EmDash: Cloudflare's CMS for Astro. Not yet on client sites — but worth watching.

Cloudflare put out something interesting last month. They have released a CMS called EmDash — “the spiritual successor to WordPress” is the line they are using, and the architecture suggests they mean it. The core idea is a full-stack CMS built on Astro, deployed to Cloudflare Workers, with content stored in D1 (Cloudflare’s SQLite-on-the-edge) and assets in R2. End-to-end TypeScript. Plugins run in sandboxed Worker isolates. It is open-source under MIT and currently sits at v0.1.0.

I am not deploying it on client sites today. The ecosystem is too young — it is days old, the plugin library is essentially empty, and “stable in production” is not the right phrase for software at this point in its life cycle. But I am paying very close attention to it, because if it grows in the way the architecture suggests it can, it solves the structural problem with WordPress that I wrote about a week ago.

Why the architecture matters

The thing that keeps making WordPress sites get hacked is not really WordPress core. It is the plugin model. When you install a WordPress plugin you are giving a piece of unverified PHP, written by somebody you have never met, full unrestricted access to your site’s database, file system, network and cron schedule. It can do anything. There is no sandbox. The only thing standing between “this plugin updates the site footer” and “this plugin exfiltrates your customer data” is the goodwill of the plugin author.

EmDash takes a fundamentally different approach. Plugins run inside isolated Cloudflare Worker contexts, not inside the same process as the rest of the site. Each plugin declares a capability manifest — a list of what it actually needs permission to do — and the runtime enforces that. A plugin that updates the footer cannot read the database. A plugin that adds a new field to the admin cannot make outbound network calls. The author can lie about what the plugin needs, but they cannot give it more capability than the manifest allows, because the runtime won’t let them.

This is not a small distinction. This is the model that browser extensions have used for fifteen years and that mobile app stores have used for a decade. WordPress plugins have never had it. It is the thing that, in the long run, would have prevented the EssentialPlugin attack: even if the attacker had pushed a malicious update to thirty plugins, none of them could have done anything they had not already declared they might do.

Why the architecture is the easy part

Architecture diagrams are cheap. The hard part is the ecosystem.

WordPress is the dominant CMS not because the codebase is good — it isn’t — but because there is a plugin for everything. Memberships, e-commerce, forms, page builders, custom post types, integrations with every CRM and email provider in existence. For an EmDash to actually replace WordPress in the wild, that plugin ecosystem needs to materialise, and that takes years.

What EmDash has going for it on this front is that the plugin API is TypeScript and the build environment is modern. Writing a plugin for it is closer to writing an npm package than writing a WordPress plugin, and that lowers the barrier for anyone who already builds web software. There is also a built-in MCP server, meaning Claude or another AI tool can write plugins and manage content directly. That sounds like a gimmick today and may turn out not to be one.

What is going against it is that the WordPress plugin community has fifteen years of momentum, an installed base in the tens of millions, and a specific group of authors who make their living from it. They don’t move easily. The earliest adopters of EmDash will be developers building net-new sites, and the ecosystem will have to grow in their wake.

What I am actually doing

Right now: nothing. I am tracking the project, reading the release notes, and building a small personal site on EmDash to understand its bones. None of that touches a client engagement.

When the ecosystem matures — call it twelve to twenty-four months, depending on how many serious developers and plugin authors come over — I expect EmDash (or whatever EmDash has become by then) to be a real third option for the kind of mid-sized site where today I have to choose between “WordPress with all its baggage” and “static site with no CMS.” That third option, with proper capability-sandboxed plugins, is the thing the small-business web has needed for a decade.

For now, the recommendation stands: static sites for the brochure end, WordPress for the genuine CMS cases, custom Astro builds for the bespoke end. EmDash gets a row in the spreadsheet of “options I am evaluating,” and probably a follow-up post in twelve months when there is more to say.

If you are technical and curious, the Cloudflare blog post is worth twenty minutes. If you are a client trying to decide what CMS to put your business website on this year, the answer is still one of the three I already build with. EmDash is in the “not yet, but soon” pile.