The architecture behind a Handled Cloud deployment.

Deployment topology

A single Handled Cloud deployment covers every origin in your configuration: micro-frontends, API gateways, and backend services.

Deploy into your own Cloudflare account and keep full ownership of the runtime, or let us manage the deployment in ours. Either way, the Handled Stack runs on Cloudflare Workers and Durable Objects, at the same edge nodes that receive your users' requests. The control plane stays in our account; the data plane can live in yours.

Adding a new application is a configuration change, not a new deployment. The same session, the same token exchange, and the same post-quantum protections apply to every route you configure.

The token-split model

When a user authenticates, the OAuth Agent obtains a full token set from your identity provider: access token, identity token, and refresh token. It then splits the set in two.

One half is stored in a secure, httpOnly session cookie on the browser. The other half is stored in a Durable Object at the edge, in a Token Store that runs on the same node. Neither half is sufficient to reconstruct a token on its own, so there is no path on which a single component (browser, edge, or origin) can impersonate the user. A compromised session cookie or a compromised edge node cannot alone produce a valid token.

On every request, the Reverse Proxy retrieves both halves, combines them to reconstruct the token, and forwards a standard JWT to your origin. Your application code never touches a cookie, a session, or an OAuth flow.

Where keys live

Client credentials for your identity provider are encrypted with AES-256-GCM before they are stored. The encryption key is a single 256-bit secret, set as an environment variable on the two workers that need it: the Tenant Config Manager and the OAuth Agent. It never appears in a database, a KV namespace, or a configuration file that leaves the worker environment.

Session cookies carry the __Host- prefix, which the browser enforces: HttpOnly, Secure, SameSite, and scoped to the exact host with no Domain attribute. A cookie that fails any of those checks is rejected by the browser before it is ever sent.

Post-quantum secure sessions

The session runs entirely on Cloudflare's network, which supports post-quantum key agreement on every connection. When a user's browser connects to a Cloudflare edge node, the TLS handshake uses a hybrid key exchange that combines a classical algorithm with a post-quantum one. If the post-quantum part is later broken, the classical part still holds; if the classical part is broken, the post-quantum part still holds.

The token-split design adds a second layer: even if the connection is compromised, the attacker holds at most one half of the token set. The session stays secure against an adversary who can break either the transport layer or a single storage location, but not both at once.