Cloudflare announces OHTTP Gateway closed beta

Cloudflare has announced a closed beta of its managed OHTTP Gateway, intended to let application backends handle requests without seeing users’ IP addresses. The company describes the service as a planned paid zone add-on and is collecting waitlist registrations for launch notifications. It is also renaming Privacy Gateway, its existing relay product, to Cloudflare OHTTP Relay. Cloudflare’s announcement

Managed cryptography, familiar backend traffic

Oblivious HTTP divides request handling between a relay and a gateway. The relay sees client network identifiers but forwards encrypted requests; the gateway decrypts requests for the application and encrypts responses. The intended privacy boundary depends on the relay operating independently of—and not colluding with—the gateway and application side. Architecture overview

According to Cloudflare, its gateway supports standard and chunked OHTTP at a zone’s /.well-known/ohttp-gateway endpoint and manages the necessary Hybrid Public Key Encryption (HPKE) keys. Clients can obtain the public-key configuration through GET requests to that endpoint. Non-OHTTP requests continue to the application without invoking the gateway. Implementation details

For backend teams, that division of responsibility moves gateway cryptography and key management into the managed service while leaving the application to handle ordinary HTTP. It does not eliminate client integration: developers still need an OHTTP client that obtains the gateway’s public-key configuration and constructs encrypted requests. Client and key-management guidance

Relay placement is an architectural requirement

Cloudflare pairs its gateway with a third-party relay. The company says the gateway will refuse to decrypt requests sent from Cloudflare Workers or Cloudflare-proxied hosts, guarding against deployments that put both hops on Cloudflare. That restriction concerns incoming relay traffic: the announcement explicitly identifies application backends on Cloudflare’s CDN or Workers as a use case for the gateway. The alternative is Cloudflare’s relay paired with a customer-operated gateway. Deployment options and restrictions

Authentication is another deployment decision. Cloudflare says Access policies run before gateway decryption, allowing teams to authenticate incoming relay traffic using options such as mutual TLS. Teams evaluating the beta should choose a relay operator and plan abuse controls around the backend’s reduced visibility into individual clients. They should also audit request payloads separately: Cloudflare cautions that OHTTP provides network-level privacy but does not remove identifying information, such as email addresses or usernames, from the request body. Authentication and privacy guidance