Everyone says EmDash is cheap. $5 a month. That’s the headline Cloudflare uses, and most coverage repeats it like a mantra. A managed WordPress host costs $20–$60 a month. EmDash sounds like a steal.
But $5 is not the price you’ll pay. Not for a real site. Not for a site that actually gets used.
A content management system should encourage you to manage content. EmDash's billing model discourages it.
Let me show you exactly why.
The $5 Plan Is a Teaser, Not a Ceiling
Cloudflare’s paid Workers plan starts at $5 a month. That buys you 10 million requests and a chunk of CPU time. Sounds generous until you realize what counts as a request.
Every page view is a request. Every admin panel click. Every plugin hook firing. Every API call. Every database read triggered by a render. One visitor loading a single blog post can hit four separate billing meters: the Worker invocation, the D1 database query, the R2 media fetch, and the KV session lookup. Each one meters separately.
A WordPress site with 5,000 monthly visitors—tiny by any standard—might generate 15,000–25,000 billable events per month just from normal browsing. Add an editor who saves drafts, manages media, and publishes a few posts a week, and you’re looking at 40,000–50,000 events. That’s still within the 10 million allowance. Barely.
The problem isn’t the first 10 million. It’s what happens after.
A Real Example: The Small Business That Didn’t Know
Imagine a local bakery with a blog. They migrate from WordPress to EmDash because they heard it’s faster and more secure. They sign up for the $5 plan. Everything works fine for two weeks.
Then they publish a popular post. A local news outlet links to it. Traffic spikes to 2,000 visitors in one day. That’s not a DDoS. That’s just a mild viral moment.
Those 2,000 visitors each load 3–4 pages. Many of those pages have images from R2, comments that trigger a plugin hook, and a sidebar widget that calls the database. Each page load generates 4–6 billable events. That day alone: roughly 30,000 events. Fine for one day.
But the spike lasts three days. By day three, they’ve burned through 90,000 events. The monthly allowance is 10 million, so still fine. But now the real cost driver appears: CPU time.
CPU Time Is the Hidden Meter
Workers charge not just per request, but per CPU millisecond. The $5 plan includes 10 million requests and 100,000 CPU milliseconds. A single complex page—one with a form plugin, a dynamic sidebar, and a post loop—can consume 15–20 CPU milliseconds per render. Multiply that by 2,000 visitors and 4 pages each, and you’re at 160,000 CPU milliseconds in one day. That’s 60% of the monthly CPU allowance in a single afternoon.
Now the bakery gets a bill. Not $5. More like $45 for that month. Still manageable.
But here’s where it compounds: admin activity. The bakery owner logs in every day to check comments, update a few posts, and moderate submissions. Each admin action triggers Workers, database reads, and plugin hooks. Over a month, that’s another 50,000 events and 30,000 CPU milliseconds. Total monthly cost: around $12–$15.
Not hundreds. Yet.
The Scenario That Breaks the Budget
Now add one plugin. A contact form that sends emails via a third-party API. That plugin declares read contentcodecodecodecode and email sendcodecodecodecode in its manifest. Every form submission triggers a dynamic worker, which spins up a V8 isolate, sends the request, and spins down. Each submission costs a Worker invocation plus CPU time for the API call.
A busy bakery gets 50 form submissions a day. That’s 1,500 submissions a month. Each one costs roughly 10 CPU milliseconds. That’s 15,000 CPU milliseconds just from the form plugin.
But the real risk is not the form. It’s the dynamic worker sandbox itself. To run plugins in sandboxed mode—the feature that justifies EmDash’s existence—you need Cloudflare’s paid plan with dynamic workers enabled. Dynamic workers have their own pricing: $0.30 per 1,000 invocations above the included 10 million. That’s cheap per invocation, but it adds up fast if a plugin runs frequently.
Now imagine the bakery installs a second plugin: an analytics aggregator that polls every hour. That’s 720 invocations per month. Still fine. But what if the plugin has a bug? What if it enters a loop, firing hooks repeatedly? Without a spending cap, that loop runs until the next billing cycle.
The Missing Kill Switch
Here’s the second-order effect most coverage misses: EmDash has no global spending cap. You can set CPU time limits per request. You can configure rate limiting via WAF rules. But you cannot set “stop billing me after $50 this month.” Cloudflare has said repeatedly that a spending cap is not available. Your site keeps running, workers keep firing, and your card keeps getting charged.
A DDoS attack on a WordPress host crashes the server. You get a flat-rate bill. A DDoS attack on EmDash racks up usage charges. One forum user calculated that a basic bot attack—10,000 IPs, one request per second each—would generate 26 billion billable requests in a month. That’s not a typo. At $0.30 per million Workers requests, that’s $7,800. Add CPU, D1 reads, and R2 operations, and the total exceeds $13,000.
That’s the extreme case. The more common one is a plugin that misbehaves, a traffic spike that lasts longer than expected, or an admin who leaves a draft auto-saving every 30 seconds. Each one chips away at the allowance. None of them trigger a warning until the bill arrives.
The Real Cost of “Serverless”
The promise of serverless is “pay for what you use.” The reality is “pay for what you can’t predict.” EmDash’s architecture is built on V8 isolates that spin up and down in milliseconds. That’s brilliant for performance. It’s terrible for cost forecasting.
A WordPress site on a $20/month managed host handles traffic spikes without extra charges. The server might slow down, but the bill stays flat. EmDash handles spikes gracefully—and then bills you for every millisecond of grace.
For a bakery with 500 visitors a month and no plugins, the $5 plan works. For a bakery with a popular blog, a contact form, and an editor who works daily, the real cost is closer to $20–$30. Still cheaper than WordPress. But for a site with moderate traffic, multiple plugins, and any dynamic features, the cost can easily hit $100–$200 in a bad month.
The Implication Nobody Talks About
The most dangerous effect is behavioral. EmDash’s pricing model penalizes you for using the CMS. Every time an admin logs in, every time a plugin fires, every time a page renders, you spend money. That creates an incentive to reduce admin activity—to batch edits, disable auto-saves, and limit plugin hooks. That’s the opposite of what a CMS should do. A content management system should encourage you to manage content. EmDash’s billing model discourages it.
WordPress charges you for hosting. EmDash charges you for using the software. That’s a fundamental difference that no amount of “spiritual successor” branding can paper over.
What This Means for Your Choice
EmDash is not a $5 CMS. It’s a CMS that starts at $5 and scales unpredictably. If you’re building a static brochure site with zero plugins and no admin activity, it’s cheap. If you’re building anything that actually manages content, supports multiple editors, or runs third-party plugins, budget realistically. Assume $20–$50 per month for a small site, and accept that a traffic spike could double that.
The sandboxed plugin architecture is genuinely innovative. The performance is excellent. But the billing model is a liability for anyone who can’t absorb an unexpected $200 month.
Don’t let the $5 headline fool you. Read the fine print. Better yet, run the math on your actual usage before you migrate.
- What is the real cost of EmDash's $5 plan?The $5 plan is a teaser; for a real site with moderate traffic and plugins, costs can reach $100–$200 per month.
- Why does CPU time matter in EmDash pricing?CPU time is billed per millisecond, and complex pages can use 15–20 ms each, quickly exceeding the $5 plan's 100,000 ms allowance.
- How does EmDash's billing model affect site management?It penalizes admin activity like saving drafts or using plugins, discouraging the content management a CMS should support.
