Cloudflare\u2019s EmDash CMS promises a serverless paradise: scale to zero, pay only for what you use, no more managing PHP servers. But that promise has a dark side. One DDoS attack could hit you with a $13,000 bill \u2014 and there is no built-in spending cap to stop it.<\/p>\n
The math is straightforward. A botnet hitting 10,000 APIs with one request per second<\/a> each generates roughly 26 billable requests in a month on Cloudflare\u2019s Workers plan. At $0.30 per million requests after the first 10 million, plus CPU time charges and additional database reads, the cost escalates fast. Someone on the Cloudflare forum<\/a> calculated exactly that scenario: $13,000 US dollars in a single month.<\/p>\n That\u2019s not a theoretical edge case. It\u2019s a direct consequence of EmDash\u2019s serverless billing model.<\/p>\n Traditional WordPress hosting charges a flat monthly fee. Whether you get 10 visitors or 10 million, your bill stays the same. EmDash flips that: every page view, every admin panel click, every API interaction is a Cloudflare Worker invocation. Workers bill per request and per CPU millisecond. The paid plan starts at $5 a month and includes 10 million requests. After that, you pay $0.30 per additional million requests, plus CPU time.<\/p>\n But that\u2019s not the only meter running. A single page view can trigger D1 database reads (billed per row), R2 storage operations (billed per operation), and KV lookups (billed per read and write). One visitor can hit four or five different billing meters simultaneously.<\/p>\n For a small business owner or blogger migrating from WordPress because they heard it\u2019s insecure, this is a nightmare. They want to publish content and not think about infrastructure. EmDash gives them the exact opposite: unpredictable monthly costs with no ceiling.<\/p>\n Here\u2019s the position I\u2019ll defend: EmDash\u2019s serverless billing model, combined with the absence of a global spending cap, makes it unsuitable for any site that cannot afford a surprise $13,000 invoice. The architecture was built for scale and security, but it ignored the practical reality of running a real-world website under bot traffic.<\/p>\n Cloudflare\u2019s own documentation confirms that there is no built-in kill switch or global request cap. You can set CPU time limits per individual request. You can configure rate limiting through WAF rules. But rate limiting is per IP address, not a global request cap. A distributed bot attack from thousands of different IPs goes right through it. And CPU limits only control how long each request runs, not how many requests you get billed for.<\/p>\n The people most likely to adopt EmDash \u2014 bloggers, small publishers, freelancers \u2014 are precisely the ones who will not configure WAF rules and monitor Cloudflare dashboards daily. They want a CMS that just works. EmDash gives them a ticking financial bomb.<\/p>\n The strongest counterargument is this: Cloudflare does offer mitigations. You can set up WAF rate limiting rules, you can configure CPU time limits, and you can monitor your usage with alerts. If you know what you\u2019re doing, you can protect yourself. The problem is your fault for not configuring it.<\/p>\n This argument fails for three reasons.<\/p>\n First, rate limiting per IP does nothing against a distributed botnet. Modern DDoS attacks originate from thousands of unique IPs. Each IP makes a small number of requests. Rate limiting per IP won\u2019t trigger because no single IP exceeds the threshold. The aggregate, however, can easily blow through your 10 million request allowance in hours.<\/p>\n Second, Cloudflare offers no way to set a hard dollar cap. There is no \u201cstop billing me after $500\u201d switch. The only way to stop the charges is to manually disable your site or delete your account \u2014 neither of which is practical mid-attack. By the time you realize what\u2019s happening, the bill has already accumulated.<\/p>\n Third, the target audience for EmDash is not DevOps engineers. It\u2019s people who used to click \u201cInstall WordPress\u201d on their hosting panel. Expecting them to configure Cloudflare\u2019s WAF, rate limiting, and billing alerts is unrealistic. The product should protect them by default. It doesn\u2019t.<\/p>\n Most discussions about EmDash\u2019s billing focus on the immediate horror story: the $13,000 bill. But the deeper issue is that this kills the \u201cserverless for everyone\u201d promise. Serverless was supposed to democratize infrastructure \u2014 make it cheap and auto-scaling so small sites could compete with big ones. But if a small site can\u2019t predict its monthly costs, serverless becomes a liability, not a benefit.<\/p>\n The second-order effect is clear: EmDash will push small publishers back to flat-rate WordPress hosting, not because WordPress is better, but because a known $20\/month bill is safer than a mystery bill with no ceiling. Cloudflare has built a technically impressive CMS that is financially hostile to the exact audience it claims to serve.<\/p>\n If you are considering EmDash for a production site, understand this: the free tier runs without sandboxed plugins \u2014 the very feature that justifies the project. The paid tier gives you sandboxing but exposes you to uncapped billing. And if you self-host on Node.js, you lose sandboxing entirely.<\/p>\n The code is MIT licensed. The runtime that powers every meaningful feature is not. That\u2019s not open source \u2014 that\u2019s a vendor lock-in disguised as one.<\/p>\n","protected":false},"excerpt":{"rendered":" Cloudflare\u2019s EmDash CMS promises a serverless paradise: scale to zero, pay only for what you use, no more managing PHP servers. But that promise has a dark side. One DDoS attack could hit you with a $13,000 bill \u2014 and there is no built-in spending cap to stop it. The math is straightforward. A botnet […]<\/p>\n","protected":false},"author":7,"featured_media":99265,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/en\/98022.png","fifu_image_alt":"EmDash's Hidden Billing Trap: Why Bot Traffic Could Cost You Thousands","footnotes":""},"categories":[31],"tags":[],"class_list":["post-98022","post","type-post","status-publish","format-standard","has-post-thumbnail","category-technology"],"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/en\/98022.png","fifu_image_alt":"EmDash's Hidden Billing Trap: Why Bot Traffic Could Cost You Thousands","_links":{"self":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/posts\/98022","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/comments?post=98022"}],"version-history":[{"count":1,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/posts\/98022\/revisions"}],"predecessor-version":[{"id":99266,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/posts\/98022\/revisions\/99266"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/media\/99265"}],"wp:attachment":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/media?parent=98022"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/categories?post=98022"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/tags?post=98022"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}How EmDash\u2019s Billing Model Works \u2014 and Why It\u2019s Dangerous<\/h2>\n
The Defensible Position: EmDash\u2019s Architecture Is Fundamentally Flawed for Cost Predictability<\/h2>\n
The Strongest Counterargument \u2014 and Why It Fails<\/h2>\n
What Most Coverage Misses: The Second-Order Effect on Serverless Adoption<\/h2>\n
One Final Warning<\/h2>\n