Cloudflare Free-tier capability composition
A precise, dated map of the free primitives that can be combined into real applications - plus a reusable reasoning prompt that forces quota math, failure behavior and honest deployment boundaries.
Verification rule. This snapshot is useful for design, not a permanent contract. Re-check the linked official pages before deployment, especially Workflows after 10 August 2026. Quotas use different windows and some invocations also consume Workers limits.
Capability and limit matrix
| Service | Free-tier envelope | Best role | Primary source |
|---|---|---|---|
| Workers | 100,000 requests/day; 10 ms CPU/request; 128 MB memory; 50 external and 1,000 internal subrequests; 6 simultaneous outgoing connections; 3 MB Worker size; 100 Workers; 5 Cron triggers; 20,000 static assets/version; 25 MiB/asset. | Stateless API, edge logic, auth gateway, HTML rewriting and service composition. | Official limits |
| Pages | 500 builds/month; 1 concurrent build; 20-minute build timeout; 100 custom domains/project; 20,000 files/site; 25 MiB/file. Pages Functions consume Workers quotas. | Static sites and client-heavy apps; move immutable files out of compute. | Official limits |
| Workers KV | 100,000 reads/day; 1,000 writes/day; 1,000 deletes/day; 1,000 lists/day; 1 GB stored; 25 MiB/value; same key at most one write/second. | Read-heavy config, feature flags, cached manifests and routing hints; not a transactional database. | Official limits |
| D1 | 10 databases; 500 MB/database; 5 GB/account; 5 million rows read/day; 100,000 rows written/day; 50 queries/Worker invocation; 7-day Time Travel. | Relational metadata, membership, indexes, ledgers and small application state. | Official limits |
| R2 | 10 GB-month storage; 1 million Class A operations/month; 10 million Class B operations/month; Internet egress is free. | Artifacts, uploads, datasets, static release bundles and content-addressed evidence. | Official limits |
| Durable Objects | Free plan uses SQLite-backed objects; 100,000 requests/day; 13,000 GB-s/day; 5 million rows read/day; 100,000 rows written/day; 5 GB total. Unlimited objects, 100 classes, 10 GB/object, 32 MiB WebSocket message, default 30 s CPU/request. | Per-room/per-user coordination, WebSockets, locks, counters and strongly ordered state. | Official limits |
| Queues | 10,000 operations/day; up to 10,000 queues; 24-hour retention; 128 KB/message; 100 retries; batch size 100; 5,000 messages/second; 25 GB backlog. | Asynchronous fan-out, retry isolation, ingestion buffers and quota smoothing. | Official limits |
| Workflows | Free: 3-day state retention, 3,000 steps/day and 1 GB-month storage; 10 ms CPU/step, unlimited wall time/step, 1 MiB non-stream result. Pricing changes begin 10 August 2026, so re-verify. | Durable multi-step jobs, waits, retries, human gates and long-running orchestration. | Official limits |
| Workers AI | 10,000 neurons/day on Free. | Small inference, embeddings, classification and routing when neuron budget is explicit. | Official limits |
Composition patterns that earn their complexity
Static-first application
Pages or Workers Static Assets + client-side state + a tiny Worker gateway. Spend compute only on authority boundaries and mutations.
Relational command plane
Worker + D1 + Queues. Mutations enter an idempotent command table, then queues isolate retries and batch expensive work.
Realtime rooms
Worker + Durable Object + WebSockets + D1 snapshots. One object owns ordering; D1 stores searchable durable summaries.
Artifact network
R2 + D1 content index + signed Worker URLs. Large immutable evidence avoids database and egress pressure.
Durable jobs
Workflow + Queue + R2. Workflow holds state and waits; Queue absorbs bursts; R2 stores intermediate and final artifacts.
Budgeted intelligence
Workers AI + KV cache + D1 ledger + local/client fallback. A neuron ledger prevents inference from silently consuming the product.
Important design traps
- KV is eventually consistent and write-constrained; do not use one hot key as a global counter or queue.
- D1 limits are row-based. A broad scan can exhaust reads even when request count looks small.
- Workers CPU is not wall-clock duration. Waiting on network or Durable Objects is different from computation.
- Queue delivery and workflow retries require idempotency keys and an effect journal.
- Free-tier daily, monthly and per-object budgets cannot be treated as one interchangeable pool.
- Pages Functions and related server-side calls still consume Workers allocations.
ChatGPT 5.6 Sol - free-tier composition prompt
Paste app ideas and the current verified matrix into this prompt. It asks for multiple architectures rather than one reflexive stack, and requires every design to expose its quota assumptions and paid boundary.
SYSTEM ROLE: CLOUDFLARE FREE-TIER COMPOSITION ARCHITECT You are given one or more app ideas. Use deep reasoning to discover non-obvious combinations of Cloudflare Free-tier services that make the ideas deployable, useful and maintainable without silently crossing into paid capacity. INPUT APP IDEAS: [PASTE IDEAS] USERS / REGIONS / TRAFFIC: [ESTIMATES OR UNKNOWN] DATA TYPES AND SENSITIVITY: [PUBLIC, PRIVATE, PERSONAL, LARGE BLOBS, REAL-TIME STATE] HARD CONSTRAINTS: [FREE-TIER ONLY, LATENCY, OFFLINE, CLIENT-SIDE CRYPTO, ETC.] VERIFIED LIMITS SNAPSHOT: [PASTE THE DATED MATRIX FROM TORSIONFIELD.DE/CLOUDFLARE] METHOD 1. Decompose each idea into capabilities: static delivery, stateless compute, relational state, key-value configuration, blobs, coordination, queues, durable workflows, inference, identity and observability. 2. Generate at least six materially different service graphs. Include conventional and surprising combinations. Do not rename the same graph. 3. For every graph, map every capability to a specific Cloudflare service and state why that service fits. 4. Calculate a quota ledger for a normal day, peak day and failure/retry day. Show requests, CPU, reads, writes, storage, queue operations, workflow steps, AI neurons and build counts where relevant. 5. Mark each number as VERIFIED LIMIT, USER ASSUMPTION or DERIVED ESTIMATE. Never invent a limit. 6. Specify consistency, idempotency, deduplication, hot-key avoidance, retry and backpressure behavior. 7. Specify graceful degradation before a quota is exhausted. Prefer static/client-side/local execution when it preserves the product. 8. Classify data by sensitivity. Minimize server-side plaintext. Explain encryption, key ownership, retention and deletion. 9. Give a concrete repository/deployment layout: Workers, Pages/assets, D1 migrations, KV namespaces, R2 buckets, Durable Object classes, Queues, Workflows, tests and wrangler configuration. 10. Define acceptance tests and observability that prove the design stays within its quota envelope. 11. Identify any capability that cannot honestly fit the Free tier and name the smallest paid or non-Cloudflare escape hatch. 12. Rank the designs by product fit, quota headroom, failure isolation, operational complexity, migration cost and novelty. OUTPUT A. Capability decomposition. B. Six or more candidate service graphs. C. Quota ledger for each graph. D. Failure and degradation plan. E. Security and data-boundary plan. F. Minimum viable Cloudflare architecture. G. Creative stretch architecture. H. Exact deployment file tree and first implementation packet. I. Rejected combinations and why. J. Facts that must be re-verified against current official documentation before deployment. Treat Cloudflare services as composable primitives, not a checklist. Optimize for a useful application, not for consuming every free service.
Download the prompt Documentation version
Torsionfield application
Torsionfield can use this method to generate participant-owned control planes without pretending Cloudflare is an infinite distributed computer. Static releases belong in assets/R2, relational membership in D1, short-lived routing hints in KV, ordered rooms in Durable Objects, burst isolation in Queues and long waits in Workflows. Each project still needs a quota ledger and graceful local fallback.