Resources and isolation

Two Previews bound to the same account-level resource ID or name share its data or instances. Bind a Preview to a different resource to isolate it.

This table shows which resources are automatically provisioned and which require separate resource bindings:

Durable Objects use a stateful singleton model: within a namespace, each object ID resolves to one instance and its storage. If Previews shared a namespace, they could read and overwrite the same state. For a class defined in the same Worker without script_name, each Preview automatically gets its own namespace and storage.

State persists across deployments within the same Preview and is deleted when the Preview is deleted.

Every Durable Object setup requires a Durable Object class exported from your Worker and a migration in your Wrangler config.

With ctx.exports (recommended, requires enable_ctx_exports compatibility flag, enabled by default for compatibility_date 2025-11-17 or later), the migration is enough for automatic Preview isolation:

{
	// Set this to today's date
	"compatibility_date": "2026-10-01",
	"migrations": [
		{ "tag": "v1", "new_classes": ["Counter"] }
	],
	"previews": {}
}

# Set this to today's date
compatibility_date = "2026-10-01"
previews = { }

[[migrations]]
tag = "v1"
new_classes = [ "Counter" ]

Production, feature-login, and redesign each get their own Durable Object namespace and storage. The empty previews block is sufficient because no Preview-specific Durable Object binding is needed.

If your code uses env.COUNTER, declare the binding in the previews block so the Preview has it:

{
	"durable_objects": {
		"bindings": [
			{ "name": "COUNTER", "class_name": "Counter" }
		]
	},
	"migrations": [
		{ "tag": "v1", "new_classes": ["Counter"] }
	],
	"previews": {
		"durable_objects": {
			"bindings": [
				{ "name": "COUNTER", "class_name": "Counter" }
			]
		}
	}
}

[[durable_objects.bindings]]
name = "COUNTER"
class_name = "Counter"

[[migrations]]
tag = "v1"
new_classes = [ "Counter" ]

[[previews.durable_objects.bindings]]
name = "COUNTER"
class_name = "Counter"

Containers are backed by Durable Objects. Each Preview gets its own Durable Object namespace, container app, and container instances. When you run npx wrangler preview, Wrangler builds and deploys the image for that Preview. The generated app name includes the Worker, Preview, and class names, such as my-worker_feature-login_MyContainer.

Preview container configuration is not inherited from the top level. If both production and Previews need the container, declare the container in both places:

• Top-level containers for production.
• previews.containers for Previews.

Use this pattern when your Worker accesses the container class through ctx.exports instead of an env binding:

const container = ctx.exports.MyContainer.getByName("tenant-a");
return container.fetch(request);

Declare the SQLite-backed Durable Object migration and the container configuration. Put the container configuration under previews.containers so Wrangler creates a container app for each Preview:

{
	// Set this to today's date
	"compatibility_date": "2026-10-01",
	"migrations": [
		{ "tag": "v1", "new_sqlite_classes": ["MyContainer"] }
	],
	"containers": [
		{
			"class_name": "MyContainer",
			"image": "./Dockerfile",
			"max_instances": 10,
			"instance_type": "basic"
		}
	],
	"previews": {
		"containers": [
			{
				"class_name": "MyContainer",
				"image": "./Dockerfile",
				"max_instances": 10,
				"instance_type": "basic"
			}
		]
	}
}

# Set this to today's date
compatibility_date = "2026-10-01"

[[migrations]]
tag = "v1"
new_sqlite_classes = [ "MyContainer" ]

[[containers]]
class_name = "MyContainer"
image = "./Dockerfile"
max_instances = 10
instance_type = "basic"

[[previews.containers]]
class_name = "MyContainer"
image = "./Dockerfile"
max_instances = 10
instance_type = "basic"

With this setup, production and each Preview use separate Durable Object namespaces and separate container apps. No previews.durable_objects binding is needed unless your Worker code reads the container namespace from env.

If your code uses an env binding, declare the Durable Object binding at the top level for production and again under previews.durable_objects.bindings for Previews:

import { getContainer } from "@cloudflare/containers";

const container = getContainer(env.MY_CONTAINER, "tenant-a");
return container.fetch(request);

{
	// Set this to today's date
	"compatibility_date": "2026-10-01",
	"migrations": [
		{ "tag": "v1", "new_sqlite_classes": ["MyContainer"] }
	],
	"containers": [
		{
			"class_name": "MyContainer",
			"image": "./Dockerfile",
			"max_instances": 10,
			"instance_type": "basic"
		}
	],
	"durable_objects": {
		"bindings": [
			{ "name": "MY_CONTAINER", "class_name": "MyContainer" }
		]
	},
	"previews": {
		"containers": [
			{
				"class_name": "MyContainer",
				"image": "./Dockerfile",
				"max_instances": 10,
				"instance_type": "basic"
			}
		],
		"durable_objects": {
			"bindings": [
				{ "name": "MY_CONTAINER", "class_name": "MyContainer" }
			]
		}
	}
}

# Set this to today's date
compatibility_date = "2026-10-01"

[[migrations]]
tag = "v1"
new_sqlite_classes = [ "MyContainer" ]

[[containers]]
class_name = "MyContainer"
image = "./Dockerfile"
max_instances = 10
instance_type = "basic"

[[durable_objects.bindings]]
name = "MY_CONTAINER"
class_name = "MyContainer"

[[previews.containers]]
class_name = "MyContainer"
image = "./Dockerfile"
max_instances = 10
instance_type = "basic"

[[previews.durable_objects.bindings]]
name = "MY_CONTAINER"
class_name = "MyContainer"

Use npx wrangler containers list and npx wrangler containers info <APPLICATION_ID> to inspect the generated app. Container support in Previews is partial, so verify that the process starts and responds before relying on it for testing.

Deleting a Preview removes its Preview record and Durable Object namespace. The Preview URL stops serving after deletion propagates, but the generated container app can remain visible in npx wrangler containers list.

For deterministic cleanup, check for leftover container apps after deleting a Preview:

npx wrangler preview delete --name "feature-login" --skip-confirmation
npx wrangler containers list

Delete any leftover app that belongs to the deleted Preview:

npx wrangler containers delete <APPLICATION_ID>

You can automate cleanup in CI by matching the generated app name prefix. Review the IDs before using this pattern broadly:

WORKER_NAME="my-worker"
PREVIEW_NAME="feature-login"
PREFIX="${WORKER_NAME}_${PREVIEW_NAME}_"

npx wrangler preview delete --name "$PREVIEW_NAME" --skip-confirmation

npx wrangler containers list --json \
	| jq -r --arg prefix "$PREFIX" '.[] | select(.name | startswith($prefix)) | .id' \
	| while read -r app_id; do
		npx wrangler containers delete "$app_id"
	done

Do not delete container apps by Worker name alone. A production app for the same Worker can have a similar name but does not include the Preview name segment.

Use your base branch to configure one staging database that all Previews share by default. A branch that needs an isolated database overrides that binding in its own configuration. Follow these steps to keep each branch's D1 migration target aligned with its Preview binding.

On your base branch, bind Previews to the shared staging database under previews.d1_databases. New branches inherit this configuration and use the same database:

{
	"previews": {
		"d1_databases": [
			{
				"binding": "DB",
				"database_name": "preview-shared-db",
				"database_id": "<PREVIEW_DATABASE_ID>",
			},
		],
	},
}

On the base branch, create a separate file named wrangler.preview-migrations.jsonc. Declare the shared staging database under top-level d1_databases. Copy the database_name and database_id from previews.d1_databases:

{
	"d1_databases": [
		{
			"binding": "PREVIEW_DB",
			"database_name": "preview-shared-db",
			"database_id": "<PREVIEW_DATABASE_ID>",
			"migrations_dir": "migrations",
		},
	],
}

On a branch that needs an isolated database, change database_name and database_id in both files:

The two files must point to the same physical database. Other branches continue to use the shared staging database from the base branch.

Add your migration files to the migrations/ directory. To use another location, change migrations_dir in wrangler.preview-migrations.jsonc.

Confirm that database_name and database_id match the Preview binding for the current branch, then apply the migrations:

npx wrangler d1 migrations apply PREVIEW_DB --remote --config wrangler.preview-migrations.jsonc

If multiple Previews share the same database_id, run the migration command for that database only once.

After the migrations succeed, deploy the Preview from the branch that contains its previews.d1_databases binding:

npx wrangler preview --name feature-login

Preview support for these areas may come later. If one of these limitations blocks your workflow, open an issue in the workers-sdk repository ↗︎. Describe whether the resource should be shared, auto-created per Preview, and cleaned up when the Preview is deleted.

A service binding from Worker A to Worker B tells Cloudflare: when Worker A calls env.AUTH.fetch(), route that request to Worker B.

Today, if Worker A has a service binding to Worker B and you deploy a Preview of Worker A, the Preview of Worker A can only bind to the production Worker B. It does not automatically bind to a matching Preview of Worker B.

If you need same-Worker calls to stay inside the Preview, use ctx.exports instead of a service binding.

Adding a Workflow binding to a previews block binds the Preview to an existing Workflow. It does not create or deploy a Preview-specific Workflow. To create a Workflow, deploy one with Wrangler.

A binding to an existing Workflow runs that Workflow's deployed code and bindings. Its instances belong to the existing Workflow. Changing the binding to a new name does not create a Workflow. Calls to that binding fail with workflow.not_found.

For isolated testing, first deploy a dedicated non-production Workflow, then bind the Preview to it. Previews bound to the same Workflow share its instances. A Workflow owned by another Worker runs that Worker's deployed implementation.

Cloudflare is working on automatic per-Preview Workflow provisioning, similar to Durable Objects.

Previews can produce messages to Queues. For example, a Preview can call env.MY_QUEUE.send(message) if its previews block includes a Queue producer binding.

Previews cannot consume messages from Queues today. A Queue can have only one consumer Worker, and the Queues service does not yet register a Preview as that consumer.

Be aware that messages a Preview produces to a production Queue can be consumed by production. Point a Preview at a production Queue only when this behavior is intentional. Do not point every Preview at one shared staging Queue and expect each Preview's queue(batch, env, ctx) handler to run. Only one consumer can receive those messages.

A Cron Trigger tells Cloudflare: on this schedule, run your Worker's scheduled() handler.

Cron Triggers target production. Previews do not create separate scheduled invocations, and the scheduler does not call a Preview's scheduled() handler today.

To test scheduled logic in a Preview, put the work behind a function that you can call from both scheduled() and a test-only route. Then call the test route on the Preview URL.

Production routes target production. Previews do not take over zone routes, production custom domains, Queue consumers, or other production triggers.

To send HTTP traffic to a Preview, use its Preview URL on workers.dev or a custom domain Preview URL. Custom domain Preview URLs are separate Preview hostnames, such as <preview-name>.app.example.com.