Cloudflare\u2019s EmDash CMS promises a revolution: plugins locked in isolated V8 sandboxes, ending the 96% of WordPress vulnerabilities that originate from plugins. It\u2019s a brilliant pitch. But there\u2019s a catch buried in the fine print \u2014 one that makes the entire security model conditional on remaining inside Cloudflare\u2019s paid ecosystem. If you self-host EmDash on a standard Node.js server, the sandbox disappears. Plugins run in-process. No isolation. No permission manifest enforced. You get the same architectural risk as WordPress, but with zero plugins and a brand-new CMS.<\/p>\n
This isn\u2019t a minor limitation. It\u2019s the defining weakness of EmDash\u2019s architecture \u2014 a single point of failure that forces a vendor lock-in for the feature that justifies the product\u2019s existence. And the company\u2019s response so far has been silence on a fix.<\/p>\n
To understand why EmDash can\u2019t sandbox plugins outside Cloudflare<\/a>, you need to understand the underlying technology. Every plugin in EmDash runs inside a V8 isolate<\/strong> \u2014 a lightweight, hardware-isolated execution context that Cloudflare calls a dynamic worker<\/strong>. When a plugin triggers, the isolate spins up in milliseconds, executes the code, and disappears. It has no direct access to the database, file system, or network. Instead, the plugin declares a capability manifest \u2014 read content, send email \u2014 and the runtime enforces that boundary down to the hardware memory protection level.<\/p>\n This works because Cloudflare\u2019s Workers runtime is built on V8 isolates combined with Linux namespaces, seccomp filters, and hardware memory protection keys. That stack is proprietary to Cloudflare. No other hosting provider replicates it. No open-source equivalent exists. When you<\/a> deploy EmDash to a Cloudflare paid plan, you get the full sandbox. When you run it locally with The code on GitHub is MIT-licensed. The runtime that makes it secure is not.<\/p>\n The strongest defense Cloudflare could offer is: \u201cEmDash is open source. You can run it anywhere. The sandbox is an optional feature of our paid infrastructure. That\u2019s a trade-off, not a flaw.\u201d<\/em><\/p>\n That sounds reasonable until you examine what \u201crunning it anywhere\u201d actually means without the sandbox. On a self-hosted Node.js server, EmDash has no plugin ecosystem \u2014 it launched with zero third-party plugins. The entire value proposition over WordPress is the security model. Remove that, and you\u2019re left with a v0.1 CMS written in TypeScript that has fewer features than WordPress had in 2005. The content editor is basic. Custom post types exist but must be created through the admin UI, not defined in code \u2014 a regression for developers who want schema-as-code. The theme system uses Astro, which is modern, but there are no pre-built themes beyond three starter templates.<\/p>\n In other words, the sandbox isn\u2019t a \u201cnice-to-have\u201d feature. It\u2019s the product. Without it, EmDash is an unfinished experiment that competes poorly against established alternatives like Ghost, Payload CMS, or even a plain Astro site with a headless CMS.<\/p>\n Cloudflare could have designed the sandbox to work with any Node.js runtime using a library like The lock-in doesn\u2019t stop at features. EmDash\u2019s serverless pricing model on Cloudflare introduces a financial single point of failure. Each page view triggers multiple Cloudflare services: a Workers invocation, a D1 database read, an R2 storage check, and possibly a KV lookup. Each service meters separately. Workers cost $0.30 per million requests after the first 10 million. D1 charges per row read. R2 charges per operation.<\/p>\n A small business owner migrating from fixed-price WordPress hosting ($20\/month) to EmDash on Cloudflare faces unpredictable bills. One documented scenario on the Cloudflare forum calculated that a basic DDoS attack \u2014 10,000 IPs, one request per second<\/a> each \u2014 could rack up 26 billion billable requests in a month. At Workers pricing, that\u2019s roughly $7,800 before CPU time. Add D1 and R2 charges, and you\u2019re past $13,000. Cloudflare does not offer a global spending cap. There is no kill switch. The site keeps running, and the credit card keeps charging.<\/p>\n WordPress hosting has its own costs \u2014 managed plans at $50\u2013$100\/month, plus plugin subscriptions. But those are predictable. You know exactly what you\u2019ll pay. EmDash\u2019s serverless architecture inverts that certainty. For a CMS targeting bloggers and small publishers, this is a risk most won\u2019t understand until they get the invoice.<\/p>\nnpm create m-dash-latest<\/code>codecodecodecode and choose Node.js, plugins execute in the same process as the CMS core. One vulnerable plugin can read your entire SQLite database, modify files, or exfiltrate data.<\/p>\nThe Counterargument \u2014 and Why It Collapses<\/h2>\n
isolated-vm<\/code>codecodecodecode or vm2<\/code>codecodecodecode. They chose not to. That\u2019s not a trade-off; it\u2019s a deliberate architectural lock-in.<\/p>\nThe Billing Trap: Serverless Surprise<\/h2>\n
Why the Plugin Ecosystem Won\u2019t Save It<\/h2>\n