Cloudflare just launched a CMS built to replace WordPress. It’s called EmDash, it runs serverless on Cloudflare Workers, and it claims to fix the plugin security model that accounts for 96% of WordPress vulnerabilities. That’s a bold pitch for a platform that powers over 42% of the web.
We wanted to know if it holds up. So we migrated a real WordPress site to EmDash v0.1.0: 147 posts, 30 pages, three custom plugins, a custom Tailwind theme, and 2.3GB of media. Not a test blog. A production site with real content and real complexity. Here’s what we found.
The problems EmDash is solving
EmDash exists because WordPress has structural problems that plugins and patches can’t fix.
The security model is the biggest one. WordPress plugins run with full access to the database and filesystem. A vulnerability in one plugin compromises the entire site. EmDash takes a different approach: plugins declare what they need access to upfront (similar to OAuth permissions) and run in isolated sandboxes. A broken plugin can’t touch anything it didn’t ask for. That’s an architectural fix, not another security plugin bolted on top.
The infrastructure model is the other. WordPress requires a PHP server and a MySQL database, provisioned and maintained whether your site gets ten visitors or ten thousand. EmDash runs on Cloudflare Workers, scaling to zero when idle. No servers to patch, no database to manage, no infrastructure overhead between you and your content.
The technical foundation is built on Astro, TypeScript, and Tailwind. If those names don’t mean anything to you, the practical difference is this: modern component-based development instead of PHP templates, with better tooling for the team maintaining your site long-term.
The problems are real. The question is whether EmDash’s answers are ready.
What worked well
Content transferred cleanly. The import wizard brought over all 147 posts and 30 pages without data loss. WordPress’s block content converted to EmDash’s format automatically, and custom post types became EmDash collections on import. For sites with large content libraries, the content migration is usually the part that kills a project. Here, it worked.
Styling carried over directly. Both the WordPress site and EmDash use Tailwind, so the utility classes transferred 1:1 without a build tooling change. Only the template language changed (PHP to Astro components), not the look and feel. Custom CSS and custom classes work fine either way. The Tailwind overlap just meant one less thing to reconfigure during the migration.
The developer experience is a genuine upgrade. Composable components with typed props instead of PHP template files. Parallel data fetching instead of sequential WordPress queries. For a team maintaining a site over years, this is where modern architecture pays off. Not in the initial build, but in every change after it.
The plugin security model works as advertised. Plugins declare capabilities, run in isolation, and can’t access the database directly. This addresses WordPress’s core security problem at the architecture level. For site owners who’ve dealt with plugin vulnerabilities (or the anxiety of not knowing which plugin will be next), this is the feature that matters most.
Where it falls short
The content model is more structured, for better and worse. EmDash pages are composed from typed content blocks rather than the ad-hoc field groups and drag-and-drop builders WordPress editors are used to. The upside: the content model is explicit, consistent, and easier to maintain over time. The downside: every custom content type needs block development upfront. WordPress gives editors maximum flexibility out of the box at the cost of developer control. EmDash inverts that, giving developers full control at the cost of requiring more setup before editors can work independently.
The block system’s form inputs are also limited to basics (text, number, select, toggle). No media picker, no list inputs, no way to extend with custom element types in v0.1.0.
No plugin ecosystem. WordPress has 60,000+ plugins. EmDash has effectively zero third-party plugins. SEO tools, contact forms, analytics integrations, caching, security scanning: all of these need custom implementation or you wait for the ecosystem to develop. For most WordPress sites, the plugins are the product. They’re the reason the site does what it does without custom development. Losing them isn’t a tradeoff. It’s a restart.
v0.1.0 rough edges. Sparse documentation (we relied on reading source code more than once) and a bug in the visual editing toolbar that required patching. Expected for a first release, but it means your team is spending real time on workarounds that shouldn’t be necessary in a production tool.
”Migration” means rebuild
Every PHP template needs to be rewritten as an Astro component. WordPress hooks, shortcodes, and the template hierarchy have no equivalent in EmDash. Custom plugins need full rewrites. The content transfers, but everything around it (templates, functionality, integrations) gets rebuilt from scratch.
In terms of scope and budget, a WordPress-to-EmDash migration is closer to commissioning a new site that reuses your existing content. The timeline and cost should reflect a full build, not an upgrade or a platform switch. If you’re getting estimates, make sure they account for template rewrites, plugin replacements, and integration work. A quote that treats this as a platform switch is missing most of the project.
A platform migration is the extreme version of a more common problem: the architecture a site was built with determines whether updates are a refresh or a rebuild. The same patterns that make a WordPress site expensive to leave (content embedded in HTML, no reusable components, plugin glue holding the templates together) are what make any site expensive to redesign on the platform it’s already on.
If you’re weighing that rebuild cost against staying on WordPress or moving to something else entirely, the decision is less about the platform and more about whether your needs have outgrown it. We cover that calculation in when to build a custom web app vs. use off-the-shelf tools.
Who should care right now
Starting a new project from scratch? EmDash is worth serious consideration, especially if you’re already in the Cloudflare ecosystem. The Astro foundation, serverless deployment, and security model are genuinely strong. The tradeoff: thin documentation, no plugin ecosystem, and v0.1.0 rough edges. If your team can handle that, the technical foundation is sound.
Running an existing WordPress site? Wait. The migration effort is a full rebuild, the plugin ecosystem doesn’t exist, and the content block system needs more input types before editors can work as independently as they do in WordPress. Revisit when EmDash ships a plugin marketplace, richer block development tools, and a more mature editing experience. If your WordPress site has become slow or fragile, the fix usually isn’t a new platform. It’s building WordPress properly: a custom theme and custom blocks instead of plugin sprawl.
Evaluating CMS options in general? Put EmDash on your watch list. The architecture is the most thoughtful WordPress alternative we’ve seen. If Cloudflare executes on the ecosystem (plugin marketplace, community adoption, content tooling), this could become the default recommendation for content-heavy sites within a year or two. It’s not there today.
The gap between foundation and ecosystem
The architecture is right. The security model solves a real problem. The developer experience is a genuine improvement over WordPress’s PHP foundation. None of that is in question.
What’s missing is everything that grows around a CMS over 20 years: the plugins, the themes, the community answers on forums, the agencies that know it inside out, the documentation that covers every edge case. WordPress has all of that. EmDash has a strong v0.1.0 and Cloudflare’s resources behind it.
That gap will close. How fast depends on whether Cloudflare can attract plugin developers, ship content tooling improvements, and build the kind of ecosystem that makes site owners confident enough to switch. We’ll be testing each major release as it ships. If the ecosystem catches up to the architecture, this changes the CMS conversation entirely.
If you’re weighing a CMS move and want help thinking it through, we’re happy to talk.