Resources and isolation·续

Resources and isolation·续

If you use env.MY_CONTAINER without declaring the Durable Object binding in your previews block, the binding will not exist in the Preview and your Worker can return a 1101 error.

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.

Container application cleanup

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.

D1 migrations

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.

1. Configure the shared staging database

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:

wrangler.jsoncjsonc

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

2. Create a Wrangler configuration file for migrations

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:

wrangler.preview-migrations.jsoncjsonc

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

3. Override the database for one branch (optional)

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

File	Binding to update
`wrangler.jsonc`	`previews.d1_databases`
`wrangler.preview-migrations.jsonc`	Top-level `d1_databases`

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

4. Add migration files

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

5. Apply migrations to the Preview database

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.

6. Deploy the Preview

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

npx wrangler preview --name feature-login

Limitations

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.

Service bindings

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.

Workflows

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.

Queue consumers

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.

Cron Triggers

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.

Routes

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.

Was this helpful?

YesNo

{"@context":"https://schema.org","@type":"TechArticle","@id":"https://developers.cloudflare.com/workers/previews/resources/#page","headline":"Resources and isolation","description":"Understand which Preview resources are shared, which are isolated, and which invocation types have limitations.","url":"https://developers.cloudflare.com/workers/previews/resources/","inLanguage":"en","image":"https://developers.cloudflare.com/workers/previews/resources/og.png?v=a51699232e855b7d","dateModified":"2026-09-22","publisher":{"@type":"Organization","name":"Cloudflare","description":"One platform for your apps, agents, and workforce. Build, secure, and scale without managing infrastructure","url":"https://www.cloudflare.com/","sameAs":["https://github.com/cloudflare","https://www.linkedin.com/company/cloudflare","https://x.com/cloudflare"],"logo":{"@type":"ImageObject","url":"https://developers.cloudflare.com/logo.svg"},"address":{"@type":"PostalAddress","streetAddress":"101 Townsend St","addressLocality":"San Francisco","addressRegion":"CA","postalCode":"94107","addressCountry":"US"},"contactPoint":[{"@type":"ContactPoint","contactType":"Customer Support","url":"https://support.cloudflare.com/","availableLanguage":["English"]},{"@type":"ContactPoint","contactType":"Sales","url":"https://www.cloudflare.com/contact/","availableLanguage":["English"]}]},"isPartOf":{"@type":"WebSite","@id":"https://developers.cloudflare.com/#website","name":"Cloudflare Docs","url":"https://developers.cloudflare.com/"}}

description: Test and debug Previews with logs, traces, metrics, Tail Workers, and browser evidence. title: Test and debug image: https://developers.cloudflare.com/workers/previews/test-and-debug/og.png?v=192029c950ad4ec5

Documentation Index
Fetch the complete documentation index at: https://developers.cloudflare.com/workers/llms.txt
Use this file to discover all available pages before exploring further.

Resources and isolation·续

Resources and isolation·续

Container application cleanup

D1 migrations

1. Configure the shared staging database

2. Create a Wrangler configuration file for migrations

3. Override the database for one branch (optional)

4. Add migration files

5. Apply migrations to the Preview database

6. Deploy the Preview

Limitations

Service bindings

Workflows

Queue consumers

Cron Triggers

Routes

On this page