Cloudflare launched EmDash on April 1, 2026, calling it the “spiritual successor to WordPress.” The pitch is seductive: TypeScript, serverless, sandboxed plugins, AI-native, MIT licensed. Developers who have wrestled with PHP, plugin bloat, and security headaches for years felt a flicker of hope.<\/p>\n
But EmDash is version 0.1.0. It has 89 commits on GitHub, was built in roughly two months with heavy AI coding assistance, and its lead engineer is transparent about it being an early developer beta. Before you migrate a client’s site or bet your own business on it, these seven limitations deserve your attention.<\/p>\n
Not because EmDash is bad. Because the wrong tool for a job is expensive, and the right tool for a future job may not be ready for today’s.<\/p>\n
The headline feature of EmDash is plugin sandboxing. Every plugin runs in its own V8 isolate via dynamic workers. It cannot touch your database, file system, or other plugins unless a capability manifest explicitly grants permission. This is genuinely superior to WordPress’s model, where a single compromised plugin can access everything.<\/p>\n
Here’s the catch: dynamic workers require Cloudflare’s Workers Paid plan, starting at $5 per month. On the free Cloudflare tier, plugins run in-process with no sandbox isolation. If you self-host EmDash on any Node.js server \u2014 your own hardware, AWS, a VPS \u2014 there is currently no sandbox support at all. The feature that justifies EmDash’s existence disappears the moment you step off Cloudflare’s paid infrastructure.<\/p>\n
This isn’t a minor limitation. It’s architectural. The code is MIT licensed, but the runtime that powers every meaningful security feature is proprietary Cloudflare infrastructure. One widely upvoted Hacker News<\/a> comment summarized it cleanly: “Open source, but architecturally locked in.”<\/p>\n WordPress runs on a $5 VPS, a Raspberry Pi, or a managed host you can switch in an afternoon. EmDash’s security model runs on Cloudflare’s Workers Paid plan. Those are not the same thing.<\/p>\n Traditional WordPress hosting charges a flat monthly rate. $20, $50, $100. Traffic spikes might slow your site or crash it, but your bill stays the same. You know what you’re paying.<\/p>\n EmDash is serverless. Every page view, admin panel click, API call, and plugin execution is a Cloudflare Workers invocation. Workers bill per request and per CPU millisecond. The paid plan starts at $5 and includes 10 million requests, but beyond that, you pay $0.30 per additional million requests plus CPU time charges.<\/p>\n One page view can hit multiple billing meters simultaneously: a Workers invocation, a D1 database read, an R2 storage operation, a KV lookup. Try predicting that monthly cost as a small business owner.<\/p>\n Someone on the Cloudflare forum did the math. A basic DDoS attack with 10,000 IPs making one request per second<\/a> each would rack up 26 billion billable requests in a month. There is no built-in spending cap. No kill switch. Cloudflare has historically declined to offer global spending limits on Workers. Your site keeps running, workers keep firing, and your credit card keeps getting charged.<\/p>\n Cloudflare offers mitigations: CPU time limits per request, WAF rate limiting. But rate limiting is per IP, not a global request cap. A distributed bot attack from thousands of different IPs goes right through it. And CPU limits control how long each request runs, not how many requests you can be billed for.<\/p>\n WordPress’s fixed post types (posts and pages) have frustrated developers for years. Workarounds like Custom Post Types UI and Advanced Custom Fields exist, but they store schema in the database, creating sync problems across environments.<\/p>\n EmDash ships with native custom content types. You can create a “Project” type with custom fields directly in the admin panel. This is, on paper, better than WordPress.<\/p>\n But the schema lives in the database. You configure it through clicks, not through code. There is no infrastructure-as-code approach for content types in the current version. No configuration file in the Astro config or anywhere in the repository to define your schema and deploy it alongside your admin interface.<\/p>\n For a solo developer running one site, this is fine. For an agency managing 50 client sites, this is a problem. Schema drift between environments \u2014 local, staging, production \u2014 becomes manual overhead. If you rebuild a staging database, you lose your content type definitions unless you remembered to export them. There is no Sanity, Payload CMS, and even Drupal (since version 4 or 5) handle this better by treating content models as code that deploys alongside the application. EmDash’s approach feels like a step backward for anyone who has experienced the pain of database-driven schema management at scale.<\/p>\n EmDash includes a WordPress migration tool. It can import posts, pages, media, and custom post types from a WXR export file or via a plugin. It even maps Yoast SEO fields to EmDash’s built-in SEO controls.<\/p>\n That’s all it imports.<\/p>\n2. Serverless Billing Has No Spending Cap<\/h2>\n
3. Content Types Live in the Database, Not in Code<\/h2>\n
git push<\/code>codecodecodecode for your schema.<\/p>\n4. The WordPress Migration Tool Imports Content, Not Websites<\/h2>\n