Every app built on minibuildai is compiled inside a Cloudflare Durable Object. Durable Objects have a hard 128 MB memory limit. Some templates needed more than that to compile — and the way we found out, and fixed it, says something useful about content-addressed caches in general.
The setup
minibuildai turns a prompt into a working app and deploys it to Cloudflare. Generated apps come in three shapes: static pages, a small Hono backend with SQLite inside a Durable Object, and login/payments templates that add better-auth, kysely and a payment SDK.
The build runs in the same isolate that serves the workspace. That keeps deploys fast and the architecture simple — until a template needs to install a real dependency tree.
The failure
Login-template projects started failing with a single, unhelpful message: “build needs more than the platform's 128 MB memory limit.” The apps were tiny. The dependency tree was not. Installing and bundling better-auth plus kysely inside the isolate peaked at roughly 500 MB of heap — the isolate is reset mid-build, and no deployment row is ever written.
| Path | Peak memory | Result inside a Durable Object |
|---|---|---|
| Light template (Hono only) | ~37 MB | Builds every time |
| Login template, live install + bundle | ~500 MB | Isolate reset before deploy |
| Login template, prebuilt bundle | < 10 MB | Deploys in about a second |
The first fix: prebuild the bundle
If the isolate cannot afford to compile the dependency tree, don't compile it there. We build the login templates' deployment bundle once, offline, outside the 128 MB limit. The artifact (about 1.9 MB of modules) ships next to the template zip.
At deploy time the platform hashes the exact bundler input — every file, the entry points, the asset config. If the hash matches a prebuilt artifact, the deploy copies the modules and skips npm and esbuild entirely. A miss falls back to the slow path, which is correct but cannot survive the memory limit for heavy templates.
The bug that made it fail twice
For a while everything worked. Then every login-template project started failing again — including, oddly, projects that never changed a file.
The prebuilt cache is keyed by the content hash of the template. Our deploy pipeline regenerates the template archives on every release (prompt files, lockfiles, metadata). The archives changed; the prebuilt artifacts were not rebuilt. Every hash missed. Every deploy fell back to the live install path. Every one of them hit 128 MB.
What made this hard to spot: the fallback is silent by design. A cache miss is a valid state — it means “bundle it live” — so nothing logged a warning, nothing failed loudly. The product just looked like it was broken.
The diagnostic experiment
We stopped guessing and ran one clean experiment: create a brand-new project from the untouched login template, deploy immediately, change nothing.
- New project from the login template → same 128 MB failure within seconds.
- New project from the light template → builds and deploys normally.
That ruled out accumulated workspace state, a degraded object, and bad generated code. The template itself could not deploy — which could only happen if the prebuilt artifact was never matching.
The fix
Two changes, both small:
- Rebuild the artifacts in the same step that regenerates the archives. Template deployment now rebuilds and uploads the prebuilt bundles from the exact bytes production will serve, before the worker deploys.
- Refuse to ship an artifact that cannot match. The offline builder rebuilds the file map the same way the deploy path does, computes the hash, and verifies it against the deploy path's own logic before uploading.
After the fix, a pristine login-template project deploys in about a second, and the gallery's login app (a real registration-and-database app) builds and ships normally.
What generalizes
A content-addressed cache that silently misses is indistinguishable from a broken product.
If you run a similar pipeline, three habits would have caught this on day one:
- Instrument misses. A cache miss that falls back to an expensive path should emit a warning with the hash and the file count, not just take the fallback.
- Regenerate caches where you regenerate inputs. Any step that rewrites source material must rebuild everything derived from it — in the same pipeline, not in someone's memory.
- Assert the fast path in CI. Build one pristine project per heavy template and require the deploy to report “prebuilt”, not “live bundling”.
The bigger lesson about limits
128 MB per isolate is a deliberate constraint: it keeps the platform cheap, predictable and fast to start. It is a good limit for serving code and a bad limit for installing arbitrary npm trees. The fix was not to fight the limit — it was to move the expensive, cacheable work outside it and keep the in-isolate path cheap.
If you are building with AI on Cloudflare, the practical rules are the same: prefer no-build output, keep server dependencies small, and treat dependency installation as an offline step.
Written by the minibuildai engineering team. Numbers come from our own build and deploy logs on Cloudflare Durable Objects; “roughly 500 MB” is the observed peak while installing and bundling the login template's dependency tree.