Cloudflare Launches Worker Previews, Giving Every Git Branch Its Own Isolated Workers Environment
Cloudflare's Worker Previews, created with npx wrangler preview, give each Git branch an isolated environment with its own URL, configuration, state and observability.
Overview
Cloudflare has launched Worker Previews, a feature that gives each Git branch of a Cloudflare Workers project its own production-like place to run. In its launch post, dated September 22, 2026, the company says each branch gets “its own code, configuration, URL, observability, and state.” InfoQ covered the release on September 29, noting that it is available now following a private beta.
What We Know
According to Cloudflare, a developer deploys an isolated Preview with npx wrangler preview, using its own variables, secrets, and bindings, separate from production configuration and traffic. Cloudflare says hundreds of Previews can run at the same time, and InfoQ reports they run concurrently under the same Worker without touching production traffic or each other. Every push to a branch updates the same running Preview, per InfoQ.
State isolation. The main technical problem, per Cloudflare, is that Durable Objects run on a singleton model, so a Preview sharing production’s namespace could modify the same instance serving live traffic. Each time npx wrangler preview runs, Cloudflare creates a new Durable Object namespace and Container application for that Preview, so a failed migration or a bad schema change stays contained to that branch.
Configuration. Teams set a base configuration once in a previews block of the Wrangler configuration file, according to Cloudflare. Individual Previews can override settings without changing production, the base, or other Previews. For Workers connected through Workers Builds, Cloudflare says a Preview is created automatically on push.
Custom domains. Preview URLs can be served from a custom domain; Cloudflare’s example is a login-branch Preview at feature-login.previews.example.com, and it says Previews can be protected with Cloudflare Access.
Agent workflow. Cloudflare positions the feature around coding agents. InfoQ describes the motivation as agent-driven development, where coding agents produce larger changes at higher volume and testing has to keep pace. Cloudflare describes an agent loop of deploying, opening the URL with Playwright MCP, clicking through, querying the traces through the Workers Observability MCP server, patching, redeploying, and verifying.
How It Differs From Existing Options
Cloudflare says that, unlike Wrangler environments, where each environment requires deploying and managing a separate Worker, Previews keep that isolation in one dashboard view. The company also says Workers already had preview URLs, which it is now calling Version URLs. Per Cloudflare, they point to specific uploaded Worker versions, do not create an isolated environment for each branch, and could only point to production resources. InfoQ advises teams to review any reliance on Version URLs, since those still target production bindings.
Early Use
Cloudflare says it used Worker Previews internally to build and test CloudflareOS, its open-source platform for safely connecting agents to company systems. The launch post quotes Dhravya Shah, Founder of Supermemory, and Dylan Garcia, Senior Staff Engineer at Ramp. Shah said Worker Previews are “exactly the kind of developer experience improvement we wanted to see.” InfoQ notes that the post provides no benchmarks or quantitative results.
What We Don’t Know
Several limits remain, according to Cloudflare. A service binding from a Preview still calls the bound Worker’s production deployment, so multi-Worker applications are not fully isolated. Previews can send messages to Queues but cannot consume them, and isolating Workflow executions requires separate configuration. Support for long-lived Previews for staging and QA is listed among the company’s next steps. The launch post itself provides no benchmarks or quantitative results, according to InfoQ.