Dentolize · Sandbox Build Optimizations Walkthrough
On this pageWhy this mattersWhat it changes, concretelyRisk profileWhat "done" looks like

For Stakeholders

Why this matters

The sandbox host that builds per-branch preview deployments had been OOM-crashing when two clinic-web builds (~5 GB of memory each) ran at the same time, forcing the team to serialize builds one-at-a-time through a semaphore as a stopgap. That's a direct tax on engineering velocity: every branch waiting on a preview link waits longer whenever another build is already running. This PR is a targeted fix for that constraint — no product feature, no customer impact, purely internal build infrastructure.

What it changes, concretely

Combined with a companion DISABLE_ESLINT_PLUGIN=true setting already in the sandbox Dockerfile, the PR author's estimate is a drop in clinic-web sandbox build memory peak from ~5 GB to ~1.5–2 GB. That headroom is what unlocks raising SANDBOX_MAX_CONCURRENT_BUILDS from 2 to 3–4 later — a separate, follow-on change, not part of this PR.

Risk profile

This is a low-risk change by construction:

  • Every line is inside a guard that only activates when an environment variable

(SANDBOX_BUILD) internal to the sandbox pipeline is set — production release builds (build:prod, build:with-sourcemaps) never set it, so they're provably unaffected by this PR.

  • The blast radius, even in the worst case, is limited to sandbox preview builds

being slower, flakier, or failing to build — never to production availability or data.

  • One real trade-off exists and is called out explicitly by the PR author: sandbox

builds no longer run a TypeScript type-check, so a branch with a type error could still produce a working-looking sandbox preview. The PR proposes a follow-up (a dedicated CI typecheck workflow) to close that gap; that follow-up has not landed yet as part of this PR.

What "done" looks like

The PR's own test plan (unchecked at time of writing) is the right acceptance bar: docker stats showing the memory drop during a rebuild, a second rebuild of the same branch coming back visibly faster, and a production build behaving identically with SANDBOX_BUILD unset. None of that is independently verifiable from source alone — see For Quality for what to actually check.