Give Each Worker Its Own Deployment Credential

Yes: a deployment pipeline can access one existing Cloudflare Worker without receiving access to every Worker in the account. Use an account-owned API token with Workers Editor scoped to that individual Worker—not the Workers product scope. Editor can deploy updates but cannot create or delete Workers.

Cloudflare’s Worker-level authorization is available to all customers. Its announcement explicitly describes the CI/CD use case: separate credentials for individual Workers instead of an account-wide deployment token. Routes, Custom Domains and bound resources still need separate consideration.

Select whether the Worker exists and what your deployment changes; use the result to choose the permission boundary.

Create an Account-Owned, Worker-Scoped Token

Provision the Worker before creating its routine deployment credential. Per-Worker access can only target an existing Worker. Creating a Worker requires Workers product-level Admin access; keep that provisioning credential out of routine publishing jobs.

In the Cloudflare dashboard:

1. Select the account, then open Manage account → Account API tokens → Create Token. Creating account tokens requires API Token Provisioning capabilities or Super Administrator status.
2. Choose Workers Editor and scope it to the individual Worker.
3. Review the summary for additional grants. Product-level Editor covers every current and future Worker in the account, so it does not provide the single-Worker boundary.
4. Store the token in the deployment system’s secret store. Give each site pipeline a separate token so it can be revoked independently. Cloudflare offers an optional expiration date; use it if your rotation process can support it.

Cloudflare documents the creation prerequisites and expiration option in its account API token instructions, and the distinction between individual-Worker and product-level access in its Workers scope rules.

For Wrangler’s granular permissions, use the account-owned token. Set CLOUDFLARE_API_TOKEN to the credential and CLOUDFLARE_ACCOUNT_ID to the target account. Do not commit the token to the repository. These environment variables are documented for this authentication path in Wrangler authorization.

Run npx wrangler deploy from the configured project. Check that the selected configuration and environment target the already-provisioned Worker. A deployment targeting a nonexistent Worker is a creation operation, which the scoped Editor token cannot perform.

Keep Route Changes Outside Routine Code Releases

A code deployment and a routing change need different authority.

For an existing Route, Editor alone can deploy new versions provided the deployment does not add, update or remove that connection. Changing Routes requires Editor plus Zone → Workers Routes → Write for every affected zone. The distinction is whether the deployment changes the connection, not merely whether the Worker serves traffic through a Route. See Cloudflare’s routing permission requirements.

For a publishing pipeline, keep routine generated-content or application releases on the Worker-scoped credential. Put hostname cutovers and Route changes in a separately authorized workflow rather than adding zone permissions to every release job.

Custom Domains Have a Separate Limitation

Cloudflare includes Custom Domains in its routing requirements, but also flags Custom Domains as not currently supporting per-Worker roles. Do not assume an unchanged Custom Domain, or added zone permission, guarantees that a single-Worker token will cover the deployment workflow. See the documented current limitations.

Keep Custom Domain changes in a separate, explicitly authorized workflow. Before replacing a working credential, verify a code-only deployment against the Worker’s existing domain configuration. The general rule for unchanged Routes does not establish the same result for Custom Domains.

Editor Can Change More Than the Uploaded Code

Workers Editor is not an “upload files only” permission. It can update code, settings, schedules, versions and deployments; rename the Worker; and manage its secrets. It cannot delete the Worker, but broken or malicious deployed code can still take the site offline. These capabilities are listed in Cloudflare’s Editor role documentation.

A single-Worker token limits which Worker the credential can administer. It does not make releases to that Worker harmless. Keep deployment approval and rollback controls appropriate to the site’s exposure, even after removing account-wide access.

Bindings Preserve the Running Worker’s Capabilities

Deploying a Worker with existing KV, R2 or D1 bindings does not itself require direct permissions on those resources. Direct operations, such as querying D1 or listing R2 objects, do require their own permissions. Cloudflare distinguishes these paths in its binding authorization guidance.

That distinction does not isolate bound data from deployed code. A binding gives the running Worker a capability, such as reading and writing an R2 bucket. Code deployed with the Editor token can exercise the Worker’s available capabilities. Cloudflare explains this model in how bindings grant capabilities.

If a publishing release also runs database queries or manages storage objects directly, separate those operations from the code deployment. Review the Worker’s bindings alongside the token scope: narrowing the credential does not narrow the capabilities already available to the application.

Verify the Boundary Before Retiring the Broad Token

First, perform a controlled deployment to the intended Worker and confirm it succeeds. Check whether the release attempts Route changes, resource creation or direct database operations. Separate those tasks instead of treating every authorization failure as a reason to grant broader access.

Next, make a non-mutating API request for a known, unrelated Worker’s content using the new token. Confirm permission is denied. Use a valid request: a wrong identifier or malformed request does not prove isolation.

Verify the deployed site’s important URLs and keep rollback available. wrangler rollback requires Editor for that Worker, according to Cloudflare’s command permissions.

Once the scoped workflow is verified, remove the old broad credential from the pipeline. Revoke it if nothing else legitimately uses it. Use a focused post-remediation verification workflow for the site-level checks: successful authorization proves the token works, not that the published website works.