Cloudflare has moved its Gateway and Workers integration into public beta, available on all Zero Trust plans, according to the company's changelog entry. The change gives administrators a new Forward action inside Gateway HTTP policies that executes customer-authored Worker code against traffic that matches a policy and is permitted to proceed, without the team having to stand up and operate a separate proxy.
The mechanism is split between two systems. Gateway continues to own the network-side responsibilities: it terminates the proxy connection, performs TLS decryption, and routes requests upstream. The Worker, by contrast, receives the request together with Gateway context. That context includes connection metadata, user identity, and device posture where that posture information is available, which means the code running on the traffic can make decisions using more than the raw HTTP request.
Policy evaluation order is documented in the changelog. Gateway evaluates HTTP request policies before it evaluates Forward policies, and after the Worker has run, Gateway inspects the final response before that response is returned to the user. This ordering matters for anyone designing a Forward policy: the request must first survive the ordinary policy checks, and the response is subject to a further inspection pass on the way back.
The changelog describes several intended uses for the Forward action. A Worker can transform HTTP requests and responses, return a coaching page to the user, or run background tasks — the examples given are Slack notifications and captures to R2. These are the vendor's stated capabilities rather than independently verified behaviours, and the entry does not describe performance characteristics, latency, or limits on what a Worker may do within the Forward path.
One documented interaction deserves attention because it constrains what a Forward policy can accomplish. Gateway inspects the original request body before delivering it to the Worker, and a body-inspection Block decision can interrupt the Worker. In other words, a request that Gateway's body inspection decides to block may never reach the customer's code, so a Forward policy cannot be relied upon to see every request that matches its filter.
The entry also states that the integration is in public beta, which is a maturity signal rather than a stability guarantee. The changelog does not state a general-availability date, does not describe pricing specific to the integration, and does not enumerate plan-level feature differences beyond saying it is available on all Zero Trust plans. Teams evaluating it should treat the beta label as the vendor's own description of the release stage.
For freelancers and small studios that build or maintain client infrastructure, the practical appeal is consolidation. A Forward policy means the proxy layer and the custom logic layer are configured in the same Zero Trust environment rather than in two separate systems, which reduces the number of moving parts a solo operator has to document and hand over. The documented ability to return a coaching page is also relevant to client-facing security work, where the alternative is often a generic block screen.
Developers should note that the Worker is not a general-purpose interception point. Because Gateway performs TLS decryption and upstream routing, the Worker operates inside a pipeline the customer does not control end to end, and because request-body inspection runs first, some traffic will be filtered before the Worker is invoked. Any design that assumes the Worker sees all matching traffic is not supported by the changelog.
The context passed to the Worker is another design consideration. Connection metadata, user identity and device posture are described as available inputs, with posture qualified as available only when it exists. Code that branches on posture therefore needs a defined behaviour for the case where posture is absent, and the changelog does not specify what that absence looks like in practice.
Two descriptions of onboarding are given: either a Worker gets deployed alongside configuration of a Forward policy, or one of the supplied Worker templates is adapted. For teams lacking existing Worker code, the templates represent the path requiring less effort and will probably serve as the starting point; however, the entry fails to state how many templates there are, what purpose each serves, or which language and runtime constraints are in effect.
The changelog does not address several questions a production deployment would raise. There is no stated rate limit, no described failure mode when a Worker errors or times out, no statement about whether Worker execution adds measurable latency to inspected traffic, and no detail on logging or observability for Forward actions. Those gaps are not evidence that the features are absent — only that the supplied source does not document them.
It is also worth separating what is new here from what is not. Gateway's policy engine, TLS decryption and upstream routing are described as existing responsibilities that the integration reuses; the new element is the Forward action and the Worker execution path attached to it. Readers should not read the entry as announcing a new proxy or a new inspection engine.
For this audience, the sensible next step is a scoped trial rather than a migration. A freelancer maintaining a handful of client Zero Trust deployments could deploy one Worker against a narrow, low-risk policy, confirm how the request-body inspection interaction behaves on real traffic, and only then consider moving coaching pages or notification workflows onto the Forward path. That framing is editorial judgement, not a vendor recommendation.
The main limitation of this report is the source itself. Everything above rests on a single Cloudflare changelog entry; there is no independent testing, no third-party documentation, and no pricing or SLA detail in the supplied material. Claims about what the Forward action can do are the vendor's, and the beta status means behaviour may change before general availability.