Worker Previews isolate Durable Objects so CI agents never share prod

Cloudflare launched Worker Previews so every Git branch can run in a production-like place with its own code, configuration, URL, observability, and state. For CI and coding agents, the rule is narrow: deploy with npx wrangler preview, keep Durable Object namespaces isolated per branch, and never share production DO namespaces with a Preview that is still experimenting.

That is a different contract than a shared staging Worker or a Wrangler environment that is really a second Worker. Previews keep isolation under one Worker and one dashboard. The buyer question: when do you rely on the Previews base configuration, and when do you override a single branch for a Durable Object migration without touching production?

What Worker Previews ship for every branch

On the Cloudflare Blog announcement (September 22, 2026), Worker Previews give each branch a production-like environment with its own code, configuration, URL, observability, and state. From that page, for every change you can:

• Deploy an isolated Preview with npx wrangler preview, using its own variables, secrets, and bindings, separate from production configuration and traffic.
• Share a stable Preview URL for the branch so every push updates the same running Preview.
• Isolate Durable Objects and Containers per branch, keeping state changes, sessions, migrations, and concurrent tests scoped to that Preview.
• Inspect logs, errors, metrics, and traces for that Preview before production sees the change.
• Start from a Preview base configuration so each Preview begins with a copy of the variables, secrets, bindings, and settings you define — the way a code branch starts from main.
• Override one Preview’s configuration when needed (for example its own database or test API key for migrations) without changing production, the base, or other Previews.
• Serve Preview URLs on a custom domain so auth providers, cookies, CORS, and OAuth redirects behave the way they will in production. You can also protect those URLs with Cloudflare Access.

The result is a pre-production feedback loop per branch: push, test behavior, inspect performance, then merge. That is the honesty gate agents need when many changes land in parallel — related to preview deployments for AI agent review, but with Cloudflare-native isolation under one Worker.

ADLC and one Worker (not a second Worker)

Cloudflare frames this as an Agent Development Lifecycle (ADLC): each change is atomic, independently deployable, observable, and revisable. Agents and humans get evidence to self-improve — catch what failed, push a fix, and verify the next deployment before production.

When you run npx wrangler preview, the branch gets its own copy of the Previews configuration you defined, on its own URL, all under the same Worker. In the dashboard, Production sits beside as many Previews as you need; the breadcrumb switches between them.

Unlike Wrangler environments — where each environment means deploying and managing a separate Worker — Previews keep that isolation in one dashboard view. Contributors work on separate changes without fighting over shared staging, and operators do not multiply Worker objects just for branch isolation. Each Preview runs as a real Worker version, so runtime and UI changes can be validated in context before production.

Never share production Durable Object namespaces

Durable Objects use a singleton model: one instance owns a given object ID and its storage. If a Preview shared the same DO namespace as production, you would not only read stale data — you could modify the same instance serving live traffic.

That is why every npx wrangler preview run automatically creates a new Durable Object namespace and Container application for that Preview. A failed migration or a bad schema change stays on that branch only.

Export the class, add its migration, and access it through ctx.exports. Cloudflare’s example:

export class Counter extends DurableObject {}

export default {
  async fetch(request, env, ctx) {
    const id = ctx.exports.Counter.idFromName("demo");
    const counter = ctx.exports.Counter.get(id);
    return counter.fetch(request);
  },
};

In production, ctx.exports.Counter resolves to the production namespace. In a Preview, it resolves to that Preview’s namespace. CI and agents should treat that automatic resolution as the safety boundary: do not invent a shared “staging DO” that both production and Previews bind to.

Preview base config vs one-branch override

Set base configuration for Previews once in a previews block in the Wrangler configuration file. Top-level settings define production; the previews block defines what new Previews start with:

{
  "vars": {
    "ENVIRONMENT": "production"
  },
  "r2_buckets": [
    {
      "binding": "UPLOADS",
      "bucket_name": "prod-uploads"
    }
  ],
  "previews": {
    "vars": {
      "ENVIRONMENT": "preview"
    },
    "r2_buckets": [
      {
        "binding": "UPLOADS",
        "bucket_name": "r2-staging"
      }
    ]
  }
}

In the dashboard under Worker → Settings, that appears as Production and Previews Base. Once the base is set, npx wrangler preview from any branch creates a Preview. If the Worker is Git-connected through Workers Builds, Previews can happen automatically on push.

Use the Previews base for defaults every branch should inherit: preview environment vars, staging bucket names, non-prod API endpoints, and any binding that should never accidentally point at production.

Override a single Preview when one branch needs a temporary shape — its own test API key, a migration-specific database, or a one-off binding — without changing production, the base, or other Previews. Durable Object namespaces are already isolated per Preview by the platform; your job is to keep bindings and secrets either on the shared Previews base or overridden on the one branch running the migration.

Observe that Preview, then revise

Send traffic to the Preview URL from a terminal, CI probe, agent, or a manual click-through. Workers Observability tools you already use for production are available scoped to each Preview: logs, errors, metrics, and traces. Select the Preview from the breadcrumb and open Observability without sorting production traffic or signals from other changes.

Agents can open the Preview URL in a headless browser (Browser Run), capture screenshots or replayable DOM events, and connect a failed request to Workers Observability events from the same run. Reviewers can watch with Live View or step in with Human in the Loop. Deploy, open the URL, click through, query traces, patch, redeploy, verify — every iteration stays on the branch.

Preview URLs can sit on a custom domain under a dedicated previews subdomain of your production apex so cookies, CORS, and OAuth redirects match production shape. Protect those URLs with Cloudflare Access when they should not be public.

Cloudflare dogfoods Worker Previews building CloudflareOS and its Gatekeepers — agents connecting to company systems where a Gatekeeper bug could expose data or allow a forbidden action. They deploy an isolated Preview for every change under review, run the full workflow, fix failures, and retest before merge. On the same page, Supermemory’s Dhravya Shah highlights previewing Worker changes before production, including routes backed by Durable Objects; Ramp’s Dylan Garcia describes using Previews with Inspect to review and test a PR on a phone.

Version URLs are not Worker Previews

Workers already had “preview URLs.” Cloudflare now calls those Version URLs: they point at specific uploaded Worker versions. Unlike Worker Previews, Version URLs do not create an isolated environment per branch and could only point at production resources. If your pipeline still deploys a version and hits a URL that shares prod bindings, you are not on Worker Previews yet — switch the CI step to npx wrangler preview and confirm DO namespaces diverge.

What is not ready yet

The announcement’s roadmap is explicit. Today, a service binding from a Preview still calls the bound Worker’s production deployment — multi-Worker preview paths are next. Previews can send messages to Queues but cannot consume them; isolating Workflow executions still needs separate configuration. Long-lived staging or QA Previews that persist across sprints are also on the list after private-beta feedback. Design agents around current limits: isolate what Previews isolate today (including DO and Containers), and do not assume Queue consumers or cross-Worker preview paths are already branch-scoped.

Keep Preview-scoped job correlation in structured logs the way you would for structured production logs agents can triage and the same timeout discipline as API timeouts and retries for owned AI backends.

Builder checklist

1. Add a previews block for Previews Base; keep production bindings at the top level.
2. In CI and agent deploy steps, call npx wrangler preview (or rely on Workers Builds on push) — not a Version URL that still uses prod resources.
3. Rely on automatic per-Preview Durable Object namespaces and Container apps; never bind a Preview to the production DO namespace.
4. Override one Preview only when a branch needs a migration-specific secret or database; leave the base and production alone.
5. Probe the stable Preview URL, read Preview-scoped traces, then revise on that branch before merge.
6. Put Preview hostnames on a custom domain when OAuth/cookies must match production; gate with Cloudflare Access when URLs must stay private.
7. Do not plan CI on Queue consumers inside Previews or multi-Worker preview paths until those land.

Sources

• Introducing Worker Previews: isolated preview environments for every change your agent makes — Cloudflare Blog (September 22, 2026): Worker Previews launch, npx wrangler preview, per-branch URL/config/state/observability, Durable Object and Containers isolation, previews base vs per-Preview override, custom domains and Access, ADLC framing, Version URLs distinction, CloudflareOS dogfood, Supermemory and Ramp quotes, and stated next steps.