Introducing Worker Previews: isolated preview environments for every change your agent makes
Source
blog.cloudflare.com
Date
Key takeaways · AI-distilled
Durable Objects and Containers get a fresh namespace per Preview automatically, since DOs are singleton-owned; without this isolation a Preview could read or modify the live instance serving production traffic.
Preview configuration inherits from a 'base configuration' set once in the previews block of the Wrangler config; any single Preview can then override just its own database or API key without touching production or the base.
Current limitation: a service binding called from a Preview still routes to the bound Worker's production deployment rather than a matching Preview, and Previews can publish to Queues but not yet consume from them.
Preview URLs can be served on your own custom domain (e.g. feature-login.previews.example.com) and locked down with Cloudflare Access, so OAuth callbacks, cookies, and CORS behave the same as in production.
IKEA's engineering team credits Previews' custom-domain support with avoiding Content Security Policy and cookie issues, and is waiting on upcoming Service Binding support for cross-Preview end-to-end testing.
Terms in this piece · Glossary
AI agent — An AI system that doesn't just answer once but works toward a goal in a loop — taking actions, reading the results, and deciding what to do next.
Why it matters
Cloudflare's Worker Previews give every git branch its own production-like environment (config, state, observability, URL), letting coding agents test larger changes before they reach production without slowing them down.
