Effective immediately, Cloudflare Gateway integrates with Cloudflare Workers via a new Forward action that is available in public beta for every Zero Trust subscription. The change allows traffic that passes existing HTTP policies to be handed off to a Worker for custom processing, eliminating the need for a dedicated proxy layer and opening new automation pathways for AI, platform, DevOps, and security teams.
How the Forward Action Works
When a request matches a Forward policy, Gateway retains responsibility for the TLS termination, proxy connection, and upstream routing. After evaluating standard HTTP request policies, Gateway injects the request into the selected Worker, supplying a context object that contains connection details, the authenticated user identity, and device posture information when available. The Worker can then transform the request or response, serve a coaching page, or trigger background jobs such as Slack notifications or R2 object captures.
Architectural and Operational Implications
Because Gateway continues to perform TLS decryption and proxy duties, existing network topology and routing remain unchanged. The only new component is the Worker, which runs on Cloudflare’s edge and receives the request after the initial policy checks. The order of evaluation is important: HTTP request policies run first, then any Forward policies, and finally Gateway inspects the response before it reaches the client. This sequencing means that existing policy logic does not need to be rewritten, but engineers must account for the additional processing step when estimating latency.
Deploying a Worker is a standard Cloudflare operation; the integration does not require a separate proxy service. Practitioners can start with one of the provided Worker templates or create a custom script that consumes the forwarded request and returns a modified response.
Security Considerations
The forwarded request includes the same security context that Gateway has already gathered, such as user identity and device posture, enabling Workers to make informed decisions without re‑authenticating. However, Gateway still inspects the original request body before it reaches the Worker. If a body‑inspection rule issues a Block, the Worker is never invoked, preserving the intended security posture. Teams should review their body‑inspection policies to ensure they align with any new Worker logic that might rely on request payloads.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
- Identify traffic flows that would benefit from in‑line processing and replace external proxies with a
Forwardpolicy. - Update CI/CD pipelines to include Worker deployment steps alongside Gateway policy configuration.
- Validate that existing request‑body inspection rules still apply as expected when a Worker is introduced.
- Monitor latency and error metrics for the new Worker path to confirm that the added edge execution does not degrade user experience.