Generated by Codex with GPT-5

What happened

The official Cloudflare Blog published the engineering write-up Unlocking the Cloudflare app ecosystem with OAuth for all, a June 24, 2026 post about opening self-managed OAuth to all customers after a careful upgrade of Cloudflare’s underlying OAuth infrastructure.

The product surface is simple: developers can create OAuth clients, users can grant scoped access through a standard consent flow, and integrations no longer have to depend on broad API tokens. The engineering problem underneath was less simple. Cloudflare already ran OAuth for a small set of manually onboarded partners, but that system was not designed for broad ecosystem access, agentic tools, richer consent, easy revocation, and stronger anti-phishing affordances at Cloudflare scale.

The post is valuable because it treats a familiar platform launch as a migration and reliability story. Cloudflare needed to upgrade its OAuth engine, preserve user-facing auth flows, avoid losing security-critical revocations, and keep multiple internal systems consistent while moving through database schemas that could not be changed safely with an ordinary in-place deployment.

The migration

Cloudflare’s OAuth service was built on Hydra, the open-source OAuth engine. The team decided against one large leap and planned two sequential upgrades: first to the latest 1.x release, then to 2.x. That reduced the unknowns, but the 1.x step still required schema migrations that would have locked critical tables if run as shipped. Some indexes were created in ways that would claim exclusive locks, columns moved across tables, and the old SDK used SELECT *, which made mixed-version behavior brittle during schema change.

The first implementation lesson is that third-party migrations often need to be adapted to the operational contract of the host system. Cloudflare rewrote SQL migrations to use lock-safer patterns such as concurrent index creation and built a custom Hydra version that selected explicit columns. That let the team perform the 1.x upgrade without user impact, then observe the behavioral differences before attempting the larger 2.x shift.

The second lesson came from client behavior. After the 1.x cutover, Cloudflare saw refresh-token errors because the newer Hydra invalidated an entire token chain when it detected refresh token reuse. That rule makes sense as a security default, but it interacted badly with high-request-volume clients such as Wrangler and MCP clients, where retries can naturally duplicate a refresh request. Cloudflare mitigated the problem in the Worker that routes OAuth traffic by coalescing refresh requests briefly, so a retry could be answered without causing session-wide invalidation. This is the kind of compatibility shim that rarely appears in abstract architecture diagrams but often determines whether a migration is tolerable in production.

The 2.x upgrade required a blue-green database strategy because the schema changes were too large for an in-place migration. The naive blue-green option would have disabled writes during the migration window. That would have protected new authorizations from being lost, but it would also have blocked new OAuth use and, more importantly, prevented users from revoking access while the migration ran. For an authorization system, unavailable revocation is not a minor inconvenience; it weakens the user’s control boundary exactly when the platform is changing state.

Cloudflare chose a more nuanced plan. The team left writes enabled, increased token expiry to reduce refresh pressure during the migration, and built a queue-backed revocation replay path. If a revocation happened while the new database copy was being migrated, Cloudflare wrote enough information into Cloudflare Queues to replay that revocation after cutting over to the green database. This is the core design move in the post: it distinguishes writes that can be allowed to expire or be retried from writes that must be preserved because they represent a security decision by the user.

Why it worked

The final 2.x cutover had several moving parts: enable the revocation capture queue, copy and restore the production database, clean up old data that violated new constraints, run migrations, cut over Hydra and two related internal systems together, then monitor and validate behavior. The production migration ran for roughly three hours. After cutover, the team found that one data cleanup job was too aggressive because a Hydra migration had marked some otherwise valid sessions invalid. That caused disagreement between Hydra and Cloudflare’s authorization service, which surfaced as increased 403 responses. Cloudflare mitigated with data restoration and follow-up changes that reduced reliance on static policy data.

The broader point is not that the migration was flawless. It is that Cloudflare had enough staging, queueing, observability, and rollback-adjacent recovery paths to turn a bad edge case into an operational incident rather than a failed launch. OAuth is infrastructure where correctness is multidimensional: a token must work when it should, fail when it should, preserve revocations, maintain consent semantics, and remain explainable to users. The migration plan explicitly separated those invariants instead of treating the database as a generic blob of state.

The payoff was measurable. The upgraded Hydra service reduced average API P95 latency from about 185 ms to about 101 ms, lowered RSS memory from about 888 MB to about 763 MB, cut Go heap allocation from about 449 MB to about 271 MB, reduced goroutines from about 4,015 to about 3,076, and dropped CPU use from about 1.07 cores to about 0.67 cores. Those improvements matter because OAuth became a platform primitive, not a boutique integration path. A delegated-access system that backs SaaS integrations, internal developer platforms, and agentic tools has to be cheap and stable enough to sit on the hot path.

Takeaway

The strongest engineering lesson is that authorization migrations should be designed around user-control invariants, not only around service uptime. Cloudflare accepted that some token writes were less important than revocation preservation, then built the queue replay mechanism around that priority. That framing is useful beyond OAuth: in any security-sensitive migration, not every write has the same semantic value, and the migration machinery should preserve the writes that express trust, consent, or revocation before it optimizes for generic completeness.

The post is also a good example of how to operationalize a platform expansion. Cloudflare did not simply expose an existing internal capability to more users. It hardened consent UX, added dashboard revocation, made app ownership visible, repaired migration SQL, handled old-client retry behavior, planned a blue-green database move, and validated performance after the fact. The durable takeaway is that “self-service for all” usually means the hidden system must become more explicit: clearer permissions, stronger abuse controls, safer migrations, better observability, and a recovery path for every state transition that users depend on.