Announcing Workers for Platforms: making every application on the Internet more programmable

Beyond APIs: handing your customers the tools to build their own features

Every product team hears the same refrain from customers: "If only we could customize this one thing, we'd be able to fully commit to your product." No matter how many features you ship, the gap between what customers want and what engineering can deliver never quite closes. APIs helped bridge that gap by letting third-party code interact with your application, but they still force you to predict exactly how customers will use your product before you build the right abstractions.

Functions offer a fundamentally different approach. Instead of exposing a fixed set of operations, functions give developers the lowest-level primitives to work with, letting them define behavior from the ground up — even building their own APIs on top. The two models complement each other: a function handling an event can call an email API, create a ticket in a ticketing system, or trigger any other service.

That's the idea behind Workers for Platforms, a new tool suite for making any application programmable. The goal is to let your customers' developers bring their own logic directly into your product, opening the door to customer-led innovation at a scale that would be impossible to achieve with an in-house engineering team alone.

Removing the friction from custom integrations

For developers, the traditional path to integrating with a third-party platform is full of setup chores before any actual coding begins. You need to host your code somewhere, expose it via an external endpoint, build out an authentication schema, and manage ops to keep the service running — all before handling a single event.

When functions are embedded directly into the product you're using, the setup disappears. You just write the code.

Why programmable platforms are hard to build

Letting developers control how events execute in your product seems obvious, but obvious doesn't mean easy. Cloudflare ran into this problem five years ago while onboarding increasingly large customers onto its network. Page Rules offered URL-based behavior modification, but customers wanted to control behavior based on cookies, headers, geolocation, and more — and the engineering team couldn't keep pace with every request.

The search for a solution came down to two requirements:

1. Performance: A CDN should never introduce latency. The solution had to be so fast users wouldn't notice it was there.
2. Security: The platform had to run untrusted code safely. No one wants a breach just to offer programmability.

Serverless functions powered by containers were evaluated, but their cold-start latency was a non-starter. The answer turned out to be in the browser: Chrome's V8 engine, running on Cloudflare's servers instead of in a browser. While the approach sounds simple in retrospect, running a large multi-tenant development platform at scale is substantial work — and if maintaining that platform consumes the engineering resources you were trying to free up, the whole exercise defeats its purpose.

Cloudflare wasn't alone in wrestling with this problem. Shopify, building its next-generation programmable storefront Oxygen, needed the same capabilities: letting customers run custom storefronts with strong performance while maintaining a secure, multi-tenant environment.

"Shopify is the Internet's commerce infrastructure, with millions of merchants using the platform," said Zach Koch, product director, custom storefronts, at Shopify. "Partnering with Cloudflare, we're able to give developers the tools they need to build unique and performant storefronts. We are excited to work with Cloudflare to alleviate some complexities of building commerce experiences – like scalability and global availability – so that developers can instead focus on what makes their brand distinct."

The building blocks of a programmable platform

Working with partners like Shopify revealed another insight: developer experience is not one-size-fits-all. An e-commerce developer has different needs than a general-purpose developer, and the underlying technology should support tailored experiences rather than forcing everyone into the same mold. Since platform providers know their customers best, Workers for Platforms exposes a set of tools and APIs designed to integrate directly into the deployment flow you want to build.

Managing millions of scripts with the Tags API

Whenever a developer on your platform wants to deploy a script, your platform can call the Workers APIs to deploy a new Worker in the background. Unlike the traditional Workers offering, Workers for Platforms is built for scale — managing hundreds of thousands to millions of Workers. The Tags API adds a way to group scripts with arbitrary tags, such as a user ID, enabling bulk actions. If a user deletes their account and you need to clean up all their Workers, a single tag-based operation can handle it.

Debugging with Trace Workers

Code ships with bugs, and any platform that lets developers write code must also give them a way to find and fix errors. Trace Workers collect information about requests handled by other Workers — including logs and exceptions — and forward that data to a destination of your choosing. This enables live logging, long-term storage, or any other debugging workflow you want to offer your customers.

Here is a simple trace Worker that sends its trace data to an HTTP endpoint:

addEventListener("trace", event => {
  event.waitUntil(fetch("http://example.com/trace", {
    method: "POST",
    body: JSON.stringify(event.traces),
  }))
})

Here is an example of what the data in event.traces might look like:

[
  {
    "scriptName": "Example script",
    "outcome": "exception",
    "eventTimestamp": 1587058642005,
    "event": {
      "request": {
        "url": "https://example.com/some/requested/url",
        "method": "GET",
        "headers": [
          "cf-ray": "57d55f210d7b95f3",
          "x-custom-header-name": "my-header-value"
        ],
        "cf": {
          "colo": "SJC"
        }
      },
    },
    "logs": [
      {
        "message": ["string passed to console.log()"],
        "level": "log",
        "timestamp": 1587058642005
      }
    ],
    "exceptions": [
      {
        "name": "Error",
        "message": "Threw a sample exception",
        "timestamp": 1587058642005
      }
    ]
  }
]

Chaining Workers with Dynamic Dispatch

Early customers frequently wanted to run their own code before running their customers' code — for authentication layers, input/output sanitization, or attaching context like user or account IDs for downstream handlers. Dynamic Dispatch lets you maintain your own Worker that, when finished executing, calls the next Worker containing your customer's code.

Example:

let user_worker = dispatcher.get('customer-worker-123');
let response = await user_worker.fetch(request);

Custom domains and more

Workers for Platforms can also be combined with Cloudflare for SaaS to create custom domains for your customers' deployments. The initial feature set is only the beginning — the goal is to provide all the tools needed to build a full platform.

Getting started

Interested parties can fill out the Workers for Platforms form to discuss their use case and get set up with the necessary tools. Meanwhile, developer docs and the Discord community are open for those who want to explore before applying.

The underlying problem is one Cloudflare solved for itself five years ago when it launched Cloudflare Workers, giving customers the ability to program its global network. That move let the engineering team focus on turning the most requested customizations into features, and the hope is that Workers for Platforms will enable other companies to do the same — and that the use cases developers dream up will surprise even the platform builders themselves.