Summary: Cloudflare announced OAuth for all on June 24, 2026, letting any customer create OAuth applications for delegated Cloudflare API access instead of relying on long-lived API tokens. The migration upgraded Hydra from 1.x to 2.x with a three-hour blue-green cutover, no downtime, and a revocation replay queue. API P95 latency fell from 185 ms to 101 ms after the engine swap.
On June 24, 2026, Cloudflare announced “OAuth for all” on its official blog: self-managed OAuth is now open to every customer, and any developer can create OAuth applications in the dashboard and complete a standard authorization flow for delegated access to the Cloudflare API. June 3, the date of the first, limited rollout, sits just three weeks back.
Read it as a routine product announcement and you would miss the point: underneath, the piece is a complete record of a real infrastructure operation — the OAuth engine moved from Hydra 1.x to 2.x, production migration took about three hours, and the service never went down at any point.
The Case for Going All-In: Retiring API Tokens
Third-party OAuth at Cloudflare was for years reserved for a short list of partners onboarded by hand — Wrangler and PlanetScale among them. Every other developer working against the API made do with API tokens, a credential that is hard to govern and unfit for delegated scenarios: users cannot see which permissions an application receives, and there is no ready-made way to take that access back.
The catalyst was the rapid rise of agentic tooling, and Cloudflare is explicit about it: as the developer platform expanded and agentic tools drove demand for delegated access, opening OAuth to every customer became critical to the platform’s success. Much of the groundwork appeared earlier this year — the consent screen was reworked to spell out the requesting application and the permissions it wants, revocation arrived in the dashboard, and app ownership was made more prominent to counter OAuth phishing.
An Engine Upgrade Planned in Two Stages
Hydra, an open-source project, is what runs Cloudflare’s OAuth engine. Judging the current deployment unequal to a full opening, the team planned the upgrade in two deliberate steps: advance to the final 1.x release first and observe its real behavior, then attempt the major version leap to 2.x.
The 1.x step alone took real effort: as shipped, the upstream database migrations take exclusive locks on critical tables before moving data, which halts live OAuth operations, and the SDK reads with SELECT *, so any column change breaks deserialization. The team’s answer was to rewrite the SQL, build indexes concurrently rather than lock tables, and keep — over the long term — a custom Hydra build that names its columns explicitly.
By the time 2.x arrived, schema changes had ruled out any in-place upgrade, so blue-green became the plan: run the full migration against a copy of the production database, then switch everything over in one motion.
The Switchover, and a Queue Built to Protect Revocations
The real test lives in the hours straddling the cutover. Halting all writes for that stretch is the obvious move, but it would block new authorizations — and, worse, revocations as well: anyone needing an application’s access cut off in the middle of the upgrade would have nowhere to turn.
Two safeguards bridged the gap. Token expiry was extended so that credentials issued before the switch would outlast the entire window, keeping writes to a minimum; and Cloudflare Queues became a revocation replay queue — each revocation landing during the upgrade was placed on the queue for the green side to replay in order once live. An error here would carry real consequences: applications users had revoked would quietly regain access.
The migration itself was heavy: about 132.5 million rows updated, 114.7 million inserted, and 136.97 GB of temporary data. Nor was the job finished once cutover was done. The team traced a knock-on issue: the newer Hydra judges refresh token reuse more strictly and voids the entire token chain when it triggers, hitting high-traffic Wrangler and MCP clients hardest. Request coalescing at the Worker level held things together at first; the lasting fix was the configurable refresh token grace period built into Hydra 2.x.
What the Numbers Say: P95 Latency Nearly Cut in Half
The numbers are striking: API P95 latency fell from 185 ms to 101 ms, about 45%; resident memory dropped from 888 MB to 763 MB and Go heap allocation from 449 MB to 271 MB; goroutines fell from 4,015 to 3,076; CPU use eased from 1.07 cores to 0.67, roughly 37% less. The engine swap’s dividends show up on every single request.
What Actually Changes for Developers
First, building a Cloudflare integration no longer means planting a long-lived API token inside another system: create an OAuth client, pick the narrowest scopes, and let users consent to the connection. Second, teams that want an agent working on their Cloudflare account gain a legitimate route with clear consent and one-click revocation instead of shared tokens. Third, whoever runs a SaaS or an internal platform can finally put Cloudflare on their supported-integrations list. Hacker News picked up the announcement on June 25, where it drew more than 380 upvotes — a warm reception from the community.