A Year of Workers for Platforms

Nearly a year after launching Workers for Platforms, Cloudflare's offering for SaaS businesses is seeing adoption across a broad range of use cases. From e-commerce and CMS platforms to low-code/no-code tools and AI companies running tailored inference models, the service has found a niche as a way to embed customizable compute at the edge. The core premise remains: give platforms the ability to let their own developers deploy code without managing the underlying infrastructure.

The architecture relies on Dynamic Dispatch, which allows platform customers to run their own Worker—for authentication, request enrichment, or other custom logic—before any end-user Worker executes. This approach was shaped in collaboration with early partners like Shopify, whose Oxygen hosting platform for Hydrogen storefronts runs on Workers, and Grafbase, which uses it to deploy serverless GraphQL backends and customer-authored resolvers in JavaScript/TypeScript or WebAssembly.

To extend visibility and control beyond the incoming request path, Cloudflare has now released three new features in open beta for Workers for Platforms users.

Outbound Workers

Dynamic Dispatch provides insight into all incoming requests, but platforms also need to see what their user Workers are sending out. Outbound Workers sit between a user Worker and its fetch() requests to the Internet, giving platform operators a hook for:

  • Logging all subrequests to identify malicious hosts or abnormal usage patterns
  • Maintaining allow or block lists for hostnames that user Workers can reach
  • Handling API authentication credentials behind the scenes, so end developers don't have to set them

When a user Worker makes an outbound request, a FetchEvent is triggered on the configured Outbound Worker. To help identify the source, platform customers can declare variables in the dispatch namespace binding, which are then accessible in the Outbound Worker via env.<VAR_NAME>.

Custom Limits

As a platform, you may want to place guardrails on Worker capabilities to fit your pricing or packaging model. Custom Limits let you cap CPU time and the number of subrequests on your customers' Workers. These limits are set from within the Dynamic Dispatch Worker, making them fully scriptable, and can be combined with script tags to apply different tiers based on customer plans.

Both Outbound Workers and Custom Limits are configured programmatically in the Dynamic Dispatch Worker, allowing platforms to layer additional custom logic on top.

Tail Workers

Live logging is a staple of the developer experience, and Cloudflare is now extending it to platform users. Tail Workers capture logs from both the Dynamic Dispatch Worker and any user Workers it invokes. The logs include metadata about the original trigger event—such as the incoming URL and status code for fetches—along with console.log() messages and any unhandled exceptions.

Adding a Tail Worker involves configuring the producing script in wrangler.toml and handling events with a new tail handler. Tail Workers are full-fledged Workers themselves, so events can be forwarded to any HTTP endpoint—for example, a logging service that parses and delivers real-time logs back to your customers.

Workers for Platforms remains an enterprise-only product for now, but Cloudflare plans to bring it to pay-as-you-go plans later this year. Interested developers can explore the feature set—Outbound Workers, Custom Limits, and Tail Workers—in the official documentation.