On 1 April 2026 Cloudflare did something that, at first glance, looked like an elaborate joke: they announced EmDash, a brand-new open-source content management system pitched as the "spiritual successor to WordPress." Anyone who has worked in the WordPress space long enough has seen challengers come and go. Ghost, Craft, Statamic - all technically excellent, none with the ecosystem gravity to shift the needle. So why pay attention this time?
Because EmDash is not just a new CMS. It is the first real-world showcase for Dynamic Workers, a genuinely new infrastructure primitive from Cloudflare that changes what serverless applications can do at runtime. And that, more than any theme engine or admin panel, is the interesting part.
What EmDash actually is
EmDash is a full-stack, serverless CMS written entirely in TypeScript and built on Astro. It runs on Cloudflare Workers, stores data in D1 (Cloudflare's SQLite-based database) and R2 (object storage), and ships under the MIT licence. The source is on GitHub and you can deploy it to your own Cloudflare account today as a v0.1.0 preview.
At Blue 37 we have been building with Astro for a while now - we know first-hand how well it handles content-heavy sites, how its island architecture keeps pages fast, and how its growing ecosystem makes developer experience genuinely pleasant. Seeing it at the core of EmDash makes the project feel immediately approachable. If you have built an Astro site before, the theming model will look familiar: themes are Astro projects composed of pages, layouts, components, and styles.
Content is stored as structured JSON (portable text) rather than raw HTML. That is a deliberate choice. Structured content is easier for machines to read, transform, and move between systems. It also means AI agents can work with your content directly, without needing to parse markup.
The security model that matters
Cloudflare's pitch rests on a single, uncomfortable statistic: 96% of WordPress security vulnerabilities originate in plugins. The reason is architectural. In WordPress, every plugin shares the same PHP runtime, the same database connection, and the same filesystem. A poorly written contact form plugin has the same level of access as your caching layer.
EmDash takes a fundamentally different approach. Each plugin runs inside its own isolated sandbox - a Dynamic Worker - and must declare exactly what it needs in a manifest before installation. Want to read content? Declare read:content. Need to send email? Declare email:send. The permissions are transparent, granular, and enforced at the infrastructure level. If a plugin does not ask for database write access, it simply cannot write to the database.
If that sounds like the OAuth permission prompts you see when connecting apps to your Google account, the comparison is intentional. It is a model web developers already understand, applied to a problem that has plagued WordPress for two decades.
Dynamic Workers: the real story
This is where things get properly interesting for anyone who builds on Cloudflare.
Dynamic Workers are a new runtime primitive that lets you spin up Workers programmatically, at runtime, to execute arbitrary code in a sandboxed environment. They use V8 isolates - the same JavaScript engine that powers Chrome - which start in a few milliseconds and consume a few megabytes of memory. Compare that to containers, which typically need hundreds of milliseconds to boot and hundreds of megabytes to run.
The practical difference is significant. You can start a new isolate for every single request, run a snippet of code, and dispose of it afterwards. There is no need to keep sandboxes warm or reuse them in ways that compromise isolation. Cloudflare describes no hard limits on concurrent sandboxes or creation rates.
For EmDash, Dynamic Workers solve the plugin security problem elegantly. But the implications reach well beyond content management:
- AI agent code execution - let agents write and run code in isolated environments without risking your production infrastructure
- Multi-tenant platforms - give each customer their own sandboxed runtime with precisely scoped bindings
- Rapid prototyping - deploy preview environments in milliseconds rather than minutes
- User-uploaded code - run untrusted third-party code safely, something that has historically required heavyweight container orchestration
Cloudflare has also released helper libraries alongside Dynamic Workers. @cloudflare/worker-bundler handles npm dependency resolution and bundling with esbuild. @cloudflare/shell provides a virtual filesystem backed by SQLite and R2. These are not CMS-specific tools. They are building blocks for an entirely new category of applications.
The pricing model during beta is straightforward: $0.002 per unique Worker loaded per day, plus standard CPU and invocation costs. That scale-to-zero model means you only pay for what actually runs.
The AI-native angle
EmDash has been designed with the assumption that AI agents are first-class users of a CMS, not an afterthought bolted on via plugins. It ships with an MCP server for direct programmatic interaction, a CLI that outputs JSON for easy parsing, and documentation structured for machine consumption.
Joost de Valk, the founder of Yoast and someone who has shaped WordPress SEO for over a decade, has been vocal about this angle. His view is that a CMS designed for AI agents to build on naturally is difficult to resist. The round-trip Markdown support means agents can export content, edit it externally, and reimport it cleanly. The structured JSON content model means agents can manipulate content without wrestling with HTML parsing.
There is even a playground that generates full sites from prompts using Workers AI. Whether or not you consider that a gimmick today, it signals a clear direction: the CMS of the future is one that works as well for automated workflows as it does for human editors.
The elephant in the room
For all its technical merit, EmDash faces the same challenge every WordPress alternative has faced: the ecosystem. WordPress has over 60,000 plugins, decades of community knowledge, and an enormous pool of developers who know it inside out. EmDash has a v0.1.0 release and an empty plugin directory.
History is not encouraging for technically-superior-but-ecosystem-light alternatives. Technical excellence alone has never been enough to displace WordPress at scale. Adoption is driven by available plugins, themes, community support, and the sheer weight of existing content and expertise.
That said, EmDash has a few things working in its favour that previous challengers did not:
- Cloudflare's distribution - it runs on infrastructure that millions of developers already use
- Astro's momentum - the framework has a growing community and is well-represented in LLM training data, which means AI tools can generate EmDash themes and plugins more effectively
- MIT licensing - more permissive than WordPress's GPL, giving developers and businesses more flexibility
- AI-native architecture - if the shift towards agent-driven development continues (and all signs suggest it will), a CMS built for that world has a structural advantage
- WordPress migration tooling - EmDash supports WXR file imports and includes guides for porting themes and plugins, which lowers the barrier to trying it
The portability question
EmDash is open source and MIT-licensed. It is built on Astro, a widely adopted framework, and uses portable abstractions at the data layer: Kysely for SQL, S3-compatible APIs for storage. In theory, you can deploy it to Netlify, Vercel, or any Node.js server with SQLite. Cloudflare has been clear about this, and it is genuinely commendable.
But here is the catch. The plugin sandboxing that forms the centrepiece of EmDash's security pitch is built entirely on Dynamic Workers, which are a Cloudflare-specific runtime primitive. When you deploy EmDash to another host, plugins run in the main Node.js process without isolate-level sandboxing. You can mitigate this with container-level isolation, strict permissions, and thorough code review, but those are operational workarounds rather than architectural guarantees.
That creates an awkward tension. On of the strongest arguments for choosing EmDash over WordPress is the security model. But to get that security model, you need to run on Cloudflare. One of WordPress's enduring strengths, is that you can host it practically anywhere: a shared hosting account, a VPS, a managed platform, your own metal, even in the browser. That portability has been a central part of WordPress's dominance and to the freedom it gives site owners.
EmDash is not locked to Cloudflare in the way a proprietary SaaS platform is locked to its vendor. You can take the code and run it elsewhere. But you lose the feature that justifies choosing it in the first place. That is a softer form of lock-in, but it is lock-in nonetheless, and it is worth being honest about.
For the project to truly succeed as a WordPress successor, the community will need either a portable sandboxing layer that works outside Cloudflare, or enough confidence in Cloudflare's long-term stewardship that the dependency feels acceptable. Neither is settled yet.
Our take
At Blue 37, we are genuinely tool-agnostic. We pick the right technology for each project rather than fitting every problem into the same stack. We have built with WordPress for decades, we still do, we also work with SvelteKit, Astro, Deno, and Bun today, and we evaluate new tools on their merits.
EmDash is not ready for production client work yet. It is a v0.1.0 preview with no plugin ecosystem, unanswered questions about long-term governance, and a security model that is currently tied to a single hosting provider. We would not recommend migrating an existing WordPress site to it today.
But it is worth watching closely, for three reasons:
- The security model is right in principle. The idea that plugins should declare their capabilities and run in isolation is not radical - it is how we already think about permissions in every other context, from mobile apps to OAuth scopes. WordPress's shared-everything architecture is the outlier, and EmDash makes a compelling case for what a capability-based alternative looks like in practice. Whether that model can be made portable is the open question.
- Dynamic Workers are genuinely exciting infrastructure. Even if EmDash itself does not achieve mass adoption, the underlying primitive opens up possibilities for multi-tenant applications, AI agent tooling, and sandboxed code execution that were previously impractical at the edge. We expect to be building with Dynamic Workers regardless of whether EmDash takes off.
- WordPress is not going anywhere soon. It powers a vast share of the web and has a community, ecosystem, and institutional knowledge base that no new entrant can replicate overnight. But the ideas in EmDash - capability-based plugins, structured content, AI-native workflows - represent the direction the web is heading. Even if you stay on WordPress, these concepts will shape what you expect from your tools.
If you are curious, the EmDash playground lets you spin up a demo without committing to anything. And if you want to talk about whether EmDash, WordPress, or something else entirely is the right fit for your next project, get in touch.