Cloudflare launched EmDash on April 1st, 2026. A spiritual successor to WordPress. Open source. MIT licensed. And free to use.<\/p>\n
That last part is technically true. But it’s also the most misleading claim in the entire announcement.<\/p>\n
The free tier of EmDash gives you a CMS that runs on Cloudflare Workers. You get 100,000 requests per day, 10 million per month. Sounds generous. But here’s what they don’t put in bold: the feature that makes EmDash worth considering \u2014 sandboxed plugin isolation \u2014 requires the paid plan. Without it, you’re running a version 0.1 CMS with zero plugins and no security advantage over WordPress.<\/p>\n
EmDash’s defining pitch is plugin security. Every plugin runs in its own V8 isolate via dynamic workers. No database access unless explicitly granted. No file system access. No network calls unless declared.<\/p>\n
That’s the headline. The reason anyone would migrate.<\/p>\n
But dynamic workers require the Cloudflare Workers Paid plan<\/a>. $5 a month minimum. If you deploy on the free tier, you get error code 10195. Switch to a paid plan. The sandbox \u2014 the entire reason EmDash exists \u2014 is not free.<\/p>\n Self-hosting doesn’t save you either. Run EmDash on your own Node.js server and sandboxed plugins don’t work at all. They run in-process. No isolation. No security advantage. You’re left with a beta CMS, zero plugin ecosystem, and the same attack surface as WordPress.<\/p>\n The code is free. The engine that makes it worth using is a monthly subscription.<\/p>\n Serverless billing sounds great in theory. Pay for what you use. Scale to zero. No idle server costs.<\/p>\n In practice, it means every page view, every admin click, every API call is a billing event. Workers bill per request and per CPU millisecond. D1 database reads bill per row. R2 operations bill per operation. KV lookups bill per read and write. One page view can hit four or five different billing meters simultaneously.<\/p>\n Someone on the Cloudflare forum did the math. A basic DDoS-style attack \u2014 10,000 IPs, one request per second<\/a> each \u2014 generates 26 billion requests in a month. On the paid plan, that’s roughly $13,000.<\/p>\n And here’s the kicker: Cloudflare does not offer a global spending cap. No kill switch. No way to say “stop charging me at $X.” You can set CPU time limits per request. You can configure rate limiting through WAF rules. But rate limiting is per IP, not a global request cap. A distributed bot attack from thousands of different IPs goes right through it.<\/p>\n WordPress hosting costs $20 a month. Flat. Predictable. If you get 10 visitors or 10 million, your bill stays the same. Your server might crash, but your credit card won’t.<\/p>\n EmDash flips that completely. And for small bloggers, freelancers, and publishers \u2014 the exact audience Cloudflare is targeting \u2014 that’s not a feature. It’s a liability.<\/p>\n Proponents of EmDash will say this: Cloudflare’s pricing is transparent. You know the per-unit costs upfront. You can monitor usage in the dashboard. You can set CPU time limits and WAF rules. Responsible operators manage their infrastructure. This is not a hidden cost problem; it’s a user education problem.<\/p>\n Fair point. Transparency matters. And yes, experienced developers can monitor dashboards and configure rate limits.<\/p>\n But here’s the dismantling: the people Cloudflare is targeting with EmDash are not experienced developers. They’re bloggers, small publishers, freelancers migrating from WordPress because they heard it’s insecure. These are people who want to publish content and not think about infrastructure. EmDash demands the opposite. It requires you to understand Workers billing, D1 pricing, WAF configuration, and CPU time limits \u2014 just to avoid a surprise bill. There is no built-in spending cap. No automated kill switch. No safety net. The most vulnerable users \u2014 the ones with the least infrastructure knowledge \u2014 are the most exposed to the worst-case scenario. That’s not a transparency problem. That’s a design problem.<\/p>\n EmDash is MIT licensed. The code is on GitHub. You can fork it. Read it. Run it locally.<\/p>\n But every meaningful feature requires Cloudflare infrastructure. The plugin sandbox requires dynamic workers, which only exist on Cloudflare’s paid runtime. The database uses D1, which is SQLite-compatible but not portable to Postgres or MySQL without rewriting. Media storage uses R2, which is S3-compatible but tightly integrated with Workers. Sessions use KV.<\/p>\n A production EmDash site on Cloudflare uses at minimum five separate Cloudflare products. Workers, D1, R2, KV, and Workers AI. Each is a separate billing line. None are portable.<\/p>\n Contrast that with WordPress. You can host it on a $5 VPS. Move it to AWS. Run it on a Raspberry Pi. Same code. Same functionality. Same cost structure. That portability is the actual spirit of open source. EmDash doesn’t have it.<\/p>\n Here’s what most coverage of EmDash overlooks: the billing unpredictability creates a perverse incentive for Cloudflare to not<\/em> build a spending cap.<\/p>\n Think about it. Cloudflare makes money when your site gets traffic. More requests, more database reads, more KV lookups, more billable events. A spending cap would limit their revenue from successful sites. It would also protect users from attacks, which is the right thing to do. But it would cap upside.<\/p>\n WordPress hosting providers have the opposite incentive. A flat-rate host makes the same $20 whether you get 100 visitors or 100,000. They’re incentivized to keep your site running efficiently. They lose money when you<\/a> get DDoSed, not gain it.<\/p>\nThe $13,000 Midnight Bill<\/h2>\n
The Strongest Counterargument \u2014 And Why It Fails<\/h2>\n
Vendor Lock-In Disguised as Open Source<\/h2>\n
The Real Second-Order Effect Everyone Misses<\/h2>\n