Cloudflare Introduces Worker Previews for Isolated Pre-Production Testing

Cloudflare Introduces Worker Previews for Isolated Pre-Production Testing Cloudflare has launched Worker Previews, providing isolated, production-like environments for individual Git branches to enable developers and automated agents to test changes before merging to production. Worker Previews give each Git branch an isolated URL, configuration, state, and observability suite under a unified Worker dashboard view. Stateful resources are isolated automatically, creating dedicated Durable Object namespaces and Container applications per Preview to prevent data corruption in production. Preview environments integrate with Workers Observability and headless browser tooling, allowing autonomous agents to deploy, test, inspect traces, and self-improve on a per-branch basis. Previous preview URLs are renamed to Version URLs, which only pointed to uploaded versions using production resources, whereas Worker Previews provide full environment isolation. Branch-Level Isolation and Management Worker Previews extend the Git branching model beyond code by allocating an isolated environment, URL, and configuration for each branch using `npx wrangler preview` or automated triggers on push via Workers Builds. In contrast to Wrangler environments that demand individual Worker management, Previews consolidate hundreds of branches alongside production in a single dashboard view. Previews can run under custom subdomains and can be restricted via Cloudflare Access. State Isolation with Durable Objects Because Durable Objects rely on a singleton model where one instance controls its storage by ID, sharing namespaces between previews and production risks live data alteration. To prevent schema and migration errors from spilling into production, Cloudflare automatically spins up a dedicated Durable Object namespace and Container application for each Preview, routing runtime calls through `ctx.exports` to the respective isolated environment. Agent Workflows and Observability Each preview environment includes dedicated Workers Observability metrics, isolating waterfalls, error traces, and fetch calls from live production traffic. This setup supports the Agent Development Lifecycle (ADLC), allowing AI agents to interact with previews through headless tools like Browser Run and Playwright MCP. Agents can execute end-to-end user flows, inspect visual captures alongside runtime logs, generate patches, and verify repairs autonomously within the branch scope.

Cloudflare 推出 Worker Previews：为每个分支提供独立隔离的预览环境 Cloudflare 正式发布 Worker Previews，为每个 Git 分支提供贴近生产环境的独立运行空间，具备专属的代码、配置、URL、可观测性及状态，以支持人类与 AI 代理的预发布反馈与自主验证。 每个分支可通过 `npx wrangler preview` 获取专属隔离环境与 URL，支持数百个分支并发运行且互不干扰。 针对状态资源，系统自动为每个 Preview 创建专属的 Durable Object 命名空间和容器应用，避免污染生产数据。 整合了独立作用域的 Workers Observability、Browser Run 截屏与会话录制工具，便于排查运行与渲染问题。 支持通过 Wrangler 统一配置基础项、支持自定义域名，并可集成 Cloudflare Access 实现访问控制。 环境隔离与状态独立 Worker Previews 让每个分支都享有独立且贴近生产环境的运行空间。通过仪表盘可在生产与各 Preview 间切换，而无需管理多个独立的 Worker。针对 Durable Objects 单例模型，系统会在执行预览命令时自动创建独立的命名空间与容器应用，确保 Schema 变更或迁移失败仅限于该分支，彻底杜绝污染生产流量与数据的风险。 面向 AI 代理与端到端测试的可观测性 每个 Preview 环境均配备完全独立作用域的 Workers Observability，能够以瀑布图追踪包含请求、绑定操作及处理调用的全生命周期。配合 Browser Run，AI 代理或开发者可启动无头浏览器执行点击、截屏或录制会话。结合 Playwright MCP 与可观测性服务，代理可自主完成部署、测试、分析 Trace、修复及重测的闭环流程。 配置管理与实践应用 开发者可在 Wrangler 配置文件中一次性设定 Previews Base 基础配置，并在单个分支上覆盖特定参数。预览 URL 还支持自定义域名并能通过 Cloudflare Access 进行访问保护。Cloudflare 内部已在开源平台 CloudflareOS 的网关安全测试中深入使用该功能，Supermemory 与 Ramp 等团队也已将其应用于复杂的 HTTP 流程验证及编码代理的审查测试。

Nothing is worse than testing out a change that works in staging, only to see it behave differently in production. That’s why we wanted to give you an environment that’s as close to production as possible — so you can battle-test your changes and make sure they behave exactly as you expect them to. 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. Ideally, that testing is done in a way [that doesn’t slow agents down](https://blog.cloudflare.com/agent-development-lifecycle/), but gives them the tools to take on more of the development lifecycle. **That’s why today we’re launching [Worker Previews](https://developers.cloudflare.com/workers/previews).** Each Git branch gets a production-like place to run, with its own code, configuration, URL, observability, and state. So now, for every change in your codebase, you can: `npx wrangler preview`, using its own variables, secrets, and bindings, separate from production configuration and traffic.`main`. We call this the The result is a pre-production feedback loop for every branch. Push your change to a branch, test behavior, inspect performance — before you merge to production. This enables an Agent Development Lifecycle (ADLC) where each change is atomic, independently deployable, observable, and revisable. And it gives agents and humans the evidence they need to **self-improve**: catch what failed, push a fix, and verify the next deployment before it hits production. When you start work on a new feature, the first thing you do is branch off of `main`. You get your own copy of the code and make your changes without affecting anything in production. Worker Previews extend that same model beyond code. Each branch gets its own isolated environment and URL. You can run hundreds of Previews at the same time — each operating independently without affecting other Previews or production. Production and each Preview have their own configuration — served on their own URL. When you run `npx wrangler preview`, the branch gets its own copy of your Previews configuration that you have defined, running on its own URL — all under the same Worker. In the dashboard, this works like switching branches. Click the breadcrumb next to your Worker's name (it defaults to Production) to see all your Previews: The dashboard brings every environment into one view. Production sits alongside as many Previews as you need, so contributors can work on separate changes without fighting over a shared staging site. Unlike [Wrangler environments](https://developers.cloudflare.com/workers/wrangler/environments/?utm_source=gemini), where each environment requires deploying and managing a separate Worker, Previews keep that isolation in one dashboard view. Each Preview runs as a real version of your Worker. Some changes can only be validated at runtime: an API endpoint has to handle a real request and return the right response. More subjective changes, like a UI update, a new onboarding step, or a different error state, need to be experienced in context before they reach production. For isolation to extend across your application, stateful resources need special treatment. The reason for that is that Durable Objects run on a [singleton model](https://developers.cloudflare.com/durable-objects/platform/known-issues/#global-uniqueness). One instance is responsible for a given object ID, and that instance owns its storage. If a Preview shared the same DO namespace as production, you wouldn't just be reading stale data — you could modify the same instance serving live traffic in real time (scary!). That is why every time you run `npx wrangler preview`, Cloudflare automatically creates a new Durable Object namespace and Container application for that Preview — so that a failed migration or a bad schema change stays contained to that branch and that branch only. All you need to do is export the class, add its migration, and access it through [ctx.exports](https://developers.cloudflare.com/workers/runtime-apis/context/#exports): In production, `ctx.exports.Counter` resolves to the production namespace, while in a Preview, it resolves to that Preview’s namespace. You now have an entire playground to experiment with. Take Sandboxes, for example, where milliseconds of improvement to startup time can make or break the experience. If you have been trying to improve cold-start performance, you can run different configurations across branches at the same time, compare their cold and warm performance side by side, and find the best setup faster. Now that each branch runs at its own URL in an isolated environment with its own state, you can enter the feedback loop and start battle-testing every change before it reaches production. You can send traffic to the Preview URL however you normally would — from your terminal, [probe from CI](https://developers.cloudflare.com/workers/previews/examples/#probe-the-preview), an agent, or by clicking through it yourself. Once that traffic starts flowing, every Workers Observability tool you’re already used to is available, scoped to each individual Preview. As each request hits the Preview, Workers Observability traces its full lifecycle in a waterfall, including fetch calls, binding operations, and handler invocations. So when something fails, you can follow exactly what happened without sorting through production traffic or signals from other changes. Observability for Previews looks just like you're already used to for production Workers. Select your Preview from the breadcrumb and open the Observability tab to see its events, errors, and traces: To give your agents even more control, you can have them open the Preview URL in a headless browser, click through a login flow step by step, and [capture a screenshot](https://developers.cloudflare.com/workers/previews/examples/#capture-a-screenshot) or record the entire session as [replayable DOM events](https://developers.cloudflare.com/browser-run/features/session-recording/) – with Browser Run. Below is an example where an agent opens the Preview, captures what was rendered, and connects a failed request to Workers Observability events from the same run. A reviewer can watch the session in real time with [Live View](https://developers.cloudflare.com/browser-run/features/live-view/) or step in with [Human in the Loop](https://developers.cloudflare.com/browser-run/features/human-in-the-loop/) when the automation needs judgment. If something fails, you see it from both angles: what rendered and what happened at runtime. That gives the agent enough evidence to keep the pre-production loop running autonomously: deploy, open the URL with [Playwright MCP](https://developers.cloudflare.com/browser-run/playwright/playwright-mcp/), click through, query the traces through the [Workers Observability MCP server](https://developers.cloudflare.com/workers/observability/mcp-server/), patch, redeploy, and verify. Every iteration stays scoped to the branch. Just like you wouldn't reconfigure your code from scratch every time you branch, you shouldn't have to reconfigure your environment either. You set ***base configuration*** for Previews once, in a `previews` block in your [Wrangler configuration file](https://developers.cloudflare.com/workers/previews/configuration/). In the dashboard under Worker → Settings, you see this inlined as `Production` and `Previews Base`. Once the base is set, run `npx wrangler preview` from any branch to create a Preview. If your Worker is Git-connected through [Workers Builds](https://developers.cloudflare.com/workers/ci-cd/builds/build-branches/#configure-preview-builds), it happens automatically on push. You can override any setting for only one Preview — without affecting production, the base, or other Previews. To bring the whole setup even closer to production, your preview URLs can be served from your own [custom domain](https://developers.cloudflare.com/workers/previews/custom-domains). If your app runs on `example.com`, a Preview for a login branch could run at `feature-login.previews.example.com`. If you want to keep those URLs private, you can [protect your Previews with Cloudflare Access](https://blog.cloudflare.com/workers-protected-by-access/) and require visitors to sign in first. We’ve already been dogfooding Worker Previews inside Cloudflare, most notably to build and test [CloudflareOS](https://github.com/cloudflare/cloudflare-os?utm_source=gemini), our open-source platform for safely connecting agents to company systems. CloudflareOS lets agents work with services such as Google, GitHub, and Slack through [Gatekeepers](https://github.com/cloudflare/cloudflare-os?utm_source=gemini#gatekeepers-a-capability-based-security-layer), which control what those agents can access and change. That makes Gatekeeper changes especially sensitive, because a bug could expose data or permit an action that should never have been allowed. Some of these bugs only appear when OAuth callbacks, permissions, approval flows, and application state are running together. Because testing each component separately cannot show us how the complete system will behave, we deploy an isolated Preview of CloudflareOS and its Gatekeepers for every change under review. We then run the full workflow, fix what fails, and test it again before merging. We’re seeing customers use Previews for the same basic reason: some problems only show themselves when the change is actually running. "At Supermemory, we use Cloudflare heavily, and Worker Previews are exactly the kind of developer experience improvement we wanted to see. For HTTP flows, we can preview Worker changes before they reach production, including routes backed by Durable Objects, and catch issues earlier without slowing down shipping." — **Dhravya Shah**, *Founder, Supermemory* "Previews is amazing for Inspect \[Ramp’s coding agent\]. I used it to review and test an Inspect PR on my phone that is making reviewing and testing PRs with Inspect on phones responsive…with Inspect." — **Dylan Garcia**, *Senior Staff Engineer, Ramp* You might be thinking: Didn't Workers already have preview URLs? It’s true, we did. We're now calling those [Version URLs](https://developers.cloudflare.com/workers/versions-and-deployments/version-urls/) because they point to specific uploaded Worker versions. Unlike Worker Previews, they don't create an isolated environment for each branch and could only point to production resources. To learn more and compare the different workflows, check out [our docs](https://developers.cloudflare.com/workers/previews/compare-workflows/). Worker Previews is a big improvement from what we offered before, but there's still more to come. Here's what we're working on next: Worker Previews are available now. Get started with the [docs](https://developers.cloudflare.com/workers/previews/get-started), and if you have a feature request or run into an issue, open an issue on [GitHub](https://github.com/cloudflare/workers-sdk/issues/new/choose) or join the Cloudflare Developers community on [Discord](https://discord.cloudflare.com/). *Acknowledgements: This project was made possible by the design and implementation efforts of Greg Brimble, Patrick O’Donnell, Matt Price, Korinne Alpers, Max Peterson, Cina Saffary, Josh Wheeler, Thomas Ankcorn, Matt Rothenberg, and Brandon Strittmatter, with leadership from Brendan Irvine-Broque and Dan Carter.*