Cloudflare has introduced Worker Previews. This feature allows each Git branch to have its own isolated, production-like environment for a Worker. Each environment has a stable URL. It also has its own configuration and unique state for each branch. Plus, there’s scoped observability. A preview is created with npx wrangler preview, and hundreds can run concurrently under the same Worker without touching production traffic or each other.
The motivation is agent-driven development. Coding agents produce larger changes at higher volume, and testing has to keep pace without becoming a bottleneck. Cloudflare sees Previews as the feedback loop for its Agent Development Lifecycle. In this process, each change is atomic, can be deployed independently, is observable, and can be revised.
The main technical problem is state. Durable Objects follow a singleton model in which one instance owns the storage for a given object ID, so a preview sharing production's namespace could modify live instances. Wrangler creates a new Durable Object namespace and Container app for each preview. This keeps failed migrations and schema changes limited to that branch. Developers export the class, add the migration, and access it via ctx.exports. In production, this resolves to the production namespace, while in a preview, it resolves to the preview's namespace.
Configuration works like a branch that starts from main. Teams set a base configuration in a previews block of the Wrangler file. This includes variables, secrets, and bindings. For example, they might point an R2 bucket to staging storage instead of production. Each preview begins with a base. It can change individual settings, like a specific database or test API key for a migration. This happens without affecting production, the base, or other previews. Workers connected through Workers Builds get a preview automatically on push, and every push to a branch updates the same running preview.
Workers Observability is scoped per preview, so logs, errors, metrics, and request traces appear without filtering out production traffic. Cloudflare also describes an agent loop that combines Browser Run, Playwright MCP, and the Workers Observability MCP server. The agent opens the preview in a headless browser. Then, they click through a flow, like login. They capture screenshots or a replayable session. Next, they match failed requests with trace events. Finally, they patch, redeploy, and verify. Previews can be served from a custom domain such as feature-login.previews.example.com so that cookies, CORS, and OAuth redirects behave as in production, and they can be gated with Cloudflare Access.
Cloudflare says it used Previews internally to build CloudflareOS, its open-source platform for connecting agents to services such as Google, GitHub, and Slack through Gatekeepers, deploying a full preview for every change under review. Supermemory and Ramp are quoted as early users, though the post provides no benchmarks or quantitative results.
Previews differ from Wrangler environments, which require deploying and managing a separate Worker per environment, and from the existing Worker preview URLs, now renamed Version URLs. Version URLs point to uploaded Worker versions, are not isolated per branch, and can only reach production resources. Worker Previews is available now, following a private beta.
Engineers should note several current limitations. A service binding from a preview still calls the bound Worker's production deployment, so multi-Worker applications are not yet fully isolated. Previews can send messages to Queues but cannot consume them, and isolating Workflow executions requires separate configuration. Long-lived previews for staging and QA are not yet supported end to end, although Cloudflare says teams in the beta asked for them and they are on the roadmap. Teams should also review any existing reliance on Version URLs, since those still target production bindings.