| name | platform-limits |
| description | Check Cloudflare Developer Platform hard limits and runtime constraints before implementation: Worker memory/CPU/body/protocol constraints, D1 size/query limits, Durable Object hotspots, KV consistency, Queue message size/order, R2 object flows, and product availability. Use to prevent invalid designs.
|
| compatibility | Cloudflare Workers TypeScript projects using Wrangler; verify current Cloudflare APIs, limits, and pricing before production use. |
| metadata | {"source":"Architecting on Cloudflare plus official Cloudflare Developer Platform docs","generated":"2026-04-28"} |
Platform Limits
Use this skill before committing to an implementation. The exact numbers can change, so verify current limits in official Cloudflare docs for the product and plan.
Limit-check workflow
For each proposed architecture, write down:
## Limit check
- Worker request duration/CPU/memory constraints:
- Request/response body size assumptions:
- Protocol requirements: HTTP, WebSocket, WebRTC, TCP/UDP, custom protocols:
- D1 database size/query/write assumptions:
- R2 object size and streaming assumptions:
- KV consistency and write/read volume assumptions:
- Queue message size, retry, and ordering assumptions:
- Workflow step/output/duration assumptions:
- Durable Object hot-key risk:
- AI model availability/token/context assumptions:
- Regional/data residency/compliance assumptions:
- Plan/account feature availability:
Common constraint categories
- Runtime shape: Workers are not traditional servers; avoid native processes, arbitrary TCP servers, and long CPU-bound work.
- Memory: Do not buffer large files or huge query results; stream and paginate.
- CPU: Split heavy work into queues/workflows/containers when needed.
- Consistency: KV is eventual; Durable Objects and D1 patterns handle stronger consistency.
- Hotspots: One global Durable Object or one tenant-wide object can bottleneck.
- Message size: Queue messages should be small references, not payload dumps.
- Database scale: D1 should be modeled around boundaries and indexed query patterns.
- AI: Model catalogs, context windows, and pricing can change.
Refactor when a limit appears
| Limit pressure | Refactor |
|---|
| Large file upload/download | Stream through Worker; store in R2 |
| Large export/report | Queue/Workflow + R2 result |
| High-contention update | Durable Object per entity |
| Huge relational dataset | Partition D1, use Hyperdrive/external DB, or rethink boundary |
| CPU-heavy transform | Chunk, queue, workflow, or container |
| Queue payload too large | Put payload in R2/D1 and send key/reference |
| KV consistency issue | Move source of truth to D1/DO |
| AI context too large | RAG/chunking/summarization |
Code review red flags
await request.arrayBuffer() on unbounded uploads.SELECT * without LIMIT.- Queue message includes file contents or entire documents.
- Global mutable arrays/maps used as state.
- One Durable Object key named
global or main.
- No pagination, streaming, or backpressure.
- Exact quota numbers hardcoded into business logic without config or documentation.
Output requirement
If a limit might be relevant, mention it explicitly in the design or code review and include a mitigation. Do not silently assume Cloudflare behaves like a VM, container host, or regional database service.
