Cloudflare Workers for Platforms
Multi-tenant platform with isolated customer code execution at scale.
Use Cases
- Multi-tenant SaaS running customer code
- AI-generated code execution in secure sandboxes
- Programmable platforms with isolated compute
- Edge functions/serverless platforms
- Website builders with static + dynamic content
- Unlimited app deployment at scale
NOT for general Workers - only for Workers for Platforms architecture.
Quick Start
One-click deploy: Platform Starter Kit deploys complete WfP setup with dispatch namespace, dispatch worker, and user worker example.
Manual setup: See configuration.md for namespace creation and dispatch worker configuration.
Key Features
- Unlimited Workers per namespace (no script limits)
- Automatic tenant isolation
- Custom CPU/subrequest limits per customer
- Hostname routing (subdomains/vanity domains)
- Egress/ingress control
- Static assets support
- Tags for bulk operations
Architecture
4 Components:
- Dispatch Namespace - Container for unlimited customer Workers, automatic isolation (untrusted mode by default - no request.cf access, no shared cache)
- Dynamic Dispatch Worker - Entry point, routes requests, enforces platform logic (auth, limits, validation)
- User Workers - Customer code in isolated sandboxes, API-deployed, optional bindings (KV/D1/R2/DO)
- Outbound Worker (optional) - Intercepts external fetch, controls egress, logs subrequests (blocks TCP socket connect() API)
Request Flow:
Request → Dispatch Worker → Determines user Worker → env.DISPATCHER.get("customer")
→ User Worker executes (Outbound Worker for external fetch) → Response → Dispatch Worker → Client
Decision Trees
When to Use Workers for Platforms
Need to run code?
├─ Your code only → Regular Workers
├─ Customer/AI code → Workers for Platforms
└─ Untrusted code in sandbox → Workers for Platforms OR Sandbox API
Routing Strategy Selection
Hostname routing needed?
├─ Subdomains only (*.saas.com) → `*.saas.com/*` route + subdomain extraction
├─ Custom domains → `*/*` wildcard + Cloudflare for SaaS + KV/metadata routing
└─ Path-based (/customer/app) → Any route + path parsing
Isolation Mode Selection
Worker mode?
├─ Running customer code → Untrusted (default)
├─ Need request.cf geolocation → Trusted mode
├─ Internal platform, controlled code → Trusted mode with cache key prefixes
└─ Maximum isolation → Untrusted + unique resources per customer
In This Reference
| File | Purpose | When to Read |
|---|---|---|
| configuration.md | Namespace setup, dispatch worker config | First-time setup, changing limits |
| api.md | User worker API, dispatch API, outbound worker | Deploying workers, SDK integration |
| patterns.md | Multi-tenancy, routing, egress control | Planning architecture, scaling |
| gotchas.md | Limits, isolation issues, best practices | Debugging, production prep |
See Also
- workers - Core Workers runtime documentation
- durable-objects - Stateful multi-tenant patterns
- sandbox - Alternative for untrusted code execution
- Reference Architecture: Programmable Platforms
- Reference Architecture: AI Vibe Coding Platform