Cloudflare's OHTTP Gateway is a quiet act of architectural integrity, and it deserves more attention than the beta itself. The company is offering a managed endpoint that decrypts Oblivious HTTP requests for an origin, but the notable detail is what it refuses to do: the Gateway will not decrypt requests coming from Cloudflare Workers or from hosts proxied through Cloudflare. That separation is the whole point, and it is a standard more vendors should adopt.
The logic is straightforward. Oblivious HTTP splits the client's identity from the request content so that no single party holds both. If Cloudflare's own gateway decrypted traffic that also flowed through Cloudflare's proxy or Workers, the company would see both the source and the payload, collapsing the privacy guarantee the protocol exists to provide. By declining to handle those requests, Cloudflare is protecting the protocol's integrity even when it costs the company some convenience. That is a meaningful choice, especially when the same company has been expanding its platform by welcoming Deno's expertise to improve its Workers programming model. The more capable Workers become, the more tempting it must be to route everything through one stack. This gateway draws a line instead.
For developers, the practical takeaway is that privacy infrastructure works only when the operator is willing to lose visibility. A managed endpoint that decrypts for you is useful, but its value depends on who else can see what. Cloudflare is saying, in effect, that it will not be the one to rejoin the identifiers with the contents. That is a design decision with real trade-offs: it means some traffic will need to be handled by a separate relay or a different provider, and it adds friction to architectures that would otherwise centralize on Cloudflare. But the friction is the feature. If you are building with Oblivious HTTP precisely to avoid a single point of trust, you want your gateway provider to be paranoid about its own reach.
This also raises a question worth watching: will the closed beta become a broader service, and will the same refusal hold when the pressure to grow usage arrives? The easy path is to offer an exception for enterprise customers or to quietly allow Workers-based origins once the beta matures. Cloudflare's current stance suggests it understands that exception would undermine the product's reason for existing. The concrete detail to track is the documentation and pricing when the gateway goes public. If the restriction remains absolute, it signals a genuine commitment. If carve-outs appear, the privacy story becomes marketing. For now, Cloudflare has earned the benefit of the doubt, but the proof will be in the limits it keeps.