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.
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.
Open source, but architecturally locked in.
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.
1. The Sandbox Plugin Security Model Requires Cloudflare’s Paid Runtime
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.
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 — your own hardware, AWS, a VPS — 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.
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 comment summarized it cleanly: “Open source, but architecturally locked in.”
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.
2. Serverless Billing Has No Spending Cap
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.
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.
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.
Someone on the Cloudflare forum did the math. A basic DDoS attack with 10,000 IPs making one request per second 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.
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.
3. Content Types Live in the Database, Not in Code
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.
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.
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.
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 — local, staging, production — becomes manual overhead. If you rebuild a staging database, you lose your content type definitions unless you remembered to export them. There is no git pushcodecodecodecode for your schema.
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.
4. The WordPress Migration Tool Imports Content, Not Websites
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.
That’s all it imports.
It does not migrate your plugins, your theme, your custom functionality, your WooCommerce store, your membership system, your forms, your SEO configuration, your redirects, your user roles, or any of the 12 to 15 plugins the average WordPress site runs. All of that must be rebuilt from scratch.
WordPress stores content as HTML in the database. EmDash uses portable text, structured JSON. This is not a simple database export and import. You are converting between fundamentally different content formats. For any site with custom blocks, advanced layouts, or complex content structures, that migration is a serious engineering project — not a weekend task.
The tool is honest about its scope. It tells you upfront what it can and cannot do. But if you’re evaluating EmDash as a migration target for an existing WordPress site with years of content, custom theme work, and a plugin stack you depend on, understand that “migration” currently means “content extraction, then rebuild everything else.”
5. The Plugin Ecosystem Is Zero
WordPress has over 62,000 plugins. WooCommerce powers 35% of all e-commerce. Elementor runs on 10 million sites. Yoast SEO serves another 10 million. The average WordPress site runs 12 to 15 plugins. That’s not an ecosystem; it’s an economy.
EmDash launched with essentially zero third-party plugins. There is no marketplace, no review queue, no community of developers publishing extensions. The codebase ships with a forms plugin and basic SEO, but that’s it.
History is brutal here. Ghost launched over a decade ago with objectively better technology than WordPress. It has roughly 0.1% market share. Craft CMS and Statamic are technically excellent and ecosystem-starved. As one commenter put it: “People aren’t on WordPress because of WordPress. They’re on WordPress because of WooCommerce, a million themes, integrations for every stupid internal business API on the planet.”
EmDash’s counter-strategy is AI. The built-in MCP server and agent skills files let AI coding tools generate plugins and themes programmatically. The MIT license removes GPL friction. In theory, you can prompt an agent to build whatever plugin you need. In practice, that assumes the agent can produce production-quality, secure, well-tested code for every integration your site requires.
If your site needs e-commerce, a membership system, a booking calendar, or integration with a CRM, you’re looking at weeks of custom development — assuming the functionality exists yet. On WordPress, those are plugin installs.
6. The Editor Experience Is Minimal
EmDash ships with a block editor that supports portable text — structured JSON rather than raw HTML. It handles headings, lists, images, embeds, and reusable sections. It is functional.
It is not WordPress’s block editor (Gutenberg). It is not Elementor, Beaver Builder, or any modern page builder. It is a basic editor reminiscent of what WordPress offered fifteen years ago. There is no drag-and-drop layout builder, no global style system, no pattern library, no real-time collaborative editing that doesn’t lose data (multiple testers reported content loss when editing in split tabs).
One reviewer who tested the beta ran into passkey authentication failures on Linux and a “page not found” error on the magic link fallback. Another noted that centered text without text-wrap: balancecodecodecodecode created ugly line breaks — a minor UI polish issue, but indicative of the overall maturity level.
For a developer who writes markdown and deploys via CLI, this may be acceptable. For a content team that needs to produce visually rich pages without developer involvement, it is not ready.
7. The Business Model Incentives Point One Direction
Matt Mullenweg, WordPress co-founder, published a detailed review of EmDash days after launch. He wrote that the product is “very solid” and praised the engineering. Then he added: EmDash was created to sell more Cloudflare services.
He’s not wrong.
Every EmDash site on Cloudflare uses at minimum five Cloudflare products: Workers for compute, D1 for the database, R2 for media storage, KV for sessions, and Workers AI. Each is a separate billing line. None are portable. You cannot take a D1 database and move it to AWS. You cannot migrate R2 buckets to Azure without rewriting your storage layer. You cannot replicate the V8 isolate sandbox anywhere else.
The code is MIT licensed. The runtime that powers every meaningful feature is proprietary Cloudflare infrastructure. That’s not malice; it’s a business model. Cloudflare is a for-profit company. Open-sourcing the code builds trust and community. The lock-in is architectural, not legal.
Compare this to WordPress. You can move a WordPress site from any host to any other host in an afternoon. Same code, same database, same functionality. That portability is a feature that EmDash, despite claiming to be the “spiritual successor,” does not offer.
The Practical Takeaway
If you are starting a greenfield content site in TypeScript, security is your top concern, and you are comfortable managing Cloudflare infrastructure, EmDash is worth evaluating. The architecture is coherent. The sandbox model solves a real problem. The economics at low traffic are compelling — a small blog on the free tier costs roughly $15 per year for a domain name.
But if you need e-commerce, a mature plugin ecosystem, predictable billing with no surprise bills, or the ability to move hosting providers on your terms, EmDash is not ready. And the features it will need to become ready — a plugin marketplace, spending caps, infrastructure portability, a content-type-as-code approach — are not trivial. They may not align with Cloudflare’s incentives to build them.
WordPress has real problems. Security is structurally broken. Governance is fragile. The architecture belongs to a different era. But it works, and it has for 24 years. EmDash is the most architecturally coherent challenge WordPress has ever faced. That does not mean it is ready to replace it.
- What is EmDash?EmDash is a TypeScript-based, serverless content management system launched by Cloudflare on April 1, 2026, as a spiritual successor to WordPress.
- Does EmDash's sandbox security work on the free tier?No, on the free Cloudflare tier, plugins run in-process with no sandbox isolation. The sandbox requires Cloudflare's Workers Paid plan.
- Can EmDash be self-hosted?Yes, the code is MIT licensed, but self-hosting on Node.js servers currently offers no sandbox support, eliminating the key security feature.
- How does EmDash billing compare to WordPress?WordPress charges a flat monthly rate, while EmDash uses serverless billing with per-request and per-CPU charges, making costs unpredictable.
- Is EmDash portable like WordPress?No, EmDash is architecturally locked into Cloudflare infrastructure, whereas WordPress sites can be moved between hosts easily.
