Skip to content
Latchkey

Huge image scan timing out or OOM in CI

A multi-gigabyte image with thousands of packages is slow and memory-hungry to scan. The scan may hit the tool timeout or the runner may kill it with OOM. Slimming the image is the durable fix; raising the timeout and memory is the immediate one.

What this error means

Scans of a large image either exceed the tool timeout or are killed by the OS with an out-of-memory signal, while the same tool scans small images fine.

CI
analyze error: timeout: context deadline exceeded
# or, killed by the runner:
Killed
Error: Process completed with exit code 137.

Common causes

The image is large and package-dense

Many layers and packages mean more to unpack, catalog, and match, which is slow and consumes memory.

The runner has too little memory for the scan

Cataloging a big image can exceed a small runner's memory, and the OS kills the process (exit 137).

How to fix it

Slim the image with a multi-stage build

  1. Move build tooling into a builder stage and copy only artifacts into the final image.
  2. Drop caches and dev packages from the runtime layer.
  3. Rescan the smaller image, which is faster and lighter.
Dockerfile
FROM golang:1.22 AS build
# ... build ...
FROM gcr.io/distroless/static-debian12
COPY --from=build /out/app /app

Raise the timeout and use a larger runner

Give the scan more time and memory so a genuinely large image completes.

Terminal
trivy image --timeout 20m myimage:latest
# and run on a runner with more memory for the scan step

How to prevent it

  • Keep runtime images small with multi-stage builds.
  • Cache the vulnerability DB so scan setup is not repeated.
  • Size the runner memory to the largest image you scan.

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →