The Cloudflare OS: one account running an entire build
One Cloudflare account runs this application end to end: the pages, the API, the relational database, the append-only event store, the object store, the queue, the scheduled jobs, the headless browser, the model calls and outbound mail. No second host, no virtual machine, no container.
A binding is a line in a Cloudflare configuration file that attaches a resource to code and names the property the code reaches it by. env.DB is a binding. The resource behind it has an account-scoped identifier; the running code never sees that identifier, only the name. That indirection is why a preview deployment can point at a different database without one line of code changing.
Below: the complete binding list read out of the configuration files, the unit each one bills on, the arithmetic for a stated month, the failure that turns a hobby account into a five-figure invoice, and reports from people who ran this stack and stayed or left.
Evidence status
Observed marks first-party measurements or runtime receipts from the named environment. Derived marks arithmetic calculated from cited inputs. Specified marks vendor or standards documentation. Implemented and deployed name code and live-state evidence, respectively. Reproduced means the stated procedure was rerun. Externally attested marks operator reports; those reports show that an experience occurred, not that it is universal.
Nine bindings ship with the request layer
wrangler.toml at the repository root declares everything the page-and-API layer can touch. The account identifier and the workers.dev subdomain are redacted; nothing else is.
| Binding | Kind | What is behind it | Why this and not something else |
|---|---|---|---|
DB | D1 database loop-content-spine | 91 tables: articles, the capability directory, agents, leads, tasks, sessions | Relational reads with joins and indexes. KV cannot filter; R2 cannot query |
LEDGER | D1 database loop-shared-events | 12 tables, append-only: events, invocations, capabilities, hash-chain checkpoints | Separate database so a write-heavy audit trail cannot compete with page reads for the same storage limit |
KV | Workers KV namespace loop_content_kv | 19 keys: OAuth handles, prompt settings, one cached audio blob | Config distributed to every location. Read-mostly, tolerant of eventual consistency |
R2 | R2 bucket miscsubjects-ledger | 645 objects, 12.3 MB: vendored docs, disclosure receipts, agent-turn archives | Bytes with no query on them. R2 charges nothing for egress; a database charges per row scanned |
AI | Workers AI | Model inference invoked from a request | Inference without an outbound API key in the request path |
DIRECTORY_DO | Durable Object class DirectoryDO in Worker loop-safe-directory-do | Slug registry plus an append-only mutation-intent log | Single strongly-consistent writer. D1 cannot hold a transaction across two requests, so the serialization point has to be an object |
TASKS | Queue producer for loop-tasks | Work handed off so the reader is not kept waiting | A request has a wall-clock budget; a queue consumer has its own |
STORE | Service binding to Worker loop-safe-storage | Bulk blobs in a second R2 bucket plus a D1 index over them | Keeps a second bucket and a second database out of the Pages project's binding list. Worker-to-worker, no public route |
META_BRIDGE | Service binding to Worker loop-meta-bridge | The Meta Graph API, fronted | That Worker binds the Meta token by reference from Secrets Store. Nothing copies the token |
All nine are repeated under [[env.preview.*]] in the same file, with DB and LEDGER pointing at loop-content-spine-preview and loop-shared-events-preview. Pages environment overrides do not inherit: a binding declared once at the top level and not repeated under env.preview does not exist in a preview deployment at all. Two D1 identifiers differ; the other seven bindings are byte-identical repetitions. That duplication is the only thing stopping a pull-request preview from writing to production data.
Seven more Workers hold what a request cannot
The Pages project is one deployment. Six sibling Workers carry the bindings a request-scoped runtime cannot own — scheduled execution, long jobs, durable state and mail — plus one that exists only to serve a single path.
| Worker | Bindings it owns | What it is for |
|---|---|---|
loop-safe-sibling | AI, DB, KV, R2, DO classes ExpertDO and AgentDO, Workflows DELIVER_WF and SELFTEST_WF, browser MYBROWSER, queue producer and consumer for loop-tasks, send_email binding EMAIL, cron /1 and 0 4 | Everything on a clock, everything that survives a restart, everything that drives a browser |
loop-safe-directory-do | DB, DO class DirectoryDO, SQLite migration v1 | The one strongly-consistent writer for slugs |
loop-safe-storage | R2 bucket miscsubjects-store, D1 loop-storage-index | Bulk blobs with a queryable index. workers_dev = false, reachable only via STORE |
loop-meta-bridge | Secrets Store refs META_ACCESS_TOKEN, META_BUSINESS_ID, META_API_VERSION | Meta Graph reads only. workers_dev = false |
miscsubjects-mcp | DB, KV, DO class MiscsubjectsMCP | Model Context Protocol server |
oip-peer | KV namespace oip-peer-store | A second federation node on a second registrable domain |
miscsubjects-robots | Route miscsubjects.com/robots.txt | One path, one Worker |
DIRECTORY_DO and STORE are ordering traps: each names another Worker by script_name or service, and if that Worker has never been deployed the next Pages deploy fails on the binding, not at the call site. The target has to exist before the pointer does.
Secrets appear as names in code and as values nowhere in the repository
Sixty-eight uppercase environment names are referenced across the Functions code, of which 43 are credentials. They are Pages environment variables and Secrets Store references, never files in the repository. Regenerate the list:
grep -rhoE 'env\.[A-Z][A-Z0-9_]{3,}' functions --include='*.js' | sed 's/env\.//' | sort -uNames only, values nowhere: ADMIN_SESSION_SECRET, AIG_TOKEN, AIG_RUN_TOKEN, AIG_SHIM_TOKEN, ANTHROPIC_API_KEY, ARCADS_API_KEY, BLOOIO_API_KEY, CF_API_TOKEN, CLOUDFLARE_API_TOKEN, CLOUDFLARE_GLOBAL_KEY, GEMINI_API_KEY, GITHUB_TOKEN, GROK_API_KEY, KIMI_API_KEY, MCP_TOKEN, META_ACCESS_TOKEN, MOONSHOT_API_KEY, OPENAI_API_KEY, STORE_KEY, STRIPE_SECRET_KEY, TELEGRAM_BOT_TOKEN, TERMINAL_KEY, VAULT_UNLOCK_TOKEN, X_API_KEY, X_ACCESS_TOKEN, and eighteen more of the same shape.
The comment in wrangler.toml records why these are plain Pages variables and not Secrets Store entries: wrangler 4.99 rejects [[secrets_store_secrets]] for a Pages project. The Meta bridge, which is a Worker and not Pages, does use Secrets Store — three references, store_id in the config, values never copied.
Every binding bills on a different unit, and only three of them can run away
The Workers Paid plan is $5.00 a month minimum for the account, and that subscription covers Workers, Pages Functions, KV, Hyperdrive and Durable Objects usage up to the included amounts below. Rates as published on 2026-07-26.
| Binding kind | The unit that bills | Free plan | Paid plan |
|---|---|---|---|
| Workers / Pages Functions requests | one request, cache hits included | 100,000/day | 10M/month, then $0.30/M |
| Workers CPU time | CPU milliseconds burned, not wall clock | 10 ms/invocation | 30M CPU-ms/month, then $0.02/M |
| D1 rows read | rows a query scans, not rows it returns | 5M/day | 25 billion/month, then $0.001/M |
| D1 rows written | rows changed, plus one per index touched | 100,000/day | 50M/month, then $1.00/M |
| D1 storage | GB summed across every database on the account | 5 GB total | 5 GB, then $0.75/GB-month |
| KV reads | one key, including reads that return null | 100,000/day | 10M/month, then $0.50/M |
| KV writes / deletes / lists | one key, or one list call | 1,000/day each | 1M/month each, then $5.00/M |
| KV storage | GB stored | 1 GB | 1 GB, then $0.50/GB-month |
| R2 storage | GB-month, standard class | 10 GB-month/month | $0.015/GB-month |
| R2 Class A operations | writes and listings | 1M/month | $4.50/M |
| R2 Class B operations | reads | 10M/month | $0.36/M |
| R2 egress | bytes to the internet | free | free |
| Durable Object requests | HTTP, RPC sessions, WebSocket messages and alarm invocations | 100,000/day | 1M/month, then $0.15/M |
| Durable Object duration | gigabyte-seconds the object is resident | 13,000 GB-s/day | 400,000 GB-s/month, then $12.50/M GB-s |
| Durable Object SQLite rows | same counters and rates as D1 | 5M read / 100,000 written per day | 25 billion read / 50M written per month |
| Queues | one operation; write + read + delete is three | 10,000/day | 1M/month, then $0.40/M |
| Workflows steps | one persisted step | 3,000/day | 500,000/month, then $0.80 per extra 100,000 |
| Browser | browser-hours, plus concurrent browsers averaged monthly | 10 minutes/day | 10 hours/month then $0.09/hour; 10 concurrent then $2.00/browser |
| Email sending | outbound transactional mail | not available | included with Workers Paid; sending to verified destination addresses is free on all plans |
Three of those units are unbounded by traffic and therefore the ones to watch. Durable Object requests count alarm invocations, so a self-scheduling object bills whether or not anyone visits. D1 rows read counts a scan, so one missing index multiplies the bill by the size of the table. Queue operations count three per message, so a retry storm triples on a metric that is already tripled.
One index turns 2,186 rows read into 1
The same lookup, run against the live production database twice on 2026-07-26, once through the slug index and once as a scan:
npx wrangler d1 execute loop-content-spine --remote --json \
--command "SELECT slug FROM articles WHERE slug='cloudflare-os'"
# "rows_read": 1, "duration": 0.1746
npx wrangler d1 execute loop-content-spine --remote --json \
--command "SELECT slug FROM articles WHERE body LIKE '%DIRECTORY_DO%' LIMIT 5"
# "rows_read": 2186, "duration": 23.1205Same table, same result column, 2,186 times the billable work and 132 times the latency. LIMIT 5 does not help, because the limit applies to rows returned and the meter counts rows scanned. Every D1 query returns a meta object carrying rows_read and rows_written; that object, not the dashboard, is the cheapest place to catch a query that scans a table.
The arithmetic for one month at one million page views
Assume one million requests a month against this application, four D1 queries per page render, all of them indexed lookups that read fewer than fifty rows each, one KV read per render for the settings blob, and the storage measured above.
Workers Paid subscription $5.00
Requests 1,000,000 (10,000,000 included) $0.00
CPU time 1,000,000 x 7 ms = 7,000,000 CPU-ms
(30,000,000 included) $0.00
D1 rows read 1,000,000 x 4 queries x 50 rows = 200,000,000
(25,000,000,000 included) $0.00
D1 storage 281,989,120 + 1,061,666,816 bytes = 1.34 GB
(5 GB included) $0.00
KV reads 1,000,000 (10,000,000 included) $0.00
R2 storage 12,261,706 bytes = 0.0123 GB (10 GB-month included) $0.00
Queues assume 20,000 messages x 3 operations = 60,000
(1,000,000 included) $0.00
------------
TOTAL $5.00The included allowances are the point. At a million page views a month this application costs the subscription and nothing else. The same page views on the unindexed query above — 1,000,000 × 4 × 2,186 = 8,744,000,000 rows read — still land inside the 25 billion included, and at ten million page views become 87.44 billion rows, of which 62.44 billion bill at $0.001 per million: $62.44. A single missing index on a 2,186-row table is a $62 line item. On a table with a million rows it is a bill that needs its own meeting.
$34,895 in eight days, with zero users and no alert
The failure that matters is not slow growth. It is a Durable Object scheduling its own wake-up.
A pre-launch solo founder posted the postmortem to Hacker News on 2026-04-16. His agent object called setAlarm() in onStart() without checking whether an alarm was already pending, so every wake-up scheduled another. Sixty-plus preview deployments each created independent object instances, each running its own copy of the loop. His timeline: began 3 April with zero prior Durable Object usage; peaked 4–5 April at roughly 930 billion row reads a day; found and fixed 11 April; invoice due 15 April, $34,895.
Work the peak day against the published rate. 930,000,000,000 ÷ 1,000,000 = 930,000 million-row units × $0.001 = $930 for one day of row reads. Eight days at that peak is $7,440. The post does not itemise the invoice, so the remaining ~$27,000 is Durable Object requests — one per alarm invocation, $0.15 per million — plus duration at $12.50 per million GB-seconds for objects that never went idle. Row reads do not explain the number. Alarms billing as requests do.
Why nothing warned him is the platform-level lesson, and the reason this sits on the index page rather than in the Durable Objects article: Workers Usage Notifications monitor CPU time. They do not monitor Durable Object row reads or writes, and there is no hard spending cap for Durable Object operations in the dashboard or in a wrangler file. Nothing was going to fire.
The fix from the same post is three lines — read getAlarm() first, call setAlarm() only if it is empty. The two structural fixes alongside it: strip Durable Object bindings out of preview environments entirely, and deploy a separate budget-monitor Worker as a kill switch, because the platform will not.
Pick the binding by the job, not by the brand
| The job | The binding | Why, in one line | Depth |
|---|---|---|---|
| Relational data you filter, join and sort | D1 | The only binding running SQL over a schema you control | D1 |
| Hot config read everywhere, written rarely | KV | Everywhere at once, eventually consistent, cheap reads and expensive writes | KV |
| Files, images, archives — bytes with no query | R2 | Free egress, $0.015 per GB-month, no per-row meter | R2 |
| Serving pages and answering API calls | Pages Functions | One deployment for the page and its API, so no version skew | Functions |
| Long-lived state one caller at a time must own | Durable Objects | Single-threaded, own SQLite. The only strong-consistency primitive here | Workers and DOs |
| Work the reader must not wait for | Queues | Producer in the request, consumer with its own time budget | Async |
| Multi-step jobs that must survive a restart | Workflows | Each step persisted, so a crash resumes rather than restarts | Async |
| Anything on a clock | Cron triggers | 15 minutes of CPU per invocation against 30 seconds for a request | Async |
| Fetching pages a plain HTTP client cannot | Browser | Real headless Chromium inside the account, billed by browser-hour | Browser |
| Outbound transactional mail | send_email binding | No mail vendor and no SMTP credentials in the request path | not published |
| Protecting an admin surface | Cloudflare Access | Identity in front of a route, before the Worker runs | not published |
Six documented reasons to keep an application off this platform
Data residency, below Enterprise. Workers gives no choice of region or country for where code executes; the product that constrains it, Regional Services, is an Enterprise add-on. One developer moved a whole TypeScript Workers project to Django over it: "I recently ported an entire TS project from cloudflare workers to a django python app since cloudflare workers don't support choice of region/country when deploying workers." The nuance his complaint misses: Durable Objects do take a jurisdiction on every plan — env.MY_DURABLE_OBJECT.jurisdiction("eu"), with eu, us and fedramp permitted — and then run and persist only there. State can be pinned; request handling cannot. Both are true, of different layers.
D1 latency and reliability, over a year in production. "Using D1 in production for over an year on multiple projects - I can confirm response times to simple queries regularly take 400ms and beyond. On top there's constant network, connection and a plethora of internal errors." A second production user, a year later on a different thread: "D1 reliability has been bad in our experience. We've had queries hanging on their internal network layer for several seconds, sometimes double digits over extended periods (on the order of weeks)."
No transaction across two requests. "Another fun limitation is that a transaction cannot span multiple D1 requests, so you can't select from the database, execute application logic, and then write to the database in an atomic way." His workaround: pack a precondition into the first statement of a batch and make it throw on purpose.
Per-tenant database sharding does not work in practice. The documented one-database-per-customer pattern collapses on the binding model: "It's not possible to set up per-user data in D1. Like in theory you probably could, but the DX infrastructure to make it possible is non-existent - you have to explicitly bind each database into your worker."
The deployment tool, if you live in a monorepo. A developer who moved a Cloudflare stack to Azure gave tooling as the reason, not price: "I found the experience of maintaining and deploying workers to be terrible and so monorepo-unfriendly due to wrangler forced usage for deploys (or at least I haven't found better ways)."
Products get superseded underneath you. Pages, which this request layer runs on, is now something Cloudflare recommends migrating away from — described approvingly: "This is kind of what happened (is happening) with pages right now. Workers gained pretty much all of their features and are now the recommended way to deliver static sites too." One developer cannot follow that recommendation at all: "I had to use Pages since Workers don't support 'Custom domains outside Cloudflare zones'. There's no way I can transfer the domain since I have subdomains tightly integrated with AWS services."
Four people who stayed, at four different scales
Someone who could not code five months earlier shipped the whole stack. "Stack: Next.js 14 + React 18 on Cloudflare Pages, Hono 4.10 API on Cloudflare Workers (60+ route modules), 4x Cloudflare D1 databases (~180 tables total), Neon Postgres via Prisma + Hyperdrive, KV + R2 + Durable Objects + Queues." Four databases and roughly 180 tables is not a toy schema.
A migration off managed Postgres took a week. "In a week, from start to production, I migrated an AWS RDS database to Cloudflare D1 behind an OpenAPI REST interface over HTTPS using itty-router-openapi [1]. This will save me at least $250 pa."
Multi-million monthly actives on SQLite inside Durable Objects. "We serve multi million MAU on sqlite orchestrated through durable objects. It's not the most complex thing in the world but it goes further than CRUD. It costs us such a small amount of money for what it does."
A live multiplayer game, with the cost boundary stated out loud. Answering a challenge that Durable Objects are too expensive for a game: "DO alarms handle the time-based stuff (fleet arrivals, combat resolution, resource ticks) so there's no persistent connection cost. so far costs have been negligible." The caveat is the useful half: that holds because the game is tick-based. Anything realtime wants WebSockets, and the billing changes with it.
The person who built Workers argues against the default choice
"It's almost always better to use Durable Objects storage, rather than D1. Even if you only want a single global database, it's better to implement that as a singleton Durable Object, than by using D1." His reasoning: D1 already is a singleton Durable Object wrapping SQLite, so going direct puts the code in the same place as the data instead of one hop away, and read replication is the only thing D1 keeps that a raw object does not have.
He is as blunt in the other direction about KV, to a developer using it as a datastore: "KV is not a distributed database and is really not intended as a database alternative at all. It's more meant for distributing bits of config globally. Cost aside, writes are way too slow for database-ish use." That is why the KV namespace in this application holds 19 keys and not 19,000.
Against both sits a production dissent from the same D1 thread — "I am running 2 production apps on Cloudflare workers, both using D1 for primary storage. I found the performance ok, especially after enabling Smart Placement" — and an independent measurement from a purpose-built harness landing between the positions: "North America performance (US and Mexico) had ~200ms+ latency per query, spiking to 500ms or higher in the test application I made using workers and D1."
Both sides measured something real. D1's convenience and D1's tail latency are both real, and which dominates depends on whether the Worker and the database end up in the same region. Smart Placement is the one lever that decides it. If a 400 ms tail on a simple query is unacceptable, the read path does not belong on D1.
Symptom, cause, fix
Error strings verbatim, each from a filed report or from a command run against this account.
| Symptom | Cause | Fix |
|---|---|---|
too many terms in compound SELECT: SQLITE_ERROR [code: 7500] | More than about five UNION ALL terms in one D1 statement | Split it, or use d1.batch() |
workers.api.error.script_too_large on deploy, fine locally | The bundled Pages Functions script exceeds 1 MiB. One report is a 2.4 MB compiled WASM file; another is a blog that crossed 200 posts | Move the asset to R2 and fetch it, or split the route into its own Worker |
string or blob too big: SQLITE_TOOBIG on a Workflow step | A step output above the SQLite value ceiling — reported at ~200 KB as a Uint8Array, while the same bytes as an ArrayBuffer pass | Write the payload to R2, return the key as the step output |
Every route returns 500 under wrangler dev --remote, production fine | Declaring a queue producer binding breaks all routes in remote dev, including routes that never touch the queue | Develop locally, or comment the producer out while using --remote |
| Browser Rendering REST calls return 400, codes 7003 / 7000, token verified | Reported against the REST endpoint with correct account id and permissions | Call the MYBROWSER binding from inside a Worker instead of the REST API |
| A Durable Object alarm silently stops firing forever | A failed handler leaves a past timestamp in storage, so every later scheduling call sees an alarm set and skips | Compare getAlarm() against Date.now(), not against null |
| Pages Function returns 500 with an empty body in production only, no logs | The script fails before it can emit output | Wrap the handler in try/catch, return the error text, deploy again |
Access-fronted API: /api/health works, every scoped call fails | The Access JWT carries an identity that is not a member of the resource requested | Map the service-token identity to a real principal before authorising |
| Forwarded mail silently never arrives | Recipient providers block Cloudflare's forwarding IP ranges: "most times Outlook just blocks Cloudflare IP ranges and emails never get routed to my Outlook mail box" | Send from your own authenticated domain instead of relying on forwarding |
The volume: nine pages, seven of them live
| Page | What it settles | Status |
|---|---|---|
| D1 as the spine | Why two SQL databases, one append-only | live |
| KV as the fast lane | What belongs in KV when SQL is already present | live |
| R2 as the object store | What free egress is worth, and what R2 does not do that S3 does | live |
| Pages Functions as the request layer | One deployment for every page and route, and its size ceiling | live |
| Workers and Durable Objects | Jobs that cannot live in a request, and the objects holding state between them | live |
| Queues, workflows and cron | Three different answers to "later", and which one each job needs | live |
| Browser Rendering as the eyes | Fetching what a plain client cannot, and what a browser-hour costs | live |
The send_email binding, routing rules, and the authentication result that made mail land | not written; /a/cloudflare-os-email redirects here | |
| Access and secret posture | Which surfaces are public, which need the owner key, the one-token model | not written; /a/cloudflare-os-access redirects here |
The capability layer above every binding here — one table of rows, each naming a function, an endpoint, a model or a flow — is documented in 891 tools, zero tool schemas, What a directory row is and The four-step loop.
How the counts on this page were taken
Four commands, run from the repository root on 2026-07-26. The account identifier wrangler prints in error output is redacted.
# 387 JavaScript files under functions/, 214 of them exporting a request handler,
# 271 exported handler functions in total
find functions -name '*.js' | wc -l
grep -rlE 'export (async )?(function|const) onRequest' functions --include='*.js' | wc -l
grep -rhoE 'export (async )?(function|const) onRequest[A-Za-z]*' functions --include='*.js' | wc -l
# 91 tables in the content spine, 12 in the event store
npx wrangler d1 execute loop-content-spine --remote --json \
--command "SELECT name FROM sqlite_master WHERE type='table'"
# row counts; the meta object in the response carries rows_read and size_after
npx wrangler d1 execute loop-shared-events --remote --json --command \
"SELECT 'events' t, COUNT(*) n FROM events UNION ALL SELECT 'invocations', COUNT(*) FROM invocations UNION ALL SELECT 'capabilities', COUNT(*) FROM capabilities UNION ALL SELECT 'anchors', COUNT(*) FROM anchors"
# events 400,756 · invocations 159,761 · capabilities 1,026 · anchors 6
# "rows_read": 561549 · "size_after": 1061666816
# three R2 buckets, six KV namespaces on the account
npx wrangler r2 bucket list
npx wrangler kv namespace listThe 387 figure matches the count recorded for this project earlier and is unchanged today. Those four COUNT() terms read 561,549 rows between them — $0.00056 of billable work, and the exact shape of the query that stops being free when the tables are a thousand times larger. COUNT() scans.
Key evidence
14 more ranked claims
Model review4 contributions · 1 modelExpand the recursive review layer
/api/articles/cloudflare-os/contributionsAsk this article · 8 suggested prompts
Text the build (+14245134626) or WhatsApp — slug|question creates a question node. Paste evidence with ingest slug|q:NODE_ID|your paste.