Skip to content

Build1 publisher3 min readPublished

Cloudflare gives each Git branch its own Durable Objects and Containers

Worker Previews give a branch its own URL, configuration and state, and isolating the Durable Object namespace is what keeps a preview's writes away from the single instance that owns production's storage.

The Engineer · Build desk

Illustration accompanying Cloudflare gives each Git branch its own Durable Objects and Containers

What happened

  • Cloudflare has launched Worker Previews, giving each Git branch a production-like deployment with its own code, configuration, URL, observability and state.
  • Durable Objects and Containers are isolated per branch, so state changes, sessions, memory, migrations and concurrent tests stay scoped to that Preview.
  • Cloudflare says hundreds of Previews can run at the same time, each independent of the others and of production, all under the same Worker.
  • With Wrangler environments each environment required deploying and managing a separate Worker, while Previews keep that isolation inside one dashboard view.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • exposure Branch count becomes the count of live deployments carrying copies of your secrets, each reachable on its own URL.
  • capability A destructive Durable Object class migration can be run and watched against a namespace only the branch can reach, before production sees the class change.
  • decision Teams maintaining a separate staging Worker now have to justify keeping it, because branch-level isolation removes the queue it existed to manage.

Durable Objects run on a singleton model. One instance is responsible for a given object ID, and that instance owns its storage [10]. Share a namespace between a preview deployment and production and the preview is not reading a copy of the session or the counter; it is reading the object production is serving from. Cloudflare's post says that if a Preview shared the same Durable Object namespace as production, "you wouldn't just be reading stale data" [11].

Migrations are on the list of things Cloudflare scopes to a Preview [4]. In my view that is the item that pays for the feature. A Durable Object class migration applied against production is not undone by reverting the branch, and a branch-scoped namespace is somewhere to run it and watch the logs, errors, metrics and traces for that Preview first [5].

Isolation costs something at the other end. If a Preview's Durable Objects are its own, they start with nothing in them [18]. Any test that depends on production-shaped data needs a seeding path, and someone has to write it and keep it current.

Each Preview begins from a base configuration: a copy of the variables, secrets, bindings and settings you define [6]. Every push to the branch updates the same running Preview on the same stable URL [3]. Take the hundreds figure at face value and a hundred concurrent branches is a hundred live deployments, each answering on its own URL, each holding a copy of those secrets [17].

Cloudflare's framing for the timing is agents. "Agents are helping us push more lines of code than ever before, and larger changes mean more ground needs to be tested ahead of release," the post said [13]. That case is argued in prose, without figures [16]. The singleton behaviour is the checkable part [10], and it holds the same whether a person or a model pushed the branch. Cloudflare calls the resulting loop an Agent Development Lifecycle, in which each change is atomic, independently deployable, observable and revisable [15].

The custom domain option deserves more attention than its position in the bullet list suggests. Serving Preview URLs on your own domain is what makes auth providers, cookies, CORS and OAuth redirects behave the way they will in production [8]. For the rest of the pitch to hold on your Worker, everything the code touches at runtime has to be a binding or something you can override per Preview. Cloudflare's override example is pointing a Preview at its own database or test API key for migrations, without changing production, the base, or other Previews [7]. A third-party API or an external Postgres is isolated only if you point the Preview at a test instance yourself.

What to watch

  • Whether Cloudflare publishes per-account limits and pricing for concurrent Previews.
  • Whether a documented path appears for seeding or cloning Durable Object state into a Preview namespace.
  • Whether Wrangler gains a way to expire Previews and their state when a branch is deleted.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories