know.2nth.aiTechnologytechcloudflareWorkers for Platforms
Technology · Cloudflare · Skill Node

Workers for
Platforms.

Multi-tenant execution for SaaS builders. Let your customers deploy their own Workers inside your Workers, with per-tenant isolation, routing, and resource limits. The "platform-of-platforms" primitive.

TechnologyMulti-tenantOpen TierLast updated · Apr 2026

Run customer code inside your code, safely.

Workers for Platforms lets you upload and execute Workers scripts on behalf of your customers. Each customer's script runs in its own V8 isolate with its own resource limits, routed by a dispatch namespace. Your platform Worker acts as the router — it receives the request, decides which customer script to invoke, and dispatches to it.

The model is: your SaaS product exposes a "custom code" surface (webhooks, plugins, automation scripts). Instead of building a sandboxed runtime from scratch, you use Cloudflare's isolate infrastructure. Shopify, Grafana, and others already do this.

You get per-script CPU limits, separate KV/D1/R2 namespaces per tenant, and Cloudflare handles the isolation. The alternative — running customer code in a shared Node.js process — is a security incident waiting to happen.

Dispatch namespaces and dynamic dispatch.

01

Dispatch namespace

A dispatch namespace is a collection of customer scripts. You upload scripts to it via the API, and your router Worker dispatches requests to the correct script by name.

# wrangler.toml — platform router
name = "platform-router"
main = "src/router.ts"

[[dispatch_namespaces]]
binding = "CUSTOMERS"
namespace = "customer-scripts"
02

Dynamic dispatch from the router

Your router Worker extracts the tenant ID from the request (subdomain, header, path) and dispatches to the customer's script. The customer script runs in its own isolate.

export default {
  async fetch(req, env) {
    // Extract tenant from subdomain
    const url = new URL(req.url);
    const tenant = url.hostname.split('.')[0];

    // Dispatch to the customer's Worker script
    const customerWorker = env.CUSTOMERS.get(tenant);
    return customerWorker.fetch(req);
  }
};
03

Uploading customer scripts

Customer scripts are uploaded via the Cloudflare API. Each script gets its own bindings, resource limits, and compatibility settings.

# Upload a customer script to the dispatch namespace
curl -X PUT \
  "https://api.cloudflare.com/client/v4/accounts/{id}/workers/dispatch/namespaces/customer-scripts/scripts/{tenant}" \
  -H "Authorization: Bearer $CF_TOKEN" \
  -F "[email protected]" \
  -F "metadata={\"bindings\":[...]}"

Where it bites you.

Enterprise gate

Requires Enterprise plan

Workers for Platforms is an Enterprise feature. There's no self-serve path. If you're building a startup that needs this, talk to Cloudflare sales early.

Script limits

Per-namespace script limits

There's a maximum number of scripts per dispatch namespace. For large multi-tenant platforms (thousands of tenants), plan your namespace partitioning strategy upfront.

Binding isolation

Customer bindings need careful scoping

If you give customer scripts access to KV or D1, make sure each tenant gets its own namespace. A misconfigured binding leaks data across tenants.

When it fits. When it doesn't.

✓ Use it when
  • Your SaaS needs a "custom code" surface. Webhooks, plugins, automation scripts, custom pricing logic — anything where customers want to run their own code.
  • You need per-tenant isolation without managing infrastructure. V8 isolates give you sandboxing without containers, VMs, or firecracker.
  • You're building a platform that hosts other platforms. The dispatch model scales to thousands of tenants with independent deploy cycles.

Where this node connects.

Go deeper.