The speed of Cloudflare Workers is what makes them powerful. Any employee can build an application and deploy it to the public Internet. That speed is also what keeps every CISO up at night: any employee can accidentally expose internal work or company data.
Today, we're launching new tools to make it easy to keep your applications hosted on Workers private. You can now apply Cloudflare Access directly to a Worker or to every Worker in your account, so your applications are behind your company login by default, without relying on each developer to set that up themselves.
How it works
When you enable Access on a Worker, Cloudflare enforces authentication before any request reaches your application code. It doesn't matter how the request gets to your Worker—whether through a custom domain, a route, a workers.dev subdomain, or a preview URL. If Access is on, the user has to authenticate first.
Previously, you had to configure this at the hostname level, setting up Access policies on each domain your Worker was reachable on. If you wanted to add a new custom domain to your Worker, you needed to update the Access policy first, or that hostname would be reachable without authentication.
Now the policy is attached to the Worker itself, so any domain or URL associated with that Worker is automatically protected. You can choose what to protect: just preview URLs, or all hostnames.
If you set it to previews only, every preview URL created for that application—whether a preview URL or a custom domain you use for previews—will require authentication whenever you deploy a new version. If you set it to all hostnames, every domain associated with that Worker is protected: custom domains, routes, subdomains, and preview URLs.
Account-wide defaults
If you have developers across your organization deploying Workers, you don't want to rely on each one to remember to enable Access. You want the default to be private.
You can set an Access policy once at the account level, and every Worker in your account—current and future—is private from the moment it's created. You choose what the policy covers: only preview URL traffic, all production traffic, or both. Preview-only is useful if your production Workers are intentionally public, but you never want an in-progress deployment exposed.
If you don't need an account-wide default and just want to lock down one specific Worker, you can apply Access to that Worker directly.
The new Access tab in the Worker view shows exactly which policies apply to that application. If you have multiple, the most specific one takes priority: hostname policies first, then Worker policies, then account policies.
Getting user identity
When Access is protecting your Worker, you can get information about who is making each request—their email, name, and groups—so you can personalize what they see, enforce permissions, or log activity per user.
Every request to your Worker carries a context with metadata about that request. When Access is enabled, we attach the authenticated user's identity to it as ctx.access. From there, you can call to get back the user's email, name, and groups.
Before, this meant validating a JWT yourself—parsing the token, verifying the signature, and extracting the claims. Now, when Access is enabled on your Worker, every authenticated request includes ctx.access.
Local development
You can use this when developing locally with wrangler dev. Add an access block to your wrangler.toml to simulate an authenticated user. Your Worker picks it up through ctx.access—returning an identity object shaped like what you'd get in production. Swap the email in your config to test as a different user.
This means you can verify that the right content shows up for the right user without having to deploy and sign in through Access every time you make a change.
Dispatch Workers
If you manage an internal platform where employees can prototype and deploy applications, you need every application to be private without configuring access controls on each one.
wrangler dispatch lets you deploy Workers at scale. Every Worker lives inside a namespace, and all traffic to that namespace goes through a single entry point: the dispatch Worker. Set an Access policy on your dispatch Worker, and every Worker deployed through it is private by default.
We also have an open-source template where you can deploy your own internal drag-and-drop deployment platform—configure access on the dispatcher Worker once, and every site deployed through it is private by default.
How it works under the hood
This feature was made possible by FL2, the new platform that powers Cloudflare's edge. Access is the front gate to your applications, and as such, it traditionally ran before all Workers logic in the request pipeline. But in order for Access applications to target individual Workers themselves instead of their hostnames, Access needs to know which Worker a given request is destined to reach. Therefore, we needed to split Workers from Workers and move the routing logic so it could run before Access.
In our old FL1 system based on NGINX and modules written in Lua, this change would have been complex and risky. Interactions between products can be subtle, and moving logic to an earlier phase of the request pipeline can be unsafe if it depends on shared state modified by another product.
FL2 made it easy. Its strict module system separates logic into well-defined, consistently ordered phases that statically declare their inputs and outputs. We were able to lean on the compiler to surface any broken interactions between phases and gradually roll out this refactor with confidence.
This is now available to everyone. Try it out in the Cloudflare Dashboard or read the documentation to get started.