Secure all your internal vibe-coded applications — in one click

Cloudflare lets a company-login policy (Cloudflare Access) attach to a Worker, the unit that runs an application on its Workers platform, instead of only to hostnames. Its announcement explains that, with protection enabled for all hostnames, a newly attached domain inherits the Worker's authentication requirement. Previously, developers had to protect each hostname separately.

An account-level policy can also make existing and future Workers private by default, with choices for preview traffic, production traffic or both and exceptions for individual Workers. Authentication happens before application code executes. This gives organizations a central default for internal tools instead of depending on every builder to configure login protection for every deployment address.

“When you enable Access on a Worker, Cloudflare enforces authentication before any request reaches your application code.”

Cloudflare

“Now the policy is attached to the Worker itself, so any domain or URL associated with that Worker is automatically protected.”

Cloudflare

“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.”

Cloudflare

“Set an Access policy on your dispatch Worker, and every Worker deployed through it is private by default.”

Cloudflare

“This feature was made possible by FL2, the new Rust-based modular proxy that powers Cloudflare's edge.”

Cloudflare