2 months ago
Hi,
Our Docker image builds started failing on July 5, 2026, with NO changes to build inputs (same requirements.txt and Dockerfile stages that built green on June 30). Two distinct failure modes, both pointing at builder infrastructure changes:
- OOM kills during
pip install(exit code 137)
process "/bin/sh -c pip install --no-cache-dir -r requirements.txt"
did not complete successfully: exit code: 137: context canceled
It died at a DIFFERENT package on each attempt (classic memory-pressure symptom, not a bad wheel). Our Dockerfile is multi-stage; BuildKit runs the Node frontend stage and the Python stage in parallel, and their combined memory peak now exceeds the builder's limit — it didn't on June 30.
- Headless Chromium can no longer launch in the builder
After we serialized the stages (fixing the OOM), the build failed at our puppeteer prerender step — Chromium exits immediately on launch:
[frontend-build 7/7] RUN npm run build
ERROR:dbus/bus.cc:405 Failed to connect to the bus...
ERROR:third_party/crashpad/... open /sys/devices/system/cpu/cpu0/cpufreq/...
at ChildProcess.onClose (@puppeteer/browsers/lib/esm/launch.js:339:24)
process "/bin/sh -c npm run build" did not complete successfully: exit code: 1
This is with --no-sandbox --disable-setuid-sandbox --disable-dev-shm-usage already set, using Debian's system Chromium (node:20-slim stage). The exact same step ran fine in your builders on June 30.
We upgraded to Pro DURING this incident — it made no difference to either failure, which further suggests builder-level limits rather than plan resources.
Failed deployments: July 5, 2026, ~17:00–18:15 UTC, services api/worker/beat (GitHub zuevskiy11-dot/Content-factory, branch main; commits a92c721, bc2da9d, 6246b0e). We've worked around it by removing the prerender from the image build (commit e8c8c53, built green), but we'd like the prerender back.
Questions:
- Did builder infrastructure change between June 30 and July 5 (memory limits, sandboxing/seccomp, kernel)?
- What are the current build-time memory limits on the Pro plan?
- Is running a headless browser (Chromium via puppeteer) inside an image build supported? If yes, what configuration is required now?
Thanks!
1 Replies
2 months ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • about 2 months ago
a month ago
Option 1: Move Prerendering to the Runtime Phase (Best Architectural Fix)
The build environment is highly restrictive, but the runtime environment is not. The most robust fix is to defer the Puppeteer prerender step until the container actually starts, moving it out of the Dockerfile 's RUN commands entirely.
How to do it: Remove the prerender script from the RUN npm run build stage. Instead, add a startup script (e.g., start.sh) that executes the prerender before booting the main application.
Example CMD :
bash
CMD ["sh", "-c", "npm run prerender && npm start"]
Note: This utilizes the runtime memory limits, which are directly tied to their Pro plan, ensuring they have enough resources to run the browser without hitting build-time limits.
Option 2: The DBus Environment Hack (If it MUST run during the Docker build)
If they absolutely require the image to contain the pre-rendered HTML before deployment, they need to trick Chromium into ignoring the missing DBus and system paths during the restricted build step.
How to do it: Add a DBus dummy variable to the Dockerfile and extra disable flags to the Puppeteer launch config.
In the Dockerfile:
dockerfile
ENV DBUS_SESSION_BUS_ADDRESS=/dev/null
In the Puppeteer config (append to existing args):
args: [
'--no-sandbox',
'--disable-setuid-sandbox',
'--disable-dev-shm-usage',
'--disable-gpu',
'--disable-software-rasterizer',
'--disable-features=DialMediaRouteProvider'
]
Option 3: Base Image Swap
The developer noted they are using Debian's system Chromium on a node: 20-slim stage. Compiling and running Puppeteer dependencies manually can be incredibly flaky under strict PaaS seccomp profiles.
How to do it: Switch the frontend build stage to use the official Puppeteer image, which is pre-configured to handle containerized DBus and sandboxing quirks out-of-the-box.
dockerfile:
FROM ghcr.io/puppeteer/puppeteer:latest AS frontend-build