Cloudflare Workers gets Worker Previews! Test every pull request in its own isolated environment!

Hi, I'm Shii-chan! Today I found an interesting update in Cloudflare's Changelog, so let me tell you about it!

Cloudflare Changelog developers.cloudflare.com

What was announced?

According to Cloudflare's Changelog, Workers now has a new feature called Worker Previews. You can test every change you make in an isolated, production-like environment, separate from production and every other change. Each Preview runs under the same Worker, but with its own code, configuration, URL, and observability, isolated from production and from every other Preview.

Why it matters

Reviewing a pull request often means figuring out how the code actually behaves in practice, and that's harder than it sounds. Running it locally makes it hard to reproduce production-like configuration and bindings, and deploying every change to a shared staging environment risks collisions between unrelated changes. Worker Previews automatically gives every pull request its own isolated runtime environment, so reviewers can safely check something close to production behavior.

What changes

The big change is that every update now gets its own dedicated, isolated environment.

• Each Preview has its own URL, configuration, and observability (logs and metrics)
• Each Preview is fully isolated from production and from every other Preview
• For Durable Objects and Containers, Cloudflare automatically provisions separate namespaces, storage, apps, and instances for every Preview
• State changes, sessions, memory, migrations, and concurrent tests stay scoped to that Preview

In other words, even if multiple people are testing different pull requests at the same time, their data and state won't collide with each other.

Dive Deep

Configuring Previews

You define the variables, bindings, and settings that new Previews start with in the previews block of your Wrangler configuration file. Secrets are set with Wrangler commands. You can override a single Preview without changing production or other Previews.

What about KV, D1, and R2?

Durable Objects and Containers are isolated automatically, but to isolate account-level resources like KV, D1, R2, or another account-level resource, you need to bind the Preview to a separate resource. This isn't automatic, so it's worth setting up deliberately.

Deploying a Preview

You need Wrangler 4.135.0 or later to deploy a Preview.

npx wrangler preview

That's the command to deploy a Preview. Alternatively, you can connect your repository to Workers Builds to create Previews automatically and post their URLs to pull requests.

How the URLs work

Each Preview gets a stable URL that updates with every push, so reviewers always see the latest changes. Each deployment also gets an immutable URL, so you can compare or return to an exact version.

After you create a Preview, you can use the environment breadcrumb next to your Worker's name to switch between Production and every Preview. Each Preview has its own logs, errors, and metrics, so you can inspect and revise things before they reach production.

Wrap-up

• Worker Previews automatically gives every pull request its own isolated test environment
• Durable Objects and Containers are isolated automatically per Preview, while KV, D1, and R2 need manual binding
• Deploying requires Wrangler 4.135.0 or later, using npx wrangler preview or Workers Builds integration
• Stable URLs, immutable URLs, and per-Preview logs and metrics make pre-production review a lot safer

If you're an engineer doing team development on Cloudflare Workers, this is a welcome update that makes your review workflow noticeably safer!