Cloudflare moved its own blog onto a CMS it just launched and called it the spiritual successor to WordPress. That sentence is doing a lot of work, so let me slow down. The same week, Ethan Sholly’s Self-Host Weekly newsletter noted at least one new content management system submission per week from readers, two of them this week alone. The pace has gotten strange.
The EmDash reveal was framed as a quiet migration rather than a launch event. Cloudflare describes it as an open-source project built on top of their developer platform. The team’s own blog is now running on it, which is a brave move and also the kind of thing that exposes every bug in production within a week. I read the announcement, the docs page, and a few angry threads, and what I want to do here is talk about why this story matters, what it tells us about the CMS space, and where I think the line is between a real successor and a project that will be dead by next year.
Why the CMS pile is growing in the first place
The simplest explanation is also the one nobody wants to say out loud. WordPress is fine. WordPress is not exciting, but it is fine. It runs a huge slice of the web, the plugin catalog is unmatched, and the migration story is well understood. Most teams do not need a new CMS. They need their existing CMS to stop fighting them.
So why does the pipeline keep producing new options? Three reasons show up consistently:
- AI hype is the funding tailwind. Investors have been writing checks for anything with “AI” and “content” in the deck. A new CMS with an AI block editor slides right in.
- The static site generator audience never left. Hugo (a Go-based static site generator), Astro, and Eleventy users are a real crowd. Some of them want a CMS-shaped front end without giving up the static output.
- Builders like building CMSes. Ethan is right that this is a category people rebuild because they think they can. They usually can, and then they cannot keep up with maintenance.
None of those reasons is a structural failure of WordPress. They are reasons a new project might get started, not reasons a new project will survive.
What Cloudflare actually shipped
The EmDash project page is sparse but does a few specific things differently. The editor is a block-based interface. Posts and pages are stored as Markdown files in a Git repository. Deployment targets the Cloudflare Workers platform, which means the runtime is edge-deployed (meaning your pages render from servers close to the visitor, not from a single origin box). That last bit is the part most WordPress hosts cannot match without bringing up a CDN in front of a PHP backend.
The version Cloudflare is running on its own blog is not the latest tagged release, which is a tell. Production users always run one or two versions behind the marketing site. Anyone who has ever maintained software recognizes the smell.
I will say the obvious nice thing about this kind of architecture. If you are already a Cloudflare shop, you can route, cache, and deploy without leaving the dashboard. That removes a real layer of glue code. The not-obvious thing is that you also inherit Cloudflare’s outage profile, which has not historically been perfect. Pick your trade-off.
The 80/20 question every new CMS has to answer
Here is the test I would apply before installing anything new:
- Can I export everything? If the export story is “you can fork the Git repo,” great. If the export story requires running a script, walk away.
- Has the project been alive for more than 18 months? Last commit in the last 30 days is the minimum. Last release within 6 months is better.
- Is there a migration path FROM the thing I currently use? Not a “we are working on it.” An actual importer.
- Is the maintainer or maintainer team named? Anonymous CMS projects are how you get ghost-rot (silent abandonment after the founder gets bored). Named maintainers are not a guarantee, but they are a signal.
- Does the dependency tree touch fewer than 50 packages? More than 50 means a security update will eventually break something you care about.
Most new CMS projects fail at least two of those. The ones that survive pass all five.
What the Ethan’s-note tag change tells us
Ethan temporarily pulled the “AI-assisted apps” tag from his newsletter because readers were confusing AI-assisted apps with vibe-coded apps. That is a taxonomy problem with a real diagnosis underneath it. The terms overlap in casual use, but they mean different things. An AI-assisted app uses AI for some feature (summarization, search, smart suggestions). A vibe-coded app is one you built by typing “make me an app” into a chat box and shipping whatever came out. The trust profile is different. The maintenance burden is different. The bug rate is different. Conflating them helps nobody.
The cleanest split I have seen is:
- AI-assisted. Human wrote the code. AI is a feature.
- Vibe-coded. AI wrote most of the code. Human is the editor.
- Pure AI-generated. AI wrote all the code. Human did not review before shipping.
Most projects I see today are in the first category. The newsletter readers were probably reading “AI-assisted” as “vibe-coded” and dismissing things they would have actually liked. The fix is to be honest about which category a project is in. Ethan is going to do that with new tags. That is the right move.
Why most new CMS projects will not survive
The graveyard of open-source CMS projects is enormous. Ghost, Plenti, TinaCMS, Keystone, Apostrophe, and dozens of others sit at varying activity levels, and most of them had enthusiastic launches. The pattern is consistent. A small team builds a beautiful v1. The team burns out or moves on to the next idea. The community fills in for a while. Then the security patches stop landing, and the project dies a slow death.
Cloudflare has the resources to maintain a CMS for ten years. Most teams do not. That is not a criticism. It is a structural observation. Maintenance is what kills most software, and most teams are not sized for it.
A real rule of thumb: if the founding team is fewer than five people and none of them are paid full-time on the project, the project has a five-year horizon at best. Plan accordingly.
Trade-offs you should actually think about
Before you install EmDash, or any of the other new CMS projects showing up in your feed, here is the honest list:
- Edge deployment is fast, but debugging is harder. A 500 error that points to a line in a Worker is not the same as a 500 error that points to a PHP file you can edit locally.
- Git-as-database is great for versioning, terrible for non-technical editors. If your editor is not comfortable with a pull request, you are going to spend weekends fixing typos in commits.
- Cloudflare lock-in is real. Moving off EmDash means rewriting your build pipeline and your edge config. That is not a weekend project.
- A small core with a healthy plugin system beats a monolith. WordPress survived because of plugins, not in spite of them.
- Backup workflows have to be designed in on day one. If you cannot back it up, you do not own it. Period.
What I would tell past me about new CMS projects
If I could send one message back to myself three years ago, before I installed the second CMS project that year, it would be this:
- Check the last commit date before you clone the repo. Three months stale is a yellow flag. A year stale is a red flag.
- Make sure exports work cleanly before you write a single post. If the export story is “you can fork the Git repo,” fine. If it requires running a script, walk away.
- Authentication is harder than it looks. Most new CMS projects skip multi-user roles and permissions. Plan to add it yourself.
That is the whole game. The EmDash launch is interesting because Cloudflare has the resources to actually maintain a CMS for a decade. Most of the other projects showing up in your feed do not. Pick accordingly.
The CMS space is not going to stop producing new projects. The pipeline is fueled by AI hype, builder enthusiasm, and a real desire for something better than WordPress. The honest answer is that WordPress is fine, and the new projects are mostly fine too, with asterisks. Pick the one whose maintenance story you can live with for ten years. That is the only test that matters.