Cloudflare ended years of partner-only restrictions on Wednesday, opening self-managed OAuth 2.0 to every developer on its platform. The move eliminates the manual onboarding process that previously limited OAuth access to a handful of vetted partners such as PlanetScale and Wrangler — and coincides with a detailed engineering retrospective published the same day that lays out how the company executed a zero-downtime database migration to make it possible.
Any developer can now create OAuth clients directly from the Cloudflare dashboard, enabling applications to request scoped, revocable access to the Cloudflare API through a standard consent screen. Previously, developers who needed to integrate third-party tools with Cloudflare accounts had no choice but to use long-lived API tokens — credentials that hand over access without a consent screen, give the user no visibility into what the application intends to do, and are difficult to revoke cleanly.
The timing reflects a structural shift in how software is being built. Cloudflare — whose infrastructure services help run approximately 20 percent of the web — said agentic AI tools were a primary driver of demand. AI agents and Model Context Protocol servers that act autonomously on a user’s behalf need delegated, revocable authorization — precisely what OAuth provides and what API tokens cannot cleanly deliver.
Why API Tokens Were a Poor Fit for Delegated Access
OAuth 2.0 solves a problem that predates AI agents by decades: how does a user safely authorize a third-party application to act on their behalf, without handing over their credentials? The protocol, standardized as RFC 6749 in 2012, issues scoped access tokens through an authorization server after the user explicitly consents. Those tokens can be limited in scope — for example, to only managing DNS records — and revoked at any time by the user.
Cloudflare API tokens lack these properties. A developer building a SaaS product that manages a customer’s Cloudflare account previously had to instruct that customer to generate a token manually, paste it into the application, and trust the application not to exceed the permissions embedded in it. Users had no consent screen, no scope summary, and no dashboard revocation. For CI/CD pipelines and personal automation that a developer controls end-to-end, tokens remain the appropriate choice. For any flow where a third party acts on behalf of a user — which describes virtually every SaaS integration and every AI agent — OAuth is the correct model.
Cloudflare’s own MCP servers already run on OAuth 2.1. Third-party developers building agents that touch Cloudflare infrastructure now have access to the same primitive.
How Cloudflare Migrated Its OAuth Engine Without Downtime
Delivering self-managed OAuth required more than a policy decision. Cloudflare’s OAuth infrastructure runs on Ory Hydra, an open-source OAuth 2.0 engine written in Go, which had been deployed in production for years under version 1.x. Opening the feature to all developers required upgrading to Hydra 2.x — but the schema migrations involved were not straightforward.
The engineering team, led by Sam Cabell, Mike Escalante, Adam Bouhmad, and Nick Comer, identified two core problems with a direct upgrade approach. First, the required database index operations would have claimed exclusive locks on critical tables, blocking any active OAuth operations — including revocations — during the migration window. Second, the version of Hydra in use generated SELECT * queries that would fail deserialization once column layouts changed.
Rather than accept downtime, the team took a staged approach. They first migrated to the latest Hydra 1.x release, rewriting the SQL migration scripts to use CREATE INDEX CONCURRENTLY — a Postgres feature that builds new indexes without holding an exclusive table lock — and built a custom Hydra fork that selects explicit columns instead of using SELECT *.
The 1.x upgrade went cleanly in production, but immediately surfaced a new issue: Hydra’s stricter refresh token reuse behavior was invalidating entire token chains for high-volume clients such as Wrangler. A single reused refresh request would invalidate both the access token and the refresh token, ending the session. The team mitigated this by adding refresh token coalescing behavior at the Cloudflare Worker layer that routes OAuth traffic — briefly caching refresh token requests so that concurrent retries received the same token rather than triggering invalidation.
The larger challenge was the 2.x upgrade, which involved significantly more schema restructuring: column additions, table splits, and data movement across 132.5 million updated rows and 114.7 million inserted rows, totaling approximately 137 gigabytes of temporary storage during the migration. A standard in-place upgrade was not viable at this scale.
Blue-Green Migration With a Revocation Replay Queue
The team chose a blue-green deployment strategy, running migrations against a copy of the production database before cutting traffic over to the upgraded version. The fundamental problem was the migration window itself: the schema changes took approximately three hours to complete, during which any revocation events submitted by users would be directed at the old database and lost when the green environment took over.
To solve this, Cloudflare built a revocation replay queue using Cloudflare Queues. Any revocation event during the migration window was written to the queue with enough metadata to replay it against the new database after cutover. Getting this right was critical: without replay, users who revoked application access during the migration window would have found that access silently restored when traffic switched to the green environment.
The team also extended token expiry times to multiple hours before the migration window, reducing the number of token refresh operations — and therefore the number of writes that could be lost during the cutover — to a manageable level.
Post-cutover, the team found one unexpected issue: a data cleanup job in Cloudflare’s authorization service was too aggressive in purging OAuth policy data, caused in part by a Hydra 2.x migration that had corrupted the state of certain valid OAuth sessions. The corruption caused a disagreement between Hydra and the authorization service, manifesting as a spike in 403 errors. The team mitigated this with data restorations and rebuilt the authorization logic to remove reliance on static policy data.
What This Migration Playbook Means for Other Hydra Users
Cloudflare is not the only organization running Ory Hydra in production. The engine is widely deployed — including, per its documentation, at OpenAI — and many teams running Hydra 1.x will eventually face the same 2.x transition. The specific techniques Cloudflare documented — non-locking index creation with CREATE INDEX CONCURRENTLY, explicit column selection to avoid deserialization failures during schema changes, blue-green deployment with a durable event replay queue for destructive operations like revocations, and refresh token coalescing at a proxy layer — constitute a reproducible engineering pattern that addresses problems Hydra’s default migration tooling does not solve.
The post-migration production environment shows improved system performance and reliability, Cloudflare reported, with no user-facing incidents after the initial data cleanup fix.
What Developers Can Build Now
With self-managed OAuth generally available as of June 3, 2026, any Cloudflare account can register OAuth applications from the dashboard at Manage account > OAuth clients. Applications begin as private — accessible only within the registering account — and can be made public after domain ownership verification. Public applications are available to any Cloudflare user and display a verified badge on the consent screen.
Three categories of integration become straightforwardly buildable. Any SaaS product that manages Cloudflare infrastructure on a customer’s behalf — DNS records, WAF rules, Workers deployments — can now offer a standard “Connect your Cloudflare account” button backed by a scoped consent flow and dashboard revocation. Internal developer platform teams can build tooling that acts on Cloudflare resources with per-user authorization rather than shared service tokens. And AI agents that need to act on a user’s Cloudflare account — the use case that, by Cloudflare’s own account, drove this change — now have a proper delegated access model that grants only the permissions the agent needs and lets users revoke that access at any time.
OAuth scopes mirror Cloudflare API token permissions, so developers can request exactly what their integration requires and no more.
Frequently Asked Questions
What is self-managed OAuth on Cloudflare, and how is it different from API tokens?
Self-managed OAuth lets a third-party application request scoped, revocable access to a user’s Cloudflare account through a standard consent screen. The user sees exactly what permissions the application is requesting, approves or denies them, and can revoke access at any time from the Cloudflare dashboard. API tokens, by contrast, are long-lived credentials that a user generates and hands to an application directly, without a consent screen or straightforward revocation path. OAuth is the appropriate model for any flow where a third party acts on a user’s behalf — including AI agents and SaaS integrations. API tokens remain appropriate for personal automation and CI/CD pipelines that the developer controls entirely.
What is Ory Hydra, and why did upgrading it require such a complex migration?
Ory Hydra is an open-source OAuth 2.0 and OpenID Connect server written in Go, widely used by companies — including OpenAI — to power production OAuth infrastructure. Cloudflare had been running Hydra 1.x for years. The jump to Hydra 2.x required extensive database schema changes: new columns, table splits, and data movement across more than 132 million rows. Standard Hydra migration scripts would have claimed exclusive locks on critical tables — blocking all active OAuth operations, including user revocations, during the migration window. Cloudflare rewrote the migration scripts to use non-locking Postgres operations, built a custom Hydra fork to avoid deserialization errors, and added a revocation replay queue to ensure no revocation events were lost during the multi-hour cutover.
What do the Cloudflare OAuth changes mean for AI agent developers?
AI agents operating through the Model Context Protocol need to act on a user’s Cloudflare account on their behalf — deploying Workers, managing DNS records, adjusting WAF rules. Until June 3, 2026, no standard delegated authorization mechanism existed for third-party developers building such agents; they had to use static API tokens. With self-managed OAuth available to all developers, agents can now request only the permissions they need, show the user a consent screen, and have that access revoked from the dashboard if needed. Cloudflare’s own MCP servers already run on OAuth 2.1, and third-party developers can now build against the same protocol.
Can the Cloudflare Hydra migration approach be used by other teams upgrading Ory Hydra?
Yes. The core techniques — using CREATE INDEX CONCURRENTLY to avoid exclusive table locks during index creation, selecting explicit columns rather than SELECT * to prevent deserialization failures when schemas change, blue-green deployment with a durable event replay queue to preserve destructive operations during the cutover window, and refresh token coalescing at a proxy layer to handle stricter reuse policies in newer Hydra versions — are applicable to any team migrating Hydra 1.x to 2.x, regardless of cloud provider. Cloudflare’s engineering post provides the architectural rationale for each choice.
Enjoyed this article? Sign up for our newsletter to receive regular insights and stay connected.