Workers permissions control who or what can view, deploy, and manage Workers in your Cloudflare account. Access is granted by assigning a Workers role to a member, User Group, or API token at a specific scope.
Workers roles define what actions are allowed. Scopes define where those actions apply: across all Workers in the account or only to selected Workers.
For the platform-wide permission model, refer to the Roles and permissions overview.
You can assign Workers roles to members, User Groups, and API tokens.
| Role | Access level | Description |
|---|---|---|
| Metadata Read-Only | Read metadata | Can view Workers metadata, settings, and observability data such as metrics, logs, and traces. Cannot view script source content or secret values. |
| Content Read-Only | Read content | Can view Workers metadata and script source content. Cannot modify Workers. |
| Editor | Edit | Can read, update, deploy, and rename existing Workers, including script content, settings, schedules, versions, deployments, and observability. Cannot create or delete Workers. |
| Admin | Full manage | Full control over Workers, including creating, reading, updating, deploying, deleting, and renaming Workers when granted at the product scope. Per-Worker Admin applies only to the selected Worker. |
Workers roles can be granted at different scopes depending on how broadly the access should apply.
| Scope | Applies to | Use when |
|---|---|---|
| Workers product | All Workers in the account | A member, User Group, or API token needs the same access across all Workers. |
| Individual Workers | Only selected Workers | A member, User Group, or API token should only access specific Workers. |
Product-level roles apply to every current and future Worker in the account.
Per-Worker roles apply only to the Workers you select. You cannot grant per-Worker access to a Worker that does not exist yet. Creating new Workers requires product-level Admin access.
You can combine product-level and per-Worker roles to give broad visibility but limited edit access.
For example, grant Metadata Read-Only at the Workers product scope so someone can browse Workers and view observability data across the account. Then grant Editor only for the specific Workers they should deploy.
You can assign Workers roles to members, User Groups, and API tokens.
Members and User Groups are for people who need dashboard or user-based access. API tokens are for CI/CD pipelines, agents, scripts, and Wrangler automation.
API tokens use the same Workers roles and scopes as members and User Groups, but they have their own permissions. A token can only perform actions allowed by the Workers role and scope assigned to that token.
To add, update, or remove Routes or Custom Domains, you need Editor access to the Worker and Workers Routes Write permission for every affected zone.
Members and User Groups need Workers Routes Write, scoped to each affected zone.
API tokens need Zone > Workers Routes > Write, scoped to each affected zone.
After a Route or Custom Domain is configured, you can deploy new Worker versions with only Editor access, as long as the deployment does not add, update, or remove that connection.
Wrangler authorizes commands using the Workers permissions of the authenticated member or API token.
Here are examples of the scope required to run Wrangler commands:
| Action | Wrangler command | Minimum role required |
|---|---|---|
| Tail logs for a Worker | wrangler tail |
Metadata Read-Only for that Worker |
| Deploy an existing Worker | wrangler deploy |
Editor for that Worker |
| Change Routes or Custom Domains during deployment | wrangler deploy |
Editor for that Worker, plus Workers Routes Write for each affected zone |
| Create a new Worker | wrangler deploy for a Worker that does not exist yet |
Product-level Admin |
| Upload a version | wrangler versions upload |
Editor for that Worker |
| Deploy a version | wrangler versions deploy |
Editor for that Worker |
| Roll back a deployment | wrangler rollback |
Editor for that Worker |
| Manage secrets for an existing Worker | wrangler secret put, wrangler secret delete |
Editor for that Worker |
These legacy permissions and roles are being replaced by the new Workers roles. There is no deprecation date right now. Existing permissions and roles continue to work, and customers will receive advance notice before any deprecation.
These legacy permissions and roles were account-level. To preserve the same behavior, assign the replacement role at the scope shown below. Use per-Worker scopes only when you intentionally want to limit access to selected Workers.
| Legacy permission or role | Replaced by |
|---|---|
| Workers Platform (Read-only) | Content Read-Only at the Developer Platform scope |
| Workers Platform Admin | Admin at the Developer Platform scope |
| Workers Platform Metadata (Read-Only) | Metadata Read-Only at the Developer Platform scope |
| Workers CI Read | Content Read-Only at the Workers product scope |
| Workers CI Edit | Editor at the Workers product scope |
| Workers Observability Read | Metadata Read-Only at the Workers product scope |
| Workers Observability Edit | Editor at the Workers product scope |
| Workers Observability Telemetry Edit | Editor at the Workers product scope |
| Workers Tail Read | Metadata Read-Only at the Workers product scope |
| Workers Scripts Read | Content Read-Only at the Workers product scope |
| Workers Scripts Edit | Editor at the Workers product scope |
For members and User Groups, use Developer Platform roles to grant Cloudflare Pages access. Do not use Workers product roles or per-Worker roles for Pages access.
For API tokens, use Pages-specific roles. These roles are available when creating account-owned API tokens.
| API token role | Access |
|---|---|
| Pages Metadata Read | View Pages metadata and configuration. Does not include Pages content access. |
| Pages Read | View Pages metadata and content. |
| Pages Write | Create, update, and delete Pages projects and Pages content. |
To deploy a Worker that has bindings to resources like Workers KV, R2, or D1, you need Editor access to the Worker. You do not need separate permissions on the bound resources to deploy the Worker.
Permissions on bound resources are only required if you need to access those resources directly, for example, reading KV keys, querying a D1 database, or listing R2 objects.
- Product-level Workers roles do not grant access to other Developer Platform products such as R2, D1, KV, Queues, Vectorize, or Hyperdrive.
- API tokens do not support platform-level Developer Platform permissions.
- Creating a new Worker requires Workers Admin because per-Worker permissions can only apply to Workers that already exist.
- Custom Domains do not currently support per-Worker roles. Support is planned.
- Legacy Workers permissions may appear in older configuration or API references, but new documentation should use the replacement Workers roles.