Cloudflare Workers Pricing 2026: Free vs Paid, Real Cost Math, and When Each Tier Wins Pricing

# Cloudflare Workers Pricing 2026: Free vs Paid, Real Cost Math, and When Each Tier Wins Cloudflare Workers pricing in 2026 has two consumer tiers. The Free plan ships 100,000 requests per day per script with 10 ms of CPU time per invocation and limited access to KV, D1, Durable Objects, and Hyperdrive. The Workers Paid plan starts at a $5 minimum monthly charge and bundles 10 million requests, 30 million CPU milliseconds, KV, Hyperdrive, and Durable Objects into the base subscription. Overages run $0.30 per million additional requests and $0.02 per million additional CPU milliseconds. Two 2026 changes matter: SQLite-backed Durable Objects storage billing went live in January 2026, and Dynamic Workers per-Worker-per-day billing begins May 26, 2026. The rest of this page is the math the docs do not run for you. Vendor pricing pages describe tiers structurally; they do not tell you what a real 50-million-request month with Workers KV and R2 actually costs, and they do not put Workers next to Vercel Functions and AWS Lambda on the same workload. Toolradar runs one cost scenario; the rest of the SERP runs none. The matrix below covers every developer-platform SKU you can plug into a Worker, the per-tier math at three traffic profiles (indie, startup, scale-up), and the head-to-head comparison the docs leave you to assemble yourself. --- ## The 2026 Cloudflare developer-platform pricing matrix The Workers Paid plan is not a single line on an invoice. It is the umbrella that bundles compute (the Worker itself), key-value storage (Workers KV), object storage (R2), relational storage (D1), strongly-consistent stateful primitives (Durable Objects), inference (Workers AI), durable messaging (Queues), and database-connection pooling (Hyperdrive) into one $5 minimum monthly charge with each SKU carrying its own included quota and overage rate. The matrix below puts every SKU side by side at the four tiers Cloudflare actually offers in 2026. ### Cross-SKU matrix at every tier | SKU | Free | Workers Paid ($5/mo) | Workers for Platforms ($25/mo) | Enterprise (contact sales) | |---|---|---|---|---| | Worker requests | 100K/day per script | 10M/mo included, then $0.30/M | Per-tenant metering on top of $25 base | Custom committed-use | | Worker CPU time | 10 ms/invocation | 30M CPU-ms/mo included, then $0.02/M; 5-min cap per invocation | Same as Paid, per-tenant | Custom | | Workers KV reads | 100K/day | 10M/mo included, then $0.50/M | Bundled per tenant | Volume discount | | Workers KV writes | 1K/day | 1M/mo included, then $5.00/M | Bundled per tenant | Volume discount | | Workers KV storage | 1 GB | 1 GB included, then $0.50/GB-mo | Same as Paid | Custom | | R2 storage | 10 GB/mo + 1M Class A + 10M Class B | $0.015/GB-mo + ops fees, **zero egress** | Same as Paid | Committed-use | | D1 rows read | 5M/day | 25B/mo included, then $0.001/M | Bundled per tenant | Custom | | D1 rows written | 100K/day | 50M/mo included, then $1.00/M | Bundled per tenant | Custom | | D1 storage | 5 GB | $0.75/GB-mo after included | Same as Paid | Custom | | Durable Objects requests | 100K/day | 1M/mo included, then $0.15/M | Bundled per tenant | Custom | | Durable Objects compute | 13K GB-s/day | 400K GB-s/mo included, then $12.50/M GB-s | Bundled per tenant | Custom | | SQLite DO storage (Jan 2026+) | Bundled w/ DO Free | 5 GB-mo included, then $0.20/GB-mo | Same as Paid | Custom | | Workers AI inference | Bundled neurons | Per-model neuron pricing | Per-tenant metering | Custom | | Queues operations | n/a | 1M/mo included, then $0.40/M | Bundled per tenant | Custom | | Hyperdrive queries | 100K/day | Unlimited | Unlimited | Unlimited | | Workers Logs | 200K/day | 20M/mo included, then $0.60/M | Bundled per tenant | Custom | | Vectorize | n/a | 50M queried + 10M stored dims included | Bundled per tenant | Custom | Three properties of this matrix are easy to miss. First, the $5 floor is not a $5 ceiling: it is a minimum monthly charge for the account, with everything you do above the bundled quotas billed on top. Second, the Free column is generous for prototyping but unusable for production traffic the moment you sustain more than roughly one request per second on a single script: 100K requests per day works out to about 1.16 requests per second averaged across 24 hours, with no headroom for spikes. Third, the matrix understates a value-prop most teams miss: **no egress charges anywhere on the platform**. R2 reads do not cost egress. Workers responses to the open internet do not cost egress. This is the single line item that flips the Workers-vs-AWS math at scale, and it is below. ### What the matrix does not tell you Bundled quotas are not interchangeable. The 30 million CPU-ms in your Paid plan does not become "extra requests" when you do not use it; it expires monthly. The 10 million KV reads do not become 10 million extra Worker requests. Each line item is metered independently, and your first surprise overage will be on whichever line you under-budgeted, not on the totals. Plan per-SKU, not per-invoice. Overage rates are simple but the unit math is not. A common mistake is to read "$0.02 per million CPU-ms" and assume that means $0.02 per million Worker invocations. It does not. The CPU-ms unit is the actual CPU clock time consumed, summed across invocations. A Worker that runs 100 ms of CPU on each of 10 million requests burns 1 billion CPU-ms, which is 970 million over the included quota, which is $19.40 in CPU overages on top of the $5 base. A Worker that runs 1 ms of CPU on each of those same 10 million requests stays inside the bundle. The Dynamic Workers per-Worker-per-day billing change effective May 26, 2026 introduces a third axis. Where the Workers Paid plan today prices on request count and CPU time, Dynamic Workers (the SKU Cloudflare offers for multi-tenant SaaS that creates customer Workers programmatically) adds a per-Worker-per-day fee on every Worker that exists, even idle ones. If your platform spins up a Worker per tenant and most tenants are inactive, the per-Worker-per-day line is the one that will surprise you. --- ## Free tier limits: when 100K req/day is enough, and the exact point you outgrow it The Workers Free tier is the most generous serverless free tier in 2026 by a noticeable margin. The 100,000 requests-per-day-per-script ceiling resets at 00:00 UTC and applies per script, not per account. A team that ships ten separate Workers (one per microservice, one per cron job, one per static endpoint) gets 100,000 requests per day on each one. The CPU ceiling of 10 ms per invocation is the harder constraint for production work: any single request that does meaningful compute, including modest JSON parsing on a kilobyte-scale payload, can eat 2 to 4 ms before your application logic runs. ### Workloads the Free tier covers cleanly A side-project API serving up to 1.16 requests per second sustained, with simple JSON-in / JSON-out logic and no per-request work above 10 ms of CPU, will live on the Free tier indefinitely. A static-site redirect Worker that maps URLs and forwards to R2 fits. A scheduled cron job that runs every five minutes to refresh a small KV cache fits inside the cron Worker's separate 100K daily allowance. A webhook receiver that validates an HMAC signature and pushes to a queue fits, as long as you stay inside the Queues Free tier (which does not exist on the Workers Free plan; the moment you need Queues, you are on Workers Paid). ### The cliff edge: where Free becomes Paid Three transitions force the upgrade. The first is sustained traffic above 1.16 requests per second on a single script. The second is any request that needs more than 10 ms of CPU time, which includes any cryptographic signing of a meaningful payload, any JSON parsing of a body over 50 kilobytes, any image processing or AI inference, and any Durable Object that does work in its body. The third is the first time you need a developer-platform SKU that is gated behind Paid: Queues, unmetered Hyperdrive, more than 100K daily Durable Objects requests, or any Workers AI inference beyond the trial neurons. The cleanest test for "do I need to upgrade today" is to look at your CPU-ms metric on the Cloudflare dashboard. If your p99 invocation is above 8 ms, you are one optimization pass away from sustained 10-ms ceiling hits, which surface as HTTP 503 responses on the request that crossed the limit. The $5 upgrade is cheaper than the engineering time to keep p99 below the cliff. --- ## Workers Paid: what $5/mo actually covers, what triggers overages, and the math on a real 15M-request month The Workers Paid subscription is the cleanest pay-as-you-go developer platform on the market in 2026, but the simplicity is a marketing illusion. The $5 floor is real. Everything above the bundled quotas is metered independently per SKU, and the first time you see a $40 monthly invoice you will not understand which line item drove the spike unless you have walked through the math at least once. Here is the walk. ### The vendor's worked example, annotated Cloudflare publishes a single worked example on the Workers pricing page: a Worker serving 15 million requests per month, with 7 milliseconds of average CPU time per request, costs $8.00 total. Decompose that figure. - Base subscription: $5.00 - Request overage: 15M requests minus 10M included equals 5M over. 5M times $0.30 per million equals $1.50. - CPU overage: 15M requests times 7 ms equals 105M CPU-ms. Subtract the 30M included, leaves 75M over. 75M times $0.02 per million equals $1.50. - Total: $5.00 + $1.50 + $1.50 = $8.00 The instructive part of this example is not the total. It is that the request overage and the CPU overage are independently the same dollar amount even though they meter completely different things. At this workload profile, a 1-ms shift in average CPU time changes the bill by $0.30; a 1M shift in request count changes the bill by $0.30. The two axes are equal-weighted at this profile, and any optimization that drops average CPU below 7 ms saves more dollars than the equivalent request-count reduction. ### What pushes the bill above $8 Three patterns drive the next jump. First, any Worker that does inference, image processing, or heavy data transformation will run 50 to 200 ms of CPU per request, not 7. The same 15M-request month at 50 ms average CPU is 750M CPU-ms, which is 720M over, which is $14.40 in CPU overage, for a total of $20.90. Second, any Worker that fans out to KV writes (audit logs, session writes, analytics ticks) hits the KV write line, which is $5.00 per million over the 1M included. Three KV writes per request times 15M requests is 45M writes, which is 44M over, which is $220 in KV-write overage alone. Third, any Worker that backs a Durable Object hits the DO request and DO compute lines; a DO that runs 50 ms of compute on each of 1M extra invocations adds $0.15 plus $625 in DO compute, depending on memory. ### The cost-optimization order of operations For a Worker on the Paid plan, the order of cost-reduction wins is empirical and rarely starts with "fewer requests." Drop average CPU first. Move static asset reads to R2 (zero egress). Batch KV writes wherever you can tolerate eventual consistency. Cache aggressively in KV reads since the read rate is $0.50 per million vs the write rate of $5.00 per million, a 10x asymmetry that makes "read 10 times, write once" almost always cheaper than the inverse. Only after those three optimizations does request-count reduction matter, and at that point the per-million-request rate of $0.30 is small enough that most teams stop optimizing and ship. --- ## Workers KV pricing: reads vs writes asymmetry, and why storage looks cheap until you list-all-keys Workers KV is a globally-replicated key-value store designed for high-read, low-write workloads. The pricing model is the structural admission of that design. Reads cost $0.50 per million, writes cost $5.00 per million, and the 10x asymmetry between them is intentional: KV is cheap to read because Cloudflare cached your value at every edge POP, and expensive to write because invalidating that cache globally is the genuinely hard work. ### The full KV pricing breakdown The Workers KV Free tier ships 100,000 reads per day, 1,000 writes per day, 1,000 deletes per day, 1,000 list requests per day, and 1 GB of storage. All limits reset daily at 00:00 UTC. The Paid tier bundles 10 million reads per month plus 1 million writes, 1 million deletes, and 1 million list requests, with 1 GB of storage included. Overages: reads $0.50 per million, writes $5.00 per million, deletes $5.00 per million, list requests $5.00 per million, storage $0.50 per GB-month. Bulk read operations are billed by the count of keys read in the bulk operation, not by the bulk operation itself. REST API, dashboard, and CLI operations all incur charges, including queries that return null. No data transfer or egress fees apply. ### The list-all-keys trap The single most expensive KV operation for an unwary application is `list()` with no prefix filter and no cursor on a large keyspace. List requests are billed at $5.00 per million, the same rate as writes, and the request count is per call, not per key returned. A naive admin dashboard that calls `list()` once per page load and runs 100 page loads per day burns 3,000 list requests per month. Three thousand is well inside the Paid bundle. But the same dashboard built into a webhook handler that fires on every external event runs 100,000 list calls per day, which is 3 million per month, which is 2 million over the bundle, which is $10 in list overage alone, on top of whatever the Worker that wrapped it costs. The fix is to never `list()` in a request hot path. Pre-compute a manifest into a single KV key, refresh that manifest on a scheduled cron, and read the manifest on every page load. One read of the manifest replaces a `list()` plus a per-page iteration, and the read rate is $0.50 per million instead of $5.00 per million. ### Storage is the line nobody budgets for KV storage at $0.50 per GB-month sounds free until you accidentally use KV as a primary data store. A single team that wrote 5 million sessions to KV at 2 KB each, never expired them, and let the keyspace grow for 18 months ended up with 10 GB of storage, which is $5 per month, which is fine, except that the same data lived simultaneously in their Postgres primary, doubled their backup volume, and made every restore-test painful. KV is a cache, not a database. The pricing model treats it as a cache. Treat it as one. --- ## R2 storage and the zero-egress promise: the one thing AWS S3 can't match in 2026 R2 is Cloudflare's S3-compatible object storage. The headline number is $0.015 per GB-month for storage, which is competitive with S3 Standard at $0.023 per GB-month. The actual moat is not storage; it is egress. R2 does not charge for egress. None. Not to the open internet, not to other clouds, not to your own infrastructure outside Cloudflare. ### The R2 pricing breakdown Storage: $0.015 per GB-month after a 10 GB-month free allowance. Class A operations (writes, lists, copies, multipart uploads): $4.50 per million after 1 million free. Class B operations (reads): $0.36 per million after 10 million free. Egress: zero. ### What zero egress actually saves you A real worked example. A startup serving user-uploaded images stores 100 GB and serves 5 TB of egress per month. On S3 Standard, the storage line is $2.30 per month and the egress line is $450 per month at the standard $0.09 per GB rate after the first GB. Total: roughly $452. On R2, the storage line is $1.50 and the egress line is $0. Total: $1.50. The egress delta is the entire AWS bill in this scenario, and it does not require any change to the application code beyond pointing the S3 client at R2's endpoint. The break-even tilts heavily in R2's favor at any meaningful egress volume. A workload that serves 100 GB of egress per month saves $9 per month versus S3. A workload that serves 1 TB saves $90 per month. A workload that serves 10 TB saves $900 per month. Multiply by 12 for the annual run-rate, and the choice is mechanical. ### Class A operations: where R2 occasionally bites you R2's Class A ops ($4.50 per million) are noticeably more expensive than the storage and read rates. A workload that does many small uploads — analytics pipelines that write per-event objects, build pipelines that publish many small artifacts, log shipping that writes one object per minute per service — can rack up Class A op charges that overshadow the storage line. The fix is to batch writes: roll up small objects into larger ones at the application layer before they hit R2. A pipeline that batches 1,000 events per object writes 1,000 times fewer Class A ops than one that writes per event, at no storage cost difference. --- ## D1 reads, writes, storage, and the SQLite-backed Durable Objects 2026 billing change D1 is Cloudflare's serverless SQLite database, designed for global read distribution with a single-region primary write. The 2026 pricing model rewards read-heavy workloads aggressively: 25 billion rows read per month included in the Paid plan, then $0.001 per million, which is genuinely cheap. Writes are an order of magnitude more expensive at $1.00 per million after the 50 million included. ### Full D1 pricing Free: 5 million rows read per day, 100,000 rows written per day, 5 GB storage. Paid: 25 billion rows read per month included plus $0.001 per million overage, 50 million rows written per month included plus $1.00 per million overage, $0.75 per GB-month storage. The 25-billion included read quota is the most generous number on the matrix and it is real. A read-heavy SaaS application serving 100 million reads per day stays inside the bundle for the entire month. A write-heavy application has the opposite shape: 2 million writes per day exhausts the bundle in 25 days. ### The Durable Objects SQLite storage 2026 change The largest 2026 pricing change is the activation of billing for SQLite-backed Durable Objects storage in January 2026. Prior to January 2026, the SQLite storage layer that backs newer Durable Objects implementations was unmetered while the feature stabilized. In 2026 it is billed at $0.20 per GB-month with 5 GB-month included on the Paid plan, and rows read and written through the SQLite layer use the same per-row D1 rates above. The practical effect for teams that built on SQLite-backed Durable Objects in 2025 expecting "free" storage is a fresh line item on the January 2026 invoice. The dollar amount is small at modest scale ($0.20 per GB-month is forgiving), but the surprise is real for teams that did not track storage growth. Teams running thousands of Durable Objects each holding tens of megabytes of SQLite data should add the storage line to the monthly forecast for 2026 onward. ### D1 schema-design choices that swing the bill Writes are the expensive line. The cheap design is to write coarse rows, read fine-grained projections. A schema that stores one row per user with a JSON column for accumulated activity, updated transactionally on each activity event, writes one row per event. A schema that stores one row per activity event writes one row per event. The cost is identical at write time. The read pattern is what diverges: the coarse schema reads one row to display the user's full activity, which is one row read at $0.001 per million; the fine-grained schema reads one row per event displayed, which is N rows at the same rate. At modest N, the difference is negligible. At analytics-dashboard scale (hundreds of rows per page load times thousands of page loads), the fine-grained schema is mechanically cheaper because the read rate is 1,000x cheaper than the write rate, and querying for an aggregate is cheap. --- ## Workers AI per-neuron pricing: what a "neuron" is, what current models cost, and when you hit the allowance Workers AI is Cloudflare's edge-deployed inference platform, billed in "neurons," a normalized compute unit that abstracts across GPU types and model sizes. The Paid plan bundles a starting neuron allowance, and overages are per-neuron at model-specific rates. ### How neurons map to real inference A neuron is approximately one second of compute on a reference GPU configuration, scaled by the model's actual compute draw. A small text-generation model running on Workers AI consumes neurons roughly in proportion to its parameter count and the output token count. A Llama 3.1 8B instruction-tuned model at the time of this writing consumes roughly 1 neuron per 100 output tokens; a Llama 3.1 70B model consumes roughly 1 neuron per 10 output tokens. The neuron count is what bills; the model identity is what determines the conversion rate. ### Practical cost ranges in 2026 For a side-project chatbot that runs 1,000 inferences per day on an 8B model with an average 200-token output, the math is 2,000 neurons per day, or 60,000 neurons per month. That sits inside the bundled allowance on Workers Paid. For a production support-ticket router that runs 100,000 inferences per day on the same model with the same output length, the math is 200,000 neurons per day, or 6 million neurons per month, which exceeds the bundle and pushes the line into overage territory. The exact overage rate is per-model; for the standard text-generation models the rate is published per million neurons and falls between $0.10 and $0.80 depending on the model. ### Embeddings and Vectorize on the same platform Workers AI also runs embedding models on the same neuron pricing, with the embedding output stored either in Workers KV (for small lookups) or in Vectorize (for vector search at scale). The Vectorize line is metered separately: 50 million queried dimensions and 10 million stored dimensions included on the Paid plan, with overages billed per million dimensions. A retrieval-augmented generation pipeline that embeds 10,000 documents (storage) and serves 100,000 queries per month (queries) sits comfortably inside the Vectorize bundle, with the inference cost falling under the neuron line above. --- ## Real cost scenarios: indie, startup, and scale-up with full line-item breakdowns This is the section the SERP does not run. Three workload profiles, each priced to the line item, with annualized totals. ### Scenario A: Indie side-project (1M requests/month, KV-cached read-mostly) - Worker requests: 1M, inside Free tier? 1M/month is 33,333 per day, inside the 100K/day Free ceiling. - Worker CPU: 5 ms average, inside the 10-ms Free ceiling. - Workers KV reads: 500K/month for cached responses, inside 100K/day Free. - Workers KV writes: 5K/month, inside 1K/day Free. - R2 storage: 5 GB of static assets, inside 10 GB Free allowance. **Monthly total: $0.** Annual run-rate: $0. This is genuinely free for a real production side-project. ### Scenario B: Startup MVP (50M requests/month, with KV + R2 + Workers AI) - Worker requests: 50M, overage of 40M, at $0.30/M = $12.00 - Worker CPU: 50M requests at 15 ms average = 750M CPU-ms, overage of 720M, at $0.02/M = $14.40 - Workers KV reads: 20M reads, overage of 10M, at $0.50/M = $5.00 - Workers KV writes: 500K writes, inside the 1M bundled allowance - R2 storage: 100 GB at $0.015/GB-month = $1.50 - R2 ops: 5M Class B reads, inside 10M free; 200K Class A writes, inside 1M free - Workers AI: 100K inferences on an 8B model averaging 150 tokens out, neurons consumed = 150K, inside the bundled allowance - Base Workers Paid: $5.00 **Monthly total: ~$37.90.** Annual run-rate: ~$455. ### Scenario C: Scale-up production (500M requests/month, D1 + Durable Objects + Workers AI heavy) - Worker requests: 500M, overage of 490M, at $0.30/M = $147.00 - Worker CPU: 500M requests at 30 ms average = 15B CPU-ms, overage of ~14.97B, at $0.02/M = $299.40 - Workers KV reads: 200M reads, overage of 190M, at $0.50/M = $95.00 - Workers KV writes: 20M writes, overage of 19M, at $5.00/M = $95.00 - D1 rows read: 5B/month, inside the 25B bundle - D1 rows written: 100M, overage of 50M, at $1.00/M = $50.00 - D1 storage: 50 GB at $0.75/GB-month = $37.50 (after the bundled allowance) - Durable Objects requests: 50M, overage of 49M, at $0.15/M = $7.35 - Durable Objects compute: 10M GB-s, overage of 9.6M, at $12.50/M GB-s = $120.00 - Workers AI: 5M inferences on 70B model averaging 200 tokens = 10M neurons. At a published rate of roughly $0.40 per million neurons after the included allowance, that lands around $4.00 (this is an estimate; the exact figure depends on model selection at the time of billing). - R2 storage: 1 TB at $0.015/GB-month = $15.00 (and zero egress on the entire serving footprint) - Base Workers Paid: $5.00 **Monthly total: ~$875.25.** Annual run-rate: ~$10,503. The instructive takeaway from Scenario C is that no single line item dominates. The CPU overage ($299) is the largest, but it is one component of a portfolio where the next three lines (Worker requests $147, DO compute $120, KV reads $95, KV writes $95) are each 10 to 15 percent of the bill. Optimizing any one of them yields modest savings; optimizing the whole portfolio matters. The shape is fundamentally different from a Vercel or Lambda invoice at the same workload, where one or two line items typically carry 70 percent of the bill. --- ## How to read your first Cloudflare invoice: every line-item demystified The first invoice you see after upgrading to Workers Paid will list roughly eight to twelve line items even if you only run a single Worker. Each one is a separate SKU on the matrix above, billed independently. Here is the standard layout and what each line means in human language. **Workers Paid subscription**: the $5 minimum. Always present. Even if you used zero requests this month, this line is $5. **Workers requests (over included)**: every request to a Worker beyond the 10M monthly bundle, billed at $0.30 per million. This includes scheduled (cron) Worker invocations and Durable Object alarm invocations. **Workers CPU time (over included)**: every CPU millisecond consumed by your Workers beyond the 30M-ms monthly bundle, at $0.02 per million. **Workers KV reads/writes/deletes/list (over included)**: four separate lines if you used any of those operations beyond the bundled allowance. The most surprising line for new users is usually KV writes, billed at $5.00 per million. **Workers KV storage (over included)**: $0.50 per GB-month for stored data beyond 1 GB. This is metered as a monthly average, not a peak. **R2 storage**: $0.015 per GB-month for stored objects beyond 10 GB. This line is almost always small. **R2 Class A operations**: $4.50 per million writes/lists/copies beyond 1M. This line is the R2 surprise line: a write-heavy workflow can rack this up faster than storage. **R2 Class B operations**: $0.36 per million reads beyond 10M. Almost always negligible. **D1 (four lines)**: rows read, rows written, storage, and any SQLite-backed Durable Objects storage charges starting January 2026. **Durable Objects requests + compute**: two lines. Compute is the line that surprises teams running DOs with non-trivial body methods. **Workers AI (per model)**: separate lines per model you invoked, each billed in neurons against the model-specific rate. **Queues, Hyperdrive, Workers Logs, Vectorize**: present only if used. Cloudflare's billing dashboard breaks this down by day; the invoice presents the monthly totals. If a line surprises you, the first diagnostic is to look at the daily-by-day distribution on the dashboard and find the day or hour where the spike happened. Most cost surprises are workflow surprises (a runaway loop, a bot scan, a forgot-to-disable cron), not pricing surprises. --- ## Cloudflare Workers vs Vercel Functions vs AWS Lambda: the same 50M-request workload, priced apples-to-apples The 50M-request startup workload from Scenario B costs roughly $37.90 per month on Cloudflare Workers Paid. The same workload on Vercel Functions and AWS Lambda differs by orders of magnitude on different line items. Here is the side-by-side at the same shape (50M requests, 15 ms average CPU, 20M KV-like reads, 500K writes, 100 GB static assets served). ### Cloudflare Workers (verified above) Monthly total: ~$37.90. Annual: ~$455. ### Vercel Functions equivalent Vercel Pro is $20 per user per month, with bundled function invocations and a separate edge-function and serverless-function metering layer. For a one-developer startup, the base seat is $20. Function invocations are bundled at the Pro tier; at 50M invocations with a sustained CPU profile, the overage line on Vercel kicks in around the 1M GB-hours mark, which a 15-ms-CPU 50M-invocation workload hits modestly. Realistic monthly bill: $35 to $55, depending on bandwidth and edge function usage. Annual: $420 to $660. Note that Vercel charges egress bandwidth above the Pro inclusive amount, which Workers does not. ### AWS Lambda equivalent AWS Lambda prices at $0.20 per million requests plus $0.0000166667 per GB-second of execution time, with a perpetual free tier of 1M requests and 400,000 GB-seconds per month. For the 50M-request workload at 15 ms average compute time on a 256 MB Lambda (a reasonable Workers-equivalent configuration): request line is 49M times $0.20 per million = $9.80. Compute line is 50M times 0.015 seconds times 0.25 GB = 187,500 GB-seconds (under the free 400,000), so $0 compute. CloudFront in front of Lambda for edge caching: a separate bill. S3 for the 100 GB of static assets: $2.30 storage plus egress, at 1 TB of egress per month would be roughly $85. Realistic monthly bill: $97. Annual: ~$1,164, dominated by S3 egress. ### The pattern across the three For low-egress compute-only workloads, all three platforms land in roughly the same monthly cost band ($35 to $100). For any workload with meaningful egress, Cloudflare Workers pulls ahead because of R2 zero-egress; Vercel sits in the middle because Pro bundles some bandwidth; AWS Lambda is consistently the most expensive at scale because S3 egress is the dominant line. The "4x cheaper than a Vercel Pro seat" framing toolradar uses applies to the seat cost, not the total bill. The total bill comparison flattens substantially. The decision is rarely about cost in isolation. It is about the cost shape: Workers prices on requests and CPU with zero egress, Vercel prices on seats and bundled invocations, Lambda prices on requests and compute time with separate egress. Workloads that fit the Workers shape (high read, light CPU, heavy egress) save the most on Workers. Workloads that fit the Lambda shape (long-running compute, low egress) save the most on Lambda. The matrix above lets you predict which shape your workload has before you commit. --- ## Wrangler config snippets: the real-world configuration that drives your bill The pricing math above turns on configuration choices you make in `wrangler.toml`. Two snippets to anchor what each setting actually costs. ### Minimum-cost Worker (Free tier, optimized) ```toml name = "minimal-api" main = "src/index.ts" compatibility_date = "2026-01-01" # No KV, no D1, no R2 — pure compute on Free tier # 100K req/day, 10ms CPU/invocation, $0/mo ``` This shape stays free indefinitely for any workload under 1.16 req/s sustained. ### Production-ready Paid Worker (typical $37/mo startup shape) ```toml name = "production-api" main = "src/index.ts" compatibility_date = "2026-01-01" workers_dev = false route = { pattern = "api.example.com/*", zone_name = "example.com" } [[kv_namespaces]] binding = "CACHE" id = "abc123..." [[r2_buckets]] binding = "ASSETS" bucket_name = "production-assets" [[d1_databases]] binding = "DB" database_name = "production-db" database_id = "xyz789..." [observability] enabled = true head_sampling_rate = 0.1 # sample 10% of requests into Workers Logs # to stay inside the 20M/mo bundle on a 50M-req workload [limits] cpu_ms = 300 # set explicit CPU ceiling per invocation # default 30,000ms; 300ms catches runaway loops cheap ``` Two settings in this snippet save money directly. `head_sampling_rate = 0.1` on the observability block reduces the Workers Logs line proportionally. `limits.cpu_ms = 300` caps any single invocation's compute, which means a runaway loop costs you 300 ms instead of the 5-minute maximum, which is the difference between a $0.0001 mistake and a $0.10 mistake at scale. --- ## Frequently asked questions **Is the Cloudflare Workers free tier permanent in 2026?** Yes. Cloudflare has not announced any plan to deprecate or limit the Workers Free tier as of May 2026. The 100,000 requests-per-day-per-script ceiling and the 10-millisecond CPU-per-invocation ceiling have been stable since the original Workers launch, with the free tier broadening to include Durable Objects request quotas and Hyperdrive query quotas over time. The Free tier is the strategic acquisition channel for Cloudflare; nothing in the 2026 pricing changes suggests a contraction. **When does the $5/mo Workers Paid plan stop covering you?** The Workers Paid plan covers you cleanly up to roughly 10M requests per month at a typical 10 to 20 ms CPU average. Above that, the request overage ($0.30 per million) and CPU overage ($0.02 per million) become meaningful line items. Above 100M requests per month, the bill typically lands in the $50 to $200 range depending on CPU profile and KV usage. Above 500M requests per month, the bill is in the hundreds to low thousands, and Cloudflare's account team usually engages to discuss Enterprise committed-use pricing. **How much cheaper is Cloudflare Workers than Vercel Functions in 2026?** For low-to-mid traffic workloads (under 50M requests per month), Workers and Vercel Pro land in similar monthly cost bands ($35 to $55). The seat-cost framing ("4x cheaper than a single Vercel Pro seat") is accurate for a one-developer team but flattens as workloads scale. The structural difference is egress: Workers does not charge egress on the platform, Vercel bundles a generous allowance and bills above it, so high-egress workloads (image-heavy SaaS, large static asset serving, video streaming) tilt toward Workers significantly. **Do R2 reads charge egress in 2026?** No. R2 does not charge for egress under any circumstance. Reads to the open internet, reads to other AWS regions, reads pulled by a Cloudflare Worker, reads pulled by code running outside Cloudflare entirely — all egress is free. This is the single biggest line-item difference between R2 and AWS S3 at scale. Class A operations (writes, lists, copies) and Class B operations (reads) both carry per-operation fees, but neither is metered as bandwidth. **How do Workers CPU-time limits actually work?** The Free tier caps each Worker invocation at 10 milliseconds of CPU time. The Paid tier caps each invocation at 30 seconds by default with a configurable ceiling up to 5 minutes. CPU time is the actual CPU clock time consumed by your code, not wall-clock time waiting on I/O. A Worker that calls `fetch()` for 800 milliseconds and then runs 5 ms of CPU consumes 5 ms of CPU time, not 805. This is why I/O-heavy Workers stay inside the Free tier easily; only computation pushes you to Paid. **What changed for Cloudflare Workers pricing in 2026?** Two billing changes activated. First, SQLite-backed Durable Objects storage billing went live in January 2026 at $0.20 per GB-month with 5 GB included on the Paid plan. Prior to that, the storage layer was unmetered while it stabilized. Second, Dynamic Workers per-Worker-per-day billing activates May 26, 2026, adding a per-Worker-per-day fee on every Dynamic Worker that exists, including idle ones. Both changes are documented at the canonical pricing page; the first surprises teams that built on SQLite-backed Durable Objects in 2025, the second surprises multi-tenant SaaS platforms that spin up a Worker per customer. **Can you mix Workers Free and Workers Paid across multiple accounts?** Yes. Each Cloudflare account has its own Workers plan. A common pattern is one account on Workers Paid for production and one account on Workers Free for development and side-projects. The plans do not pool quotas; each account meters independently. This is also how teams isolate billing: separate accounts per business unit, each with its own subscription and overage profile, billed independently. Workers for Platforms is the inverse pattern, where one account hosts many tenants billed per-tenant under a $25 base. --- ## Internal links - [Cloudflare review](https://www.solomonsignal.com/launch-school/reviews/cloudflare): broader Cloudflare ecosystem overview if you are evaluating Cloudflare beyond Workers (CDN, Zero Trust, Pages, DNS). - [Cloudflare pricing](https://www.solomonsignal.com/launch-school/pricing/cloudflare): the account-level Cloudflare pricing page covering CDN, security, and Zero Trust tiers that sit above the Workers developer-platform layer. - [Cloudflare integrations](https://www.solomonsignal.com/launch-school/integrations/cloudflare): the integration directory for connecting Cloudflare to other tools in your stack. - [Cloudflare Workers best practices](https://www.solomonsignal.com/launch-school/tutorials/cloudflare-workers-best-practices): the production-patterns companion to this pricing page, covering the optimization patterns that drive the cost math above. ## External authority references - Cloudflare Workers official pricing documentation: developers.cloudflare.com/workers/platform/pricing/ - Cloudflare Developer Platform plans page: cloudflare.com/plans/developer-platform/