Cloudflare Just Rebuilt WordPress From Scratch. It's a Sign of What's Likely to Come For All Legacy Systems

Cloudflare recently announced EmDash, a new open-source content management system it describes as "the spiritual successor to WordPress." The company said its AI coding agents rebuilt the WordPress open-source project from the ground up in two months. It's written in TypeScript, runs serverless, uses Astro as its web framework, and is MIT-licensed with no WordPress code used.

The technical pitch is interesting on its own, particularly that it's the first major Cloudflare and Astro joint project since its acquisition earlier this year. But the strategic argument behind EmDash is the part that should resonate with infrastructure leaders, because it's the same argument playing out across database migrations, authentication systems, and pipelines throughout the enterprise.

The plugin problem isn't fixable

WordPress powers over 40% of the internet. It created an entire economy of developers, agencies, and hosting providers. And its plugin architecture that made it extensible enough to dominate is the source of 96% of its security vulnerabilities. In 2025, more high-severity vulnerabilities were found in the WordPress ecosystem than in the previous two years combined.

The root cause is architectural. A WordPress plugin is a PHP script that hooks directly into the CMS. There is no isolation. Every plugin has direct access to the site's database and filesystem. Installing a plugin means trusting it with access to everything and trusting it to handle every malicious input perfectly.

Unfortunately, it isn't a bug that can be patched. It stems from a design decision made when WordPress launched 24 years ago, before AWS EC2 existed, before serverless was a concept, and before the threat landscape looked anything like it does today. The WordPress ecosystem has spent two decades building workarounds like marketplace vetting, manual plugin reviews, and reputation systems, but the fundamental problem persists because it's load-bearing. You can't retrofit isolation into an architecture that was designed for shared execution without breaking the ecosystem built on top of it.

The EmDash approach: capabilities, not access

EmDash's plugin model works differently. Each plugin runs in its own isolated sandbox as a Cloudflare Dynamic Worker and receives capabilities through declared bindings rather than direct access to underlying systems. A plugin declares exactly what it needs in its manifest: access to content lifecycle hooks, permission to send emails, ability to communicate with a specific external hostname. It cannot do anything else. It has no implicit network access, no database access, no filesystem access beyond what's explicitly granted.

The practical effect is that security decisions shift from "do I trust this code" to "do I trust these declared capabilities." A plugin with tens of thousands of lines of code can be evaluated based on its manifest alone. If it only requests read access to content and permission to send emails, that's all it can do, regardless of what the code contains. The architecture enforces the constraint, not the review process.

This is the same principle behind database-level Row Level Security, containerized microservices, and OAuth scoping where isolation by design rather than isolation by process. The concept isn't novel. What's notable is the argument that WordPress's architecture is too far gone to adopt it.

The real argument: when patching costs more than rebuilding

The CMS itself is almost beside the point. What Cloudflare is really arguing and demonstrating is that there's a category of legacy infrastructure where the security and maintenance costs of continuing to patch an aging architecture eventually exceed the cost of rebuilding from scratch. And that AI development tools have collapsed the rebuild timeline from years to weeks.

Cloudflare claims its agents rebuilt the entire WordPress feature set in two months. Even discounting for marketing optimism and considering EmDash is an early developer beta, not a production-ready WordPress replacement, the speed of the rebuild says something about where the cost curves are heading. If a team of AI coding agents can produce a functional CMS in two months, the calculus around "maintain versus rebuild" shifts dramatically for any system where the maintenance burden is security-driven.

Where this goes

The reality is that EmDash is still a v0.1.0 preview, and WordPress has 40% market share with a massive ecosystem and decades of accumulated functionality. Declaring WordPress "dead" because Cloudflare shipped a TypeScript CMS would be roughly as premature as declaring Oracle dead because Postgres exists.

The underlying argument that some legacy foundations have accumulated so much patchwork that they're more expensive to maintain than to replace doesn't depend on EmDash succeeding. It depends on the rebuild economics continuing to improve, which they will, because AI development tools are getting better faster than legacy systems are getting simpler.

For infrastructure leaders, the question EmDash raises is about the threshold at which maintaining a legacy foundation becomes more expensive than replacing it, and whether AI tools have moved that threshold closer than most organizations realize.