On June 24, 2026, Cloudflare published “OAuth for all” on its official blog, opening self-managed OAuth to every customer: anyone can now create their own OAuth applications in the dashboard and obtain delegated access to the Cloudflare API through a standard authorization flow. That is just three weeks after the initial, limited launch on June 3.
It reads like a product announcement, but underneath it is the full record of a major infrastructure operation: Cloudflare upgraded its OAuth engine from Hydra 1.x to 2.x with roughly three hours of production migration time and zero user-facing downtime.
From API Tokens to OAuth: Why Open It Up
Third-party OAuth on Cloudflare used to be reserved for a small set of manually onboarded partners, such as the Wrangler and PlanetScale integrations. Everyone else building against the API had to rely on API tokens. Tokens are hard to manage and a poor fit for delegated application flows: users cannot clearly see what an application will receive, and there is no convenient way to revoke it.
The catalyst was the explosion of agentic tooling. Cloudflare says it plainly: as the developer platform grew and agentic tools drove demand for delegated access, opening OAuth to all customers became critical to the platform’s success. Earlier this year the company already reworked the consent screen to make the requesting application and its permissions explicit, added revocation to the dashboard, and made app ownership more visible to counter OAuth phishing.
Upgrading the OAuth Engine: A Two-Stage Migration
Cloudflare’s OAuth engine is Hydra, an open-source project. The old deployment could not support a full opening, so the team planned an upgrade — deliberately split into two steps: move to the final 1.x release and observe behavior first, then take the major 2.x jump.
Even the 1.x step was not trivial. The upstream database migrations take exclusive locks on critical tables, add columns, and move data around, which would block live OAuth operations; the SDK also reads with SELECT *, which breaks deserialization after schema changes. The team rewrote the SQL to build indexes concurrently instead of locking tables, and maintained a custom Hydra build that selects explicit columns.
The 2.x schema changes were too large for an in-place upgrade, so the team chose blue-green: run the migrations against a copy of the production database, then cut over.
Blue-Green Cutover and the Revocation Replay Queue
Blue-green sounds simple; the hard part is the multi-hour window in between. The obvious approach is to disable writes, but that means no new authorizations — and, worse, no way to revoke. A user trying to cut off an application’s access mid-upgrade would be stuck.
Cloudflare built two safeguards. First, it extended the expiry of newly issued tokens so credentials granted before the switch would keep working through the window, minimizing writes. Second, it used Cloudflare Queues to build a revocation replay queue: every revocation during the upgrade is written to a queue, then replayed once the green side is live. Getting this wrong has a nasty failure mode — applications users had revoked would silently regain access.
The migration moved serious data: roughly 132.5 million rows updated, 114.7 million rows inserted, and 136.97 GB of temporary bytes. After the cutover, the team also chased down a subtler issue: the newer Hydra is stricter about refresh token reuse and invalidates the entire token chain, which hurt high-volume clients like Wrangler and MCP clients. They added request coalescing in a Worker as a stopgap, then used the configurable refresh token grace period built into Hydra 2.x as the real fix.
The Performance Numbers: P95 Cut Nearly in Half
The payoff shows up in the metrics. Hydra’s API P95 latency dropped from 185 ms to 101 ms, about 45% faster; resident memory fell from 888 MB to 763 MB; Go heap allocation dropped from 449 MB to 271 MB; goroutines went from 4,015 to 3,076; and CPU use fell from 1.07 cores to 0.67, down roughly 37%. The engine upgrade pays out on every single OAuth request.
What It Means for Developers
First, building a Cloudflare integration no longer means stuffing a long-lived API token into someone else’s system: create an OAuth client, select the narrowest scopes, and let users grant consent. Second, teams that want an agent to touch their Cloudflare account now have a legitimate path with explicit consent and one-click revocation instead of shared tokens. Third, anyone running a SaaS or an internal developer platform can put Cloudflare on their supported-integrations list for real. The announcement landed on Hacker News on June 25 and drew more than 380 upvotes, a warm reception from the community.
Sources
- OAuth for all — Cloudflare Blog
- Self-managed OAuth clients — Cloudflare Changelog
- Create an OAuth client — Cloudflare Docs
- OAuth for all — Hacker News
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.