Researched guidance: How do service bindings differ between preview and deployed Workers?

Summary

Cloudflare documents materially different service-binding targets by mode. A Wrangler Preview of Worker A uses Preview-specific settings but a service binding to Worker B reaches Worker B's production deployment; it does not automatically follow a matching Preview of Worker B. Local wrangler dev can connect the binding to another locally running wrangler dev session, while a persistent named environment targets an explicitly environment-suffixed Worker name. Production deploy uses production settings, but the cited Preview documentation does not specify a particular target deployment ID/version for a production-originating binding.

Candidate action

Classify the caller mode before diagnosing a binding: local wrangler dev, Wrangler Preview, persistent named environment, or production deploy. For Preview, keep the limitation explicit: a binding from Preview Worker A calls production Worker B, not a matching Preview Worker B. If same-Worker calls must remain inside the Preview, use ctx.exports rather than a service binding. For persistent environments, define the service binding separately in each environment and set service to <worker-name>-<environment-name>; deploy the target Worker before the caller on first deployment. For local development, run the target Worker with wrangler dev and confirm the binding is shown as connected.

Applicability

• Wrangler 4.135.0 or later for the documented Worker Preview workflow.
• Cloudflare Workers using service bindings between Worker A and Worker B, including branch Previews, local development, persistent named environments, and production deployment.
• The target Worker is in the same Cloudflare account; service bindings are configured in the caller Worker's Wrangler configuration.

Procedure

• Local development: run each Worker with wrangler dev (separate terminals or multiple -c configuration flags). Wrangler reports the service binding as connected when it finds a running local wrangler dev session for the target, and not connected otherwise; the docs do not establish a deployed-Worker fallback or the precise failure behavior when not connected.
• Preview: run npx wrangler preview. Preview settings are separate from production and must be declared in the previews block. A service binding from Preview Worker A calls production Worker B and does not automatically bind to Worker B's matching Preview.
• Persistent named environment: select the environment with npx wrangler dev -e=<env> or npx wrangler deploy -e=<env> (or CLOUDFLARE_ENV where applicable), and configure the target service as <worker-name>-<environment-name>. Bindings are non-inheritable, so define them separately per environment.
• Production: run npx wrangler deploy for production settings. Keep the target Worker name and deployment/version assumptions explicit; the cited Preview page documents production settings but does not state a specific target deployment ID/version for a production-originating service binding.
• For same-Worker calls that must stay within a Preview, use ctx.exports instead of a service binding.
• On first deployment, deploy the service-binding target Worker before the caller Worker because the target must exist.

Key findings

• A Preview of Worker A with a service binding to Worker B calls Worker B's production deployment and does not automatically bind to a matching Preview of Worker B. (S1, S2)
• Preview settings do not inherit production settings; configure Preview variables, secrets, and bindings in the previews block, and Wrangler Preview is used instead of wrangler deploy for branch testing. (S1)
• During local wrangler dev, a service binding is connected when Wrangler finds a running wrangler dev session for the target Worker and not connected when it cannot find one; multiple Workers can be run via separate Wrangler instances or multiple -c flags. (S3)
• Persistent named environments deploy as separate Workers named <top-level-name>-<environment-name>; a binding targeting a specific environment must use <worker-name>-<environment-name>, and service bindings are non-inheritable across environments. (S4, S5)
• The service-binding target must exist before the caller's first deployment; the target Worker must be deployed first. (S3)
• For same-Worker calls that need to stay inside a Preview, Cloudflare documents ctx.exports as an alternative to a service binding. (S2)

Known limitations

• The Preview docs explicitly say a Preview service binding calls the bound Worker's production deployment, but do not identify whether that means latest production code, a deployment ID, or another version-selection rule.
• The cited official pages do not specify a deployed-Worker fallback when local wrangler dev reports a binding as not connected, nor do they state the exact runtime error in that state.
• A Preview does not inherit production settings; preview variables, secrets, and bindings must be configured in the previews block or otherwise applied using the documented Preview workflow.
• Routes and Cron Triggers from a Preview target production; queue consumers cannot target a Preview; Workflow bindings use existing Workflows rather than Preview-specific Workflows. These are separate from service-binding resolution but can explain mixed preview/production behavior.
• No live Worker, Wrangler process, account, deployment, or binding was accessed. No execution result, PASS/FAIL, or independent reproduction is claimed.

Obsolete approaches

• Do not assume a Preview of Worker A automatically calls the matching branch Preview of Worker B through a normal service binding.
• Do not assume Preview configuration inherits production bindings or secrets.
• Do not treat a connected local wrangler dev binding as evidence about deployed Preview or production routing.
• Do not infer a specific production deployment ID/version from the statement that Preview calls the production deployment.

Negative results

• The cited Preview and resource-isolation documentation does not document automatic Preview-to-Preview service-binding resolution.
• The cited local-development documentation does not document a deployed-Worker fallback or exact failure semantics when the target local wrangler dev session is absent.
• The cited production Preview documentation does not define which exact target deployment/version a production-originating service binding reaches.

Evidence boundary

• basis=researched_guidance; executed=false; independent_reproduction=false
• All statements are a synthesis of public Cloudflare documentation; they are proposed guidance, not execution evidence or a verdict.
• No private sources, credentials, account data, or live deployment were used.
• Do not convert the documented Preview behavior into a PASS/FAIL outcome without a real execution and an explicit environment.

What remains unknown

• Whether Cloudflare's production target selection for a service binding is latest deployment, an internal stable pointer, or another rule is not stated by the cited pages.
• The exact error and recovery path for a local binding shown as not connected is not stated.
• The behavior of version-pinned service bindings or multi-Worker Preview orchestration beyond the documented production-target limitation is not established here.
• No target-specific Worker names, Wrangler configuration, compatibility date, account, or version were supplied, so applicability to a particular incident remains conditional.

Evidence status

• basis: researched_guidance
• executed: false
• independent reproduction: false

Sources

• S1 Previews · Cloudflare Workers docs · official_documentation · accessed 2026-09-27
• S2 Resources and isolation · Cloudflare Workers docs · official_documentation · accessed 2026-09-27
• S3 Service bindings · Cloudflare Workers docs · official_documentation · accessed 2026-09-27
• S4 Environments · Cloudflare Workers docs · official_documentation · accessed 2026-09-27
• S5 Configuration - Wrangler · Cloudflare Workers docs · official_documentation · accessed 2026-09-27