Primitives
Cloudflare primitives I use in production.
This is a practical reference, not a sales page. For each primitive: what it does, what older pattern it replaces, where it fits well, and what to watch out for.
Compute
Workers
Your application logic runs here. No servers, no regions — requests route to the nearest of 300+ edge locations automatically.
PHP app servers behind Nginx · Express on EC2 · Flask on a VPS
The shift
Traditional app servers are long-lived processes. Workers run in isolates close to incoming requests. That shifts effort away from instance management and toward application design.
Good for
- / SSR rendering (Astro, Remix, Hono)
- / API and BFF endpoints
- / Edge auth middleware and request rewriting
- / Proxy and analytics passthrough
Watch out for
- ! CPU time limit per request
- ! No shared in-process state between requests
- ! Node.js API parity gaps
State
Durable Objects
Single-writer coordination units. One object owns one piece of state, with colocated logic and strong consistency — no Redis required.
Redis for locks · Sticky sessions · App-level distributed state hacks
The shift
Most coordination problems come down to state ownership. Durable Objects make that explicit: one object instance per ID, with state and logic together. This works well for sessions, carts, rate limits, and other ordered-write flows.
Good for
- / Session and auth token management
- / Rate limiting buckets (per-user, per-IP)
- / Realtime collaboration rooms
- / Workflow state machines
Watch out for
- ! ID design strategy is critical
- ! Not for high-read, low-write hot data
- ! WebSocket hibernation complexity
Storage
D1 · R2 · KV
Three storage primitives for three access patterns. Relational queries in D1, large objects in R2, globally cached keys in KV.
MySQL · S3 + filesystem · Redis for hot reads
The shift
The key idea is storage by access pattern. D1 handles relational SQL, R2 handles objects, and KV handles global key-value reads. Modeling data deliberately instead of one-size-fits-all.
D1 — relational SQL
- User records, content, subscriptions
- SQLite API in the Worker runtime
R2 — object storage
- File uploads, media, AI artifacts
- No egress fees (huge vs S3)
KV — hot reads
- Session tokens, feature flags, config
- Globally consistent eventually
Watch out for
- ! D1 is SQLite — no PG extensions
- ! KV is eventually consistent
- ! Set R2 lifecycle policies early
- ! Rethink the schema vs MySQL
Background Execution
Queues · Workflows
Durable async execution that survives failures. Queues for fan-out with retries. Workflows for multi-step orchestration with checkpoints.
Laravel Queue workers · Horizon · cron jobs
The shift
Queues and Workflows handle durability and retries. Workflows add step-level orchestration and checkpoints for longer, complex jobs.
Queues — for
- Webhook processing
- Email sending pipelines
- Image/video processing triggers
Workflows — for
- Multi-step AI pipelines
- Agent execution loops
- Human-in-the-loop steps
Watch out for
- ! Always implement idempotency keys
- ! Design dead-letter handling early
- ! Workflow duration ceiling limits
AI + Search
Vectorize · Workers AI · AI Gateway
Semantic search, on-platform model inference, and a centralized gateway for every LLM call across all your projects.
Pinecone/Weaviate · Replicate · bare API keys in code
The shift
Workers AI handles on-platform inference. AI Gateway centralizes provider traffic, rate limits, caching, and cost visibility.
AI Gateway — for
- Single point of control for all LLM calls
- Per-route rate limiting and caching
Workers AI + Vectorize — for
- Semantic search over content
- Audio transcription with Whisper
Watch out for
- ! Version your embedding models
- ! Measure retrieval quality with evals
- ! AI Gateway caching is aggressive
See it in practice
Each primitive here is used in at least one live project.
If you want concrete examples, the project pages show where each primitive appears in real workflows.