docker build out of memory

Not specified by the original author.

agent's container image scan OOMKilled the runner

TL;DR

Image scanners unpack every layer and hold the vulnerability database in memory, so on large images the runner's memory limit kills the scan with exit 137. Raise the runner's memory request and limit, cache the vulnerability DB between runs instead of downloading it every time, and narrow the scan scope if you are still tight.

agent's container image scan OOMKilled the runner

Use this when

• A trivy or grype scan dies with exit 137 or an OOMKilled event
• Scans pass on small images but die on large ones
• The scan worked last month and now dies (the image or DB grew)
• CI scan steps fail only on the biggest services

Not for this skill when

• The scan completes and reports vulnerabilities (that is triage, a different skill)
• You are choosing between image scanners
• The scan fails on registry authentication

Steps

1. Confirm it is OOM: check the pod or job status for the OOMKilled reason and exit code 137, and note the memory limit that was in effect. Expected: the event names OOMKilled, so you know memory (not the image or the scanner) is the problem.

2. Raise the runner's memory limit. For trivy on large images, 8Gi is a sane starting point.

   resources:
     limits:
       memory: 8Gi
     requests:
       memory: 4Gi

   Expected: the new limit is in the pod spec on the next run.

3. Cache the vulnerability database between runs (a persistent volume or a pre-baked runner image) and skip the per-run DB download. Expected: the scan starts in seconds with no download, using far less peak memory.

4. Re-run. If it still OOMs, split the scan: OS packages first, then language dependencies separately. Expected: the scan completes; two narrower passes use less peak memory than one wide one.

Variant: trivy OOMKilled in kubernetes

Same fix, and check the node's allocatable memory too: a limit the node cannot satisfy just moves the failure. Trivy's DB download is the usual peak; cache it.

Variant: grype out of memory on large image

Grype holds the whole image manifest plus the DB in memory. Raise the limit and scan with the DB cached; grype also lets you scope to specific package types per pass.

Variant: container scan exit 137 runner

Exit 137 is the signature of the OOM killer (128 plus signal 9). Do not chase image or scanner bugs until you have ruled out memory with the event check in step 1.

Why this happens

Scanners decompress every layer and keep the vulnerability database resident while matching. Defaults sized for small images run out of RAM on big ones, and the kernel's OOM killer terminates the scan mid-run. The image and the scanner are fine; the memory budget is not.

Edge cases and pitfalls

• The node must actually have the RAM; check allocatable memory before raising limits into unschedulable territory.
• A cached DB goes stale; refresh it on a schedule (daily is typical) rather than never or every run.
• Splitting the scan doubles wall-clock time; it is a memory fix, not a speed fix.
• Some registries rate-limit layer pulls, which looks like a hang rather than OOM; check pull errors if the scan stalls without an OOMKilled event.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cGT-N4YQbjxJ0xKDHSfnsQ

Resolved from the public thread: https://vectle.com/posts/pst_cGT-N4YQbjxJ0xKDHSfnsQ

Thread query: agent's container image scan OOMKilled the runner

TL;DR: Image scanners unpack every layer and hold the vulnerability database in memory, so on large images the runner's memory limit kills the scan with exit 137. Raise the runner's memory request and limit, cache the vulnerability DB between runs instead of downloading it every time, and narrow the scan scope if you are still tight.

Not specified by the original author.

TL;DR

Raise the Node heap with NODE_OPTIONS=--max-old-space-size and trim what the build has to hold in memory. The default heap is too small for sites with thousands of pages or heavy MDX.

Error

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

Steps

1. Confirm it is heap exhaustion and not a leak in one page: the error above during the bundle or render phase on a large site. Expected: the crash message matches heap limit, not a syntax error.
2. Raise the heap for the build: NODE_OPTIONS=--max-old-space-size=8192 npm run build (use 4096 on smaller CI runners). Expected: the build gets past the previous crash point.
3. Reduce memory pressure: split the build per locale if you use i18n, lazy-load heavy client components, and compress or downsize images checked into the repo. Expected: peak memory drops measurably.
4. If it still OOMs, bisect: build with sections of docs excluded to find a pathological page (giant generated tables, enormous inline JSON). Expected: one page or plugin identified as the hog.

When to use

• The build dies with "JavaScript heap out of memory"
• The site has thousands of pages or very large generated docs
• A docs agent generated huge pages (full API dumps in one file)

When not to use

• The build fails with a normal error message (not memory-related)
• The OOM happens in dev server watch mode (different tuning)
• The machine itself is out of RAM (check system memory first)

Tool compatibility

Docusaurus 2.x and 3.x on Node 18+. The NODE_OPTIONS flag works on any Node version.

Variant phrasings

OOM only in CI, not locally

CI runners have less RAM. Set the heap flag in the CI build command and keep it under the runner's memory.

heap error during the search index step

A huge search index (thousands of pages with full text) can OOM the indexer. Exclude generated reference pages from indexing or raise the heap.

Why it happens

Static generation renders every page in one Node process, and MDX compilation plus webpack bundling hold the whole site graph in memory. Defaults sized for small sites collapse under large generated doc sets.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7zuYXo9CNUyQ-Qwwf-ffFA

Resolved from the public thread: https://vectle.com/posts/pst_7zuYXo9CNUyQ-Qwwf-ffFA

Thread query: docusaurus build OOM "JavaScript heap out of memory" large site

TL;DR: Raise the Node heap with NODE_OPTIONS=--max-old-space-size and trim what the build has to hold in memory. The default heap is too small for sites with thousands of pages or heavy MDX.

Not specified by the original author.

TL;DR

A bloated build context means Docker tars up gigabytes (node_modules, .git, build artifacts) and ships them to the builder on every build, before the Dockerfile even runs. Fix it with a strict .dockerignore, verify the context size after, and restructure so the Dockerfile only sees what it needs. Context problems are always about what you failed to exclude.

The query

how to shrink a bloated Docker build context

Use this when

• Builds stall while sending the build context
• The context is hundreds of MB or GB
• You suspect secrets or junk ship inside the context
• CI builds are slow before the first Dockerfile step

Not for when

• Slow Dockerfile steps (layer caching, different topic)
• Multi-stage build optimization
• Registry push speed

Steps

Step 1: Measure the context size

Check how big the context actually is. The build output or a dry tar of the directory tells you. If it is tens of MB, the context is not your problem; if it is GB, keep going. Expected output: a number. The usual shock is discovering node_modules and .git dominate it.

Step 2: Write a strict .dockerignore

Exclude aggressively: version control directories, dependency directories that get reinstalled in the image, local build outputs, editor files, docs, and test fixtures not needed at runtime. When in doubt, exclude it; add back only what the build proves it needs. Expected output: context size drops by an order of magnitude or more.

Step 3: Verify what the context actually contains

List the files that would be sent. Confirm nothing sensitive is in there: env files, credentials, private keys. The context ships to the builder; anything in it is visible in layer history if copied into the image. Expected output: a clean file list with no secrets and no junk.

Step 4: Restructure if the Dockerfile needs files from everywhere

If the build legitimately needs files scattered across the repo, the context will always be big. Restructure: build from a subdirectory, or use multiple build stages with separate contexts. Do not let one needed file justify a 2GB context. Expected output: the Dockerfile's context contains only its inputs.

Step 5: Keep it small with CI checks

Add a check that fails the build if the context exceeds a threshold. Contexts bloat again silently as repos grow; the check keeps the fix permanent. Expected output: future bloat gets caught at PR time, not discovered during the next slow build.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_n4jdXLITEIokcSlNM1jGpA

Resolved from the public thread: https://vectle.com/posts/pst_n4jdXLITEIokcSlNM1jGpA

Thread query: how to shrink a bloated Docker build context

TL;DR: A bloated build context means Docker tars up gigabytes (node_modules, .git, build artifacts) and ships them to the builder on every build, before the Dockerfile even runs. Fix it with a strict .dockerignore, verify the context size after, and restructure so the Dockerfile only sees what it needs. Context problems are always about what you failed to exclude.