What changed
On October 15, 2026, Cloudflare launched a public beta of the Forward action in Cloudflare Gateway, integrating customer-written Cloudflare Workers into the path of permitted HTTP traffic. The Worker receives a Request and Gateway context, can modify request headers or bodies, call next() to continue to the original destination, modify the response or return a synthetic response. Cloudflare also announced DLP custom validation functions that can check detected data against an external source of truth. A separate Custom Functions feature that returns typed values to Gateway policy selectors is planned before the end of 2026 and is not yet generally available.
Why it matters
Organizations previously had to maintain their own HTTP proxies, SIEM-to-webhook chains or bespoke gateways to add app-specific decisions and transformations to web-security traffic. Forward lets builders put that logic into the Workers platform beside the Gateway that already enforces identity, device and destination policies. For small teams this can remove an infrastructure tier and enable immediate alerts or tailored user interstitials. But moving custom code into the policy path also introduces application failure modes, usage costs and inspection-order limitations that require testing before broad deployment.
Forward is an inline Worker on already-permitted HTTP traffic
Gateway evaluates its HTTP request policies before Forward. A Block action prevents Worker invocation; the first matching Forward rule dispatches permitted traffic to its bound Worker. Gateway handles TLS termination, routing and upstream connections. A Worker can transform the request, call next(request) once to reach the original destination, inspect and transform the response, or return a response without calling upstream. It can also schedule notifications or R2 writes. Cloudflare says the dispatch occurs locally within its network rather than requiring a round-trip to an external proxy.
Security policy still controls the traffic — and inspection order matters
Forward does not override Gateway Block policies. The original request body is inspected before it reaches the Worker, and Gateway inspects the final response, including synthetic responses. However, modified request bytes are not re-inspected by request-side DLP before being sent upstream. A body-inspection Block can interrupt a Worker that has already started. Workers must not assume that their own fetch() subrequests inherit the user's Gateway egress configuration or policies; next() preserves the original destination path. WebSocket traffic bypasses the Worker. These constraints make the design more than a generic reverse-proxy drop-in.
Custom DLP validation is distinct from future policy selectors
Cloudflare also supports custom DLP validation functions that dispatch to Workers to verify whether a detected pattern is actually sensitive, such as checking whether a token is live before blocking a request. Separately, Gateway Custom Functions will call Workers during policy evaluation and expose their returned string, number or boolean as a policy selector. Cloudflare expects those selectors before the end of 2026; they are not part of the Forward public beta available today. Teams should not plan a production policy that depends on this unshipped selector feature.
Availability, limits and pricing
The Forward public beta is available across Cloudflare Zero Trust plans. Its Worker executions are billed using standard Workers request pricing, including the Free tier's execution and daily request limits. The announcement says both Forward and future Custom Functions will be available across plan types at general availability. This is not a promise of free, unlimited per-request processing; operators should model request volumes and latency under their own code and test fallback behaviour.