Cloudflare Access (4)

Last updated Oct 12, 2026 With Cloudflare Access, you can restrict who is authorized to access your application. You decide who is approved, and every request is checked before your Worker runs. Approved visitors are let through, while everyone else is shown a login page or blocked.

You can protect:

• A single application: require sign-in on its preview URLs, production URLs, or both.
• All Workers in your account: protect every existing and newly created Worker by default.
• Specific custom domains and hostnames: restrict access at the hostname or route level.

Before you start

To use Access with Workers, you need:

• Zero Trust enabled on your account. If Zero Trust is not turned on, complete Zero Trust setup first, then return to the Workers dashboard.
• Permission to manage Workers and Access applications.

Choose what to protect

Protect all Workers

Require sign-in on every Worker in your account, including Workers you deploy in the future. You can require sign-in on only preview deployments, or on both production and preview deployments.

Dashboard path: Workers & Pages overview page > Protect all Workers.

1. In the Cloudflare dashboard, go to the Workers & Pages page. Go to Workers & Pages ↗
2. Find the Protect all Workers card.
3. If the card says Not enabled, select Enable Access.
4. Choose Previews only or All traffic.
5. Under Authentication policy, select an existing policy or configure one of the policy options.
6. Select Enable Access.
7. (Optional) Review the session duration.
8. Select Apply Access.

To protect only preview deployments for every Worker, create a self-hosted Access application with an all_preview_workers destination:

"destinations": [
  {
    "type": "all_preview_workers"
  }
]

To protect every Worker's production and preview deployments, use all_workers instead:

"destinations": [
  {
    "type": "all_workers"
  }
]

Send these destinations in a POST /accounts/{account_id}/access/apps request. For the full request schema, including policy options, session settings, and advanced Access options, refer to the Access applications API.

Protect one Worker

Require sign-in on a single Worker. This automatically protects every domain associated with the Worker, including its routes, Custom Domains, workers.dev hostname, and previews. You can require sign-in on only preview deployments, or on both production and preview deployments.

WebSocket limitation

Worker-level Access policies do not currently support WebSocket connections. WebSocket upgrade requests to a Worker protected by a worker-level Access policy will fail with a 403 error.

If your Worker uses WebSockets (including Durable Objects, real-time applications, or RDP-over-WebSocket), protect it with a hostname-based Access application instead.

Dashboard path: Workers & Pages > select your Worker > Access.

1. In the Cloudflare dashboard, go to the Workers & Pages page. Go to Workers & Pages ↗
2. Select your Worker from the application list.
3. Select the Access tab.
4. Select Protect this Worker behind Access.
5. Choose Previews only or All traffic.
6. Under Authentication policy, select an existing policy or configure one of the policy options.
7. (Optional) Review the session duration.
8. Select Apply Access.

To protect only preview deployments for one Worker, create a self-hosted Access application with a preview_worker destination. Set worker_id to your Worker's ID:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps" \
  --request POST \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --json '{
    "type": "self_hosted",
    "name": "Access for my-worker",
    "destinations": [
      {
        "type": "preview_worker",
        "worker_id": "c81a2d22c29840ed9d61681a3270dbff"
      }
    ],
    "policies": [
      {
        "decision": "allow",
        "include": [
          {
            "email_domain": {
              "domain": "example.com"
            }
          }
        ]
      }
    ]
  }'

To protect the Worker's production and preview deployments, use worker instead:

"destinations": [
  {
    "type": "worker",
    "worker_id": "c81a2d22c29840ed9d61681a3270dbff"
  }
]

For the full request schema, including policy options and session settings, refer to the Access applications API.

Protect a specific hostname, Custom Domain, or path

Use hostname-based Access when only a specific URL that routes to your Worker should require sign-in, such as a workers.dev hostname, a Custom Domain, a subdomain, or a path. Hostname-based Access protects only that exact URL, whereas protecting a Worker protects the entire Worker regardless of how it is accessed. For example with hostname-based Access, you can protect my-worker.example.workers.dev, admin.example.com, or a single path such as example.com/login to make only part of your Worker private.

In both the dashboard and the API, you protect a hostname or path by creating a self-hosted application and using the hostname or path as the application domain.

Create the self-hosted application in Zero Trust > Access > Applications. To match subdomains, multiple paths, or wildcards, refer to Application paths.

Create the self-hosted application with a POST /accounts/{account_id}/access/apps request, setting the application domain to the hostname or path. For the full request schema, refer to the Access applications API.

Make a Worker public when all Workers are protected

If account-level Access protects all Workers, you can make a specific Worker public by adding a Worker-level bypass. A bypass means Access does not require sign-in for that Worker.

Note

This is only useful when account-level Access already protects the Worker. If there is no account-level Access policy, a public Worker does not need a bypass.

Dashboard path: Workers & Pages > select your Worker > Access.

1. In the Cloudflare dashboard, go to the Workers & Pages page. Go to Workers & Pages ↗
2. Select your Worker from the application list.
3. Select the Access tab.
4. Select the option to make the Worker public or bypass account-level Access.
5. Confirm the change.

Create a Worker-level Access application with a bypass policy. Use the worker destination, set worker_id to your Worker's ID, and set the policy decision to bypass with an include rule that matches everyone:

"policies": [
  {
    "decision": "bypass",
    "include": [
      {
        "everyone": {}
      }
    ]
  }
]

Policy options

When you turn on Access, choose who can sign in. The same policy options are available whether you protect all Workers or one Worker.