Cloudflare is launching a managed Oblivious HTTP (OHTTP) Gateway service, available as a paid add-on to customer zones. OHTTP is an IETF standard that routes HTTP requests through two independent hops — a relay and a gateway — so that no single party sees both user identity and request content. The relay sees the client's IP address but only encrypted payloads; the gateway decrypts requests but never sees who sent them. Cloudflare already runs the relay side (formerly called Privacy Gateway, now renamed Cloudflare OHTTP Relay). The new gateway product completes the pair. The structural problem being solved is real. In a standard client-server exchange, app servers learn client IP addresses, TLS fingerprints, geolocation, and enough metadata to link requests back to individual users. OHTTP's "double-blind" model splits this knowledge across two non-colluding parties. The relay strips client identifiers before forwarding; the gateway handles decryption using Hybrid Public Key Encryption (HPKE). App servers receive plain HTTP and never touch the cryptographic layer. Cloudflare's pitch centers on three pain points. First, building a performant OHTTP gateway is genuinely hard — the cryptographic overhead plus the extra network hop introduces latency that homegrown implementations struggle to manage. Second, Cloudflare's anycast architecture means the gateway runs on every edge server globally, minimizing relay-to-gateway latency. If the origin is also on Cloudflare's CDN or Workers, decryption and request handling can happen on the same metal, eliminating gateway-to-origin hops entirely. Third, customers who already protect their servers behind Cloudflare couldn't use Cloudflare's relay product without breaking OHTTP's trust model — the same company would see both sides. The gateway product resolves this by letting customers pair a Cloudflare gateway with a third-party relay. Existing deployments illustrate the use case. Flo Health uses OHTTP for an Anonymous Mode that lets users access personal health data without linkable identifiers. Apple's Private Cloud Compute uses OHTTP to disassociate AI inference requests from user identities, and Apple's LiveCallerID is listed as a potential gateway customer. These are high-sensitivity applications where the privacy architecture is load-bearing, not decorative. The product supports both standard and chunked OHTTP, with chunked recommended for better performance through incremental processing. Onboarding is designed to be minimal — enable the gateway on your zone, point clients to a .well-known/ohttp-gateway endpoint, and Cloudflare handles scaling. Non-OHTTP requests pass through untouched. The gateway also inherits zone-level abuse protections. The business model is straightforward infrastructure rent: a paid add-on to existing Cloudflare zones, currently in closed beta with a waitlist. This follows Cloudflare's established pattern of turning open standards into managed services — they did the same with DNS (1.1.1.1), WARP, and their contributions to iCloud Private Relay. The question is whether OHTTP adoption reaches sufficient scale to matter, or whether it remains a niche tool for privacy-first apps. The broader bet is that privacy will shift from user-side bolt-ons (VPNs, adblockers, cookie toggles) to developer-side infrastructure defaults. If Cloudflare makes OHTTP adoption trivial, the standard has a real shot at broader deployment. If the friction remains too high or demand stays concentrated in a few high-profile integrations, this becomes a nice feature rather than a platform shift.
