You can control who can access your Developer Platform resources and what they can do with them by assigning roles and scopes through permission policies. Each policy combines a role, which defines the actions allowed, with a scope, which defines where those actions apply.
For Developer Platform products, scopes can be set at three levels:
| Level | Scope | Use when |
|---|---|---|
| Platform | All products on an account | You want to grant access across Workers, R2, D1, KV, Durable Objects, Queues, Workers AI, Vectorize, Hyperdrive, and other Developer Platform resources. |
| Product | All resources in one product | You want to grant access to all Workers, all R2 buckets, or all D1 databases, without granting access to other products. |
| Resource | One resource inside a product | You want to grant access to a specific resource, such as an individual Worker or R2 bucket. |
Assign one of these roles to define the level of permission you want to grant:
| Role | What it allows |
|---|---|
| Metadata Read-Only | View resource lists, settings, metrics, logs, and traces. Cannot view product content such as code, data, or stored objects. |
| Content Read-Only | Everything in Metadata Read-Only, plus read product content such as Worker code, D1 database rows, or R2 objects. Cannot make changes. |
| Editor | Everything in Content Read-Only, plus update product content and settings. Cannot create or delete resources. |
| Admin | Full control, including creating and deleting resources. |
Developer Platform permissions can be granted in two ways:
| Grant type | Best for | How it works |
|---|---|---|
| Members and User Groups | People using the dashboard or API | Permissions are inherited when the member signs in to the dashboard or authenticates to the API. |
| API tokens | CI/CD systems, automation, and service accounts | The token receives only the product and resource permissions selected when the token is created. |
When you assign a role to a member or User Group, that permission applies whenever the user uses the Cloudflare dashboard or API.
For example, if you assign a member Metadata Read-Only at the platform level, they can view settings, metrics, logs, and traces for all Developer Platform products on the account — Workers, R2, D1, and everything else — but cannot view product content like code, data, or stored objects.
If you assign Metadata Read-Only at the Workers product level, they can view settings and observability data for all Workers on the account, but have no visibility into R2, D1, or other products.
If you assign Metadata Read-Only for a single Worker, they can only see settings and observability data for that one Worker. They will not see any other Workers or any other products.
If several people on the same team or project need the same access, create a User Group instead of assigning permissions to each member.
Assign the permission policy to the group, then add the relevant members. Each member automatically inherits the group's policy.
Use API tokens for CI/CD pipelines, agents, scripts, and other automated systems that need to access Developer Platform resources programmatically.
For example, create an API token with Workers Editor for a deployment pipeline that needs to update and deploy Worker code.
API tokens support product-level and, where available, resource-level permissions. They do not support platform-level permissions. To grant an API token broad Developer Platform access, select the product-level permissions for each product the token needs.
To use granular permissions with Wrangler, authenticate with an account-owned API token.
To authenticate Wrangler with an account-owned API token, create a token with only the permissions you need, then set these environment variables:
export CLOUDFLARE_API_TOKEN="<YOUR_API_TOKEN>"
export CLOUDFLARE_ACCOUNT_ID="<YOUR_ACCOUNT_ID>"Wrangler uses the token's permissions. If the token is scoped to a specific Worker, Wrangler can only perform actions allowed for that Worker.
Wrangler commands can require different permissions depending on what they manage:
| What you want to do | Example Wrangler command | Required access |
|---|---|---|
| Deploy an existing Worker | wrangler deploy |
Editor scoped to that Worker, or Editor at the Workers product scope. |
| Create a new Worker | wrangler deploy for a Worker that does not exist yet |
Admin at the Workers product scope. |
| Tail logs for one Worker | wrangler tail |
Metadata Read-Only scoped to that Worker, or Metadata Read-Only at the Workers product scope. |
| List KV namespaces | wrangler kv namespace list |
Developer Platform Metadata Read-Only at a scope that includes KV. |
| Create a KV namespace | wrangler kv namespace create |
Developer Platform Admin at a scope that includes KV. |
| Change Routes or Custom Domains during deployment | wrangler deploy |
Editor for the Worker, plus Workers Routes Write for every affected zone. |
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.
| Use case | Scope | Role |
|---|---|---|
| View settings, logs, and metrics across all products | Platform | Metadata Read-Only |
| Read Worker code without modifying it | Workers product | Content Read-Only |
| Deploy any existing Worker, no access to other products | Workers product | Editor |
| Change Routes or Custom Domains during deployment | Workers product and each affected zone | Editor and Workers Routes Write |
| Rename an existing Worker | Individual Worker or Workers product | Editor |
| Create or delete Workers | Workers product | Admin |
| Automated deployments from CI/CD or agents | API token with Workers product | Editor |
| Automated deployments to one specific Worker | API token with individual Worker | Editor |