Running 1,000 Headless Chromium Instances in Kubernetes Without Crashing Your Nodes

Running headless browsers at enterprise scale is resource-heavy. Vanilla Chromium instances leak zombie sub-processes, exhaust shared memory buffers, and cause cascading out-of-memory (OOM) kills across Kubernetes nodes without strict container runtime tuning.

Dockerfile Optimization Blueprint

To prevent container crashes and optimize process lifecycle management, use a minimal base paired with dumb-init as PID 1:

FROM node:20-bookworm-slim

RUN apt-get update && apt-get install -y --no-install-recommends 
    dumb-init 
    libnss3 libatk-bridge2.0-0 libx11-xcb1 libxcomposite1 libxdamage1 
    && rm -rf /var/lib/apt/lists/*

ENV PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=1
ENV PUPPETEER_EXECUTABLE_PATH=/usr/bin/google-chrome

ENTRYPOINT ["/usr/bin/dumb-init", "--"]
CMD ["node", "server.js"]

Crucial Production Flags

• Mount Custom /dev/shm: By default, Docker allocates only 64MB to shared memory. Always configure Kubernetes pods with a dedicated emptyDir memory volume mounted to /dev/shm.
• Context Recycling: Never restart the entire Chromium instance per job; spin up isolated ephemeral BrowserContext instances and close them immediately upon request completion.
• Block Unnecessary Sub-resources: Abort requests for images, web fonts, tracking beacons, and media assets to save network throughput and canvas rendering RAM.