{
  "version": "2",
  "id": "https://freelancenews.online/news/cloudflare-puts-gateway-and-workers-integration-into-public-beta-on-2832f530",
  "title": "Cloudflare puts Gateway and Workers integration into public beta on all Zero Trust plans",
  "summary": "The Forward action in Gateway HTTP policies lets teams run their own Worker code on permitted traffic, with Gateway handling proxying, TLS decryption and upstream routing — and with request-body inspection able to interrupt the Worker.",
  "body": "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.\n\nThe 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.\n\nPolicy 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.\n\nThe 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.\n\nOne 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.\n\nThe 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.\n\nFor 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.\n\nDevelopers 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.\n\nThe 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.\n\nTwo 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.\n\nThe 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.\n\nIt 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.\n\nFor 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.\n\nThe 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.",
  "category": "dev",
  "language": "en",
  "datePublished": "2026-10-15T17:17:28.532Z",
  "dateModified": "2026-10-15T17:17:28.532Z",
  "eventDate": "2026-10-15",
  "sourcePublicationDate": "2026-10-15T00:00:00.000Z",
  "source": {
    "name": "developers.cloudflare.com",
    "url": "https://developers.cloudflare.com/changelog/post/2026-10-15-gateway-workers-public-beta/",
    "kind": "official-publisher"
  },
  "practicalImpact": "For freelancers and small teams running client Zero Trust setups, the integration reduces the number of separate systems to configure and hand over: custom logic and proxy policy live in the same environment. The documented coaching-page capability is directly useful for client-facing security UX. However, because request-body inspection runs before the Worker and can interrupt it, and because the release is a beta with no stated pricing or failure-mode detail, the prudent approach is a narrow trial on low-risk policies rather than migrating existing workflows.",
  "limitations": "All information comes from a single Cloudflare changelog entry. No independent testing or third-party documentation was supplied. The entry does not state a general-availability date, integration-specific pricing, rate limits, Worker error or timeout behaviour, latency impact, or logging and observability details. The number and content of the referenced Worker templates are not described. Capability claims are the vendor's own, and beta behaviour may change.",
  "keyPoints": [
    "Cloudflare's Gateway and Workers integration is in public beta on all Zero Trust plans, per the vendor changelog.",
    "A new Forward action in Gateway HTTP policies runs customer Worker code on matching, permitted traffic without a separate proxy.",
    "Gateway handles proxying, TLS decryption and upstream routing; the Worker receives the request plus Gateway context such as connection metadata, user identity and device posture when available.",
    "Gateway evaluates HTTP request policies before Forward policies and inspects the final response before returning it to the user.",
    "Gateway inspects the original request body before handing it to the Worker, and a body-inspection Block decision can interrupt the Worker."
  ],
  "review": {
    "status": "source-reviewed",
    "checkedAt": "2026-10-15T17:17:28.532Z",
    "method": "Automated comparison against retrieved source text; not independent fact-checking.",
    "correctionNote": null
  },
  "sources": [
    {
      "id": 1,
      "url": "https://developers.cloudflare.com/changelog/post/2026-10-15-gateway-workers-public-beta/",
      "publisher": "developers.cloudflare.com",
      "title": "Changelog",
      "publishedAt": 1792022400000,
      "fetchedAt": 1792084630684,
      "hash": "837812cb27217e93d8d324cccaa2b8a0784754920d72f9ea499df50853a2c255",
      "kind": "official-publisher"
    }
  ],
  "claims": [
    {
      "claim": "Cloudflare's Gateway and Workers integration entered public beta on all Zero Trust plans.",
      "source": 1,
      "id": "claim-1",
      "url": "https://freelancenews.online/news/cloudflare-puts-gateway-and-workers-integration-into-public-beta-on-2832f530#claim-1"
    },
    {
      "claim": "The Forward action in Gateway HTTP policies runs customer code on matching, permitted traffic without a separate proxy.",
      "source": 1,
      "id": "claim-2",
      "url": "https://freelancenews.online/news/cloudflare-puts-gateway-and-workers-integration-into-public-beta-on-2832f530#claim-2"
    },
    {
      "claim": "The Forward action can transform requests and responses, return a coaching page, or run background tasks such as Slack notifications and R2 captures.",
      "source": 1,
      "id": "claim-3",
      "url": "https://freelancenews.online/news/cloudflare-puts-gateway-and-workers-integration-into-public-beta-on-2832f530#claim-3"
    },
    {
      "claim": "The Worker receives the request and Gateway context including connection metadata, user identity and device posture when available.",
      "source": 1,
      "id": "claim-4",
      "url": "https://freelancenews.online/news/cloudflare-puts-gateway-and-workers-integration-into-public-beta-on-2832f530#claim-4"
    },
    {
      "claim": "Gateway evaluates HTTP request policies before Forward policies and inspects the final response before returning it to the user.",
      "source": 1,
      "id": "claim-5",
      "url": "https://freelancenews.online/news/cloudflare-puts-gateway-and-workers-integration-into-public-beta-on-2832f530#claim-5"
    },
    {
      "claim": "Gateway inspects the original request body before delivering it to the Worker, and a body-inspection Block decision can interrupt the Worker.",
      "source": 1,
      "id": "claim-6",
      "url": "https://freelancenews.online/news/cloudflare-puts-gateway-and-workers-integration-into-public-beta-on-2832f530#claim-6"
    }
  ],
  "formats": {
    "html": "https://freelancenews.online/news/cloudflare-puts-gateway-and-workers-integration-into-public-beta-on-2832f530",
    "markdown": "https://freelancenews.online/news/cloudflare-puts-gateway-and-workers-integration-into-public-beta-on-2832f530.md",
    "json": "https://freelancenews.online/news/cloudflare-puts-gateway-and-workers-integration-into-public-beta-on-2832f530.json"
  }
}