For modern internet-facing apps, Cloudflare gives developers a focused, integrated set of primitives that compose globally by default — full-stack apps, AI agents, APIs, and real-time systems, all on the same network that already handles your security and delivery.
Code is cheaper. App count goes up. The bottleneck moves from writing software to running it safely, globally, and without infrastructure glue.
Absorb the spike. Give every app platform services. Scale to zero when the work disappears.
More apps only helps if the runtime keeps up. Which parts of your stack are paying a global tax because they were built for a single region?
Cloudflare's developer platform inherits the same global network architecture as its security and CDN edge. Workers run as V8 isolates across 330+ cities, within ~50 ms of ~95% of the Internet-connected population — no region selection required. Auth, routing, API validation, transforms, and cache logic run at the DDoS/WAF perimeter, before traffic reaches your origin.
One box, one app, operational ownership of OS, runtime, packages, and capacity.
Better isolation and scheduling, but each unit still carries a lot of runtime surface.
Process-level isolation. Slow cold starts (500ms-10s). Heavy context switching overhead between customer workloads.
Lightweight execution contexts inside a shared V8 runtime. One process can run thousands of isolates with minimal per-request overhead.
Lightweight compute is the start, not the whole platform. The real leverage appears when storage, AI, media, and orchestration are native bindings.
Most clouds wire services together with SDKs, roles, networks, gateways, discovery, and certificates. Cloudflare bindings are capability handles delivered directly into the Worker runtime — no secrets in app code, no internal gateway, no extra network hop. Service Bindings split Workers without public APIs or duplicate request billing.
env object
Declare a binding in your Worker configuration, access it via env.BINDING_NAME in your code. The runtime injects all bindings into env before your code executes.
await env.DB
.prepare("SELECT * FROM users")
.all();
await env.BUCKET
.put("file.pdf", data);
await env.AI.run(
"@cf/meta/llama-3.1-8b",
{ messages: [...] }
);
await env.VECTOR_INDEX
.query(embedding,
{ topK: 5 }
);
await env.AUTH_WORKER
.fetch(request);
await env.QUEUE
.send({ userId: 123 });
env.OTHER_WORKER.fetch(). On Workers Standard, that call doesn't add a request to your bill — CPU time across both Workers is aggregated into one invocation.This is the mental model to land: Workers is not isolated from the platform. It is the place where the platform is composed.
Once the platform is available inside the Worker, the same model can host websites, APIs, tenant code, agents, storage-backed apps, and media workflows.
Workers becomes the deployment target for modern web applications: server-rendered routes, APIs, static assets, and edge logic all living close to users.
detectnpx wrangler setup --dry-run
# inspect adapter + config changes
configurenpx wrangler setup
# install adapter and generate config
deploynpx wrangler deploy
# deploy the framework app to Workers
scaffoldnpm create cloudflare@latest -- my-app
# start from a Worker or framework template
Workers is not only JavaScript. JavaScript and TypeScript run directly on V8. Python Workers are first-class, and systems languages can target WebAssembly when they need a portable runtime boundary.
The most frictionless path for edge applications: no separate server process, just request handlers running in the Workers runtime.
A first-class Python experience on Workers. CPython runs via Pyodide inside V8 isolates, with deploy-time snapshotting to reduce startup cost and no separate precompile step.
uvx --from workers-py pywrangler init
uv run pywrangler dev
Framework adapters map server concepts onto the Workers Request/Response runtime. Languages that compile to Wasm can run inside the isolate; apps that need lower-level OS features can use Containers.
Cloudflare Containers run Docker images and full Linux environments alongside Workers. The Worker stays on the request path — the Container handles work that needs OS-level access, custom runtimes, heavier CPU, or filesystem.
Deployment lifecycle — scaffold, bind, run locally, preview in CI, deploy to production.
Create a Worker or framework app with C3 — Create Cloudflare CLI.
npm create cloudflare@latestAdd platform resources as bindings, then use them from env — for example env.DB, env.AI, or env.BUCKET.
bindings → env.DB / env.AI / env.BUCKETRun local development with Miniflare simulating Workers, KV, D1, and more without deploying to the edge. For frontend apps, tools like Vite give you a fast dev loop.
wrangler dev
vite devYour CI/CD runner — GitHub Actions, GitLab CI, or Bitbucket Pipelines — runs tests, then creates a preview review URL.
wrangler deploy --env previewMerge to main; CI deploys with a scoped API token. Developers do not need production credentials.
CLOUDFLARE_API_TOKEN
wrangler deploy --env production[env.preview] and [env.production].Hyperscalers are strong for model training and big AI infrastructure. The harder question for many teams is putting AI safely into production apps, globally, with the flexibility to switch providers.
Workers handle the stateless fetch layer. Durable Objects supply the actor model — unique ID, serialized execution queue, co-located SQLite. Agents SDK wraps that into a typed agent abstraction. Sandbox and Browser Run extend the tool surface without widening your Worker's trust boundary.
A Worker handles the event. A Durable Object gives the agent identity. Capabilities stay behind explicit boundaries.
One V8 isolate per invocation. Events arrive via fetch(), WebSocket, MCP, or schedule. Services injected as env.* — no shared state.
One Durable Object per session. idFromName() pins every call to one actor — private SQLite, serialized queue, hibernatable WebSocket.
AI Gateway · Workers AI · Sandbox SDK · Browser Run · Dynamic Workers — each behind an explicit dispatch boundary. A failing tool cannot crash the agent.
Durable identity, persistent state, real-time connections, scheduled work
Agents SDK wraps a Durable Object into a typed Agent class. Each instance has a stable identity via idFromName(), private embedded SQLite (this.sql), and this.setState() which persists state and broadcasts it to connected JS/React clients. Schedules are persisted and wake the agent for callbacks — no continuous process required. Durable state survives eviction; plain in-memory variables do not. Agents SDK docs →
Isolated code execution — commands, files, processes, preview URLs
Sandbox SDK gives agents an isolated Linux container for executing untrusted or generated code. Persistent interpreters keep state across calls — good for agents, CI runners, cloud REPLs, and data analysis pipelines.
Parent Worker → env.LOADER.load() → isolated child Workers
Dynamic by design: the Parent Worker loads isolated child Workers for AI-generated code and passes only the interfaces it chooses. Bindings pass handles, not code — the child receives a stub; calling a method delegates execution into the parent's isolate and returns the result. No ambient env access, no secrets shared.
Headless Chrome on Cloudflare's network — screenshots, PDFs, structured data
Browser Run provides headless Chrome via a Worker binding. Use quickAction() for instant captures or full Puppeteer/Playwright/CDP/Stagehand sessions. Live View and session recording are available for human-in-the-loop workflows.
The Agent handles the conversation. The Workflow handles the job.
The Agent keeps the conversation responsive while Workflows runs the background job in durable steps. Completed step results are saved, failed steps can retry, and the job can pause for human approval before continuing. Progress updates flow back to the Agent, so the user stays informed without waiting for the whole job to finish.
Agents run your code. Workers for Platforms turns the runtime into a product — your customers deploy their own isolated Workers through your API.
"When your product is other people's apps." Workers for Platforms lets you expose the Workers runtime as a programmable execution layer — your customers deploy isolated Workers through your API, you control the boundaries.
Three primitives, one dispatch model: your Dispatch Worker receives requests
→ calls env.DISPATCHER.get(workerName)
to resolve a User Worker by name → proxies into an isolated V8 isolate containing only the code and bindings you granted.
How requests find the right User Worker — path · subdomain · KV lookup · custom metadata
/api/:name → DISPATCHER.get(name)client-a.yourplatform.com → client-a-workerawait KV.get(tenantId) → workerNameworker.userMetadata.plan === "pro"What the platform controls for every User Worker — bindings · outbound worker · limits · observability
fetch() calls from User Workers pass through your Outbound Worker — enforce allowlists or block egress entirelyHow dispatch works in three steps
wrangler.jsonc — the runtime injects it as env.DISPATCHER, a typed handle to every User Worker in your namespace.
{
"dispatch_namespaces": [
{ "binding": "DISPATCHER", "namespace": "my-platform" }
]
}
workerName from the request — URL path, hostname, a KV lookup, or metadata attached to the worker at deploy time.
const userWorker = env.DISPATCHER.get(workerName);
return userWorker.fetch(request);
User Workers are deployed programmatically via the Cloudflare API — no Wrangler required on the customer side.
Every Worker — yours or your customers' — needs data. The platform exposes storage as bindings: pick the shape that fits the access pattern.
Different access patterns deserve different storage. The platform exposes each
primitive as a Worker binding, so the same code path can read from key/value,
SQL, objects, an existing relational database, or strongly consistent per-key state.
Declare the binding once and use it directly from env —
No API keys in code, no secret handling, no manual connection plumbing.
The runtime gives your Worker the right pre-authenticated object before the request runs.
env.KV.get(key)env.DB.prepare(sql)env.BUCKET.put(key, body)
Deep dive →
env.VECTOR_INDEX.query(embedding)env.HYPERDRIVE.connectionStringenv.ROOMS.get(id)Not every workload starts as a full-stack app. Some begin as one route, one API, or one integration point.
Workers can be a single request handler, a structured API, or a backend that sits in front of other services. You choose how much framework you need.
The point is optional structure: start with the smallest Worker that solves the job, then add routing, middleware, or language ecosystems only when the API earns it.
fetch(request). Great for webhooks, auth checks, redirects, and small APIs.Put it together — compute, AI, storage, media, network, orchestration. This is what changes when "serverless" becomes "platform".
Compute is the start, not the product. The product is what you can compose around it — inference next to data, retrieval next to context, state next to coordination, the CDN and WAF already in the request path. That is the platform Workers ships.
Cloudflare global network sits in front of every Worker
CDN · DDoS · WAF · Bot management · Smart Routing · Tiered Cache · Zero Trust · Access & more
Every request reaches your Worker through Cloudflare's network first — global delivery, security, routing, caching, and access controls already in the path.
Focused builder community · Close product feedback loop · Faster collaborative adoption
Where Cloudflare fits
Hyperscalers are broad. Cloudflare is focused on global, secure, edge-native apps.
Pay nothing when idle. No provisioned VMs or containers — billing starts when requests arrive, stops when they don't.
Deploy once, run in 330+ cities. Within 50 ms of ~95% of internet users. Smart Placement keeps compute next to data.
Inference, state, storage, queues, observability — all as bindings. No infrastructure to provision. Just develop.
Inference, state, storage, media, queues, deployment, observability —
all the products you need·without provisioning any infrastructure.
So developers can focus on what they enjoy most: develop!
Note: these demos need to be run at together and on RNobre Cloudflare account.
The categories above explain what you can build. These demos show the same platform primitives in motion: media, agents, retrieval, queues, AI, and multi-cloud ingress.
An open-source AI-native workspace, decomposed into the Developer Platform primitives underneath: model choice, agents, durable state, governed tools, isolated execution, and AI observability.
Three videos, three postures: public, origin-restricted, signed-URL gated. Signed video uses the Stream binding to mint short-lived JWTs server-side.
One Agent, one MCP Server Portal, three MCP servers behind Access. Tools discovered at runtime; every call crosses a real Zero-Trust boundary. Workers AI generates images; D1 / R2 / KV store results.
Four persistent Agents challenge a decision from distinct perspectives, then a rotating proposer synthesizes the trade-offs for a vote. Durable Objects coordinate each council while AI Gateway routes model calls and D1 preserves the transcript.
An Orchestrator delegates to Worker agents with separate Workspaces, read-only R2 policy data, fetch-tool allowlists, and Workers AI through AI Gateway. The Audit trail shows what the agent can touch — and where the Guardrail stops it.
Docs into R2 → Queue → Workflow → Workers AI embeds → vectors in Vectorize. At chat time, query vector + top matches stitched into the LLM prompt. Six bindings, one Worker.
Cloudflare edge validates and normalises events, pushes clean payloads into a Queue. A GCP Cloud Run backend pulls via HTTP and acks. Bot mitigation, queueing, and AI visibility in one path via AI Gateway.
A 9-step space mission: SWAPI fetch → AI analysis → AI risk assessment → human-in-the-loop pause → AI report → KV archive. Arm a mid-flight "bomb" to fail a step — previous outputs stay preserved, retry recovers without re-running the AI calls.
Interactive tutorial showing how Containers extend Workers with custom runtimes. Live ISS tracker with 3D globe, lifecycle management, and scaling models (singleton vs load-balanced). Built on Durable Objects — each container is a DO with location affinity and state.