The gap: privacy infrastructure with a missing half
If your app’s servers already run behind Cloudflare, OHTTP has been awkward to adopt. The relay half was easy — Cloudflare has offered one since 2022 under the name Privacy Gateway — but the gateway half, the component that decrypts the encrypted requests, had to be something you built and operated yourself. And if Cloudflare hosted both your relay and your servers, you’d break the protocol’s core promise: no single party should see both who the user is and what they sent.
On October 2, 2026, Cloudflare announced a closed beta for the Cloudflare OHTTP Gateway, a self-serve, paid add-on that handles the gateway role for you. The old relay product gets renamed Cloudflare OHTTP Relay, making the split clearer. According to the announcement, customers can enable the Gateway on their zone with a few clicks and join a waitlist ahead of general availability.
The double-blind model, in one paragraph
OHTTP is an IETF standard that splits a normal request across two independently operated hops. A relay sees the client’s IP address and TLS fingerprint but forwards only ciphertext, stripped of identifiers. A gateway sits between the relay and your app server, decrypting requests and encrypting responses using Hybrid Public Key Encryption, so your server handles plain HTTP and never learns who the client is. No party sees both identity and content — Apple’s Private Cloud Compute uses exactly this pattern to decouple AI inference requests from user identities.
What the managed gateway changes for builders
Cloudflare says the gateway runs on every server in its edge network via anycast, so relay-to-gateway hops stay short. If your origin is on Cloudflare’s CDN or Workers, decryption and origin resolution can happen on the same hardware, cutting gateway-to-origin latency. Clients send well-formed OHTTP requests to a /.well-known/ohttp-gateway endpoint on your zone; regular HTTP traffic passes through untouched, and both standard and chunked OHTTP are supported.
A few design decisions address pain points Cloudflare saw relay customers hit when self-hosting:
- Key management is fully managed — public HPKE keys are served at the well-known endpoint, so clients can fetch them without you rolling crypto infrastructure.
- Relay authentication runs through Cloudflare Access policies (mutual TLS, service credentials, custom logic) before decryption, so you can gate which relays may send traffic.
- Abuse is scoped by zone: a client can hit subdomains of your zone but can’t pivot your gateway at third-party domains.
- To protect the trust separation, the Gateway will refuse to decrypt requests originating from Cloudflare Workers or proxied Cloudflare hosts — a guardrail against accidentally running both halves on one operator.
Picking a side of the split
The decision rule from the announcement is straightforward. Servers off Cloudflare and willing to run your own gateway? Use the OHTTP Relay and self-host the gateway side. Servers behind Cloudflare’s CDN or Workers, or accepting OHTTP traffic from a third-party client like Apple’s LiveCallerID? The Gateway is the fit, because Cloudflare can’t operate both hops for the same traffic without breaking the privacy model.
This matters beyond privacy apps. As more agent and AI traffic flows through intermediaries — a theme I touched on when looking at Cloudflare’s AI Gateway search tooling — the question of which infrastructure layer learns what about the user keeps coming up. OHTTP gives you a standards-based answer, and a managed gateway lowers the cost of actually implementing it.
One practical caveat
Network-level anonymity is all OHTTP buys you. As Cloudflare’s own post notes while pointing builders to client libraries, OHTTP doesn’t hide what’s inside the request payload — if your API requires accounts, tokens, or identifiable content, that linkage travels with the plaintext. Treat the Gateway as one layer: it removes IP and fingerprint linkage from your server’s view, not the need to think about what your application itself logs and stores. If you’re experimenting, the waitlist registration plus the sample OHTTP client library are the concrete starting points.