Yesterday, Cloudflare announced a new CMS called emdash CMS.
And they didn’t exactly tiptoe into the room.
They positioned it as a kind of “spiritual successor” to WordPress, built from the ground up to fix what they see as the platform’s biggest flaws, especially around plugin security and outdated architecture.
It’s a full-stack, serverless CMS, built with modern tooling, designed for the edge, and wired for an AI-first world.
In other words:
This is not a plugin.
Not a framework.
Not a “better theme system.”
This is Cloudflare saying:
“What if we rebuilt WordPress entirely?”
Which is… quite a sentence.
and this is where it gets interesting
Because when very smart people rebuild something from scratch, they tend to fix the problems they can see most clearly.
And the problems Cloudflare sees are very real:
- Plugin security (sandboxing, isolation)
- Serverless scaling
- Modern developer experience
- AI-native programmability
All of which make perfect sense…
If you are looking at the world from inside an infrastructure company.
the law of perspective (or: why developers think about data models at night)
Over the years, I’ve noticed a simple pattern:
You don’t see problems as they are.
You see problems as you experience them.
If you are a developer, your problems look like:
- “This data model is messy”
- “Plugins have too much access”
- “Why is this not more structured?”
- “Why does this feel bolted together?”
If you are a small business owner, your problems look like:
- “Why did bookings drop?”
- “What should I post this week?”
- “How do I get more customers?”
- “Why is this plugin asking me to configure something I don’t understand?”
These are not the same problems.
One of these people is thinking about architecture.
The other is thinking about survival.
inside the building, everything looks like infrastructure
If you sit inside Cloudflare, surrounded by APIs, edge networks, and people who casually use the phrase “isolate runtime” in conversation, a very natural idea emerges:
“What if we rebuilt the CMS properly?”
And to be fair, emdash does some genuinely thoughtful things:
- A schema-driven content model
- Sandboxed plugins with limited capabilities
- A cleaner separation between content and presentation
- An Astro-based frontend system
- A design that fits neatly into a serverless, API-first, AI-friendly world
If you are a developer, this feels like someone has finally tidied your desk.
And it’s a very nice desk.
the thing about tidy desks
The problem is that most people are not trying to tidy their desk.
They are trying to run a business from it while:
- replying to emails
- posting on social
- updating their website
- wondering why traffic dropped
- and occasionally eating something directly over the keyboard
From that perspective, the big problems are not:
- “We need a better schema system”
The big problems are:
- Plugin discovery is chaotic
- There are too many choices
- Onboarding is confusing
- Nothing feels connected
- “Easy” often isn’t
Very few people are lying awake thinking:
“If only my CMS had a more elegant content model.”
a brief moment about plugins (where reality lives)
Plugins are where the real world quietly shows up.
In systems like WordPress:
- People install a few plugins
- They stick with what works
- They avoid complexity
- They do not wake up excited about configuring things
And importantly:
They are not primarily trying to design perfect data structures.
They are trying to:
- get bookings
- send emails
- improve SEO
- sell things
- be found
emdash spends a lot of time solving problems like plugin security, isolation, and capability boundaries.
These are real problems.
But they are not always the problems customers feel first.
the custom post type detour (we took a wrong turn, briefly)
There is a subtle thread in the emdash narrative around structured content.
It suggests that in WordPress, creating structured content often means installing heavy plugins.
That’s… partly true in practice.
But not strictly true in reality.
WordPress has supported custom content types in core for years.
The real gap is not:
“This is impossible.”
The real gap is:
“Most people never get that far.”
Which is the actual problem.
Not structure.
Adoption.
who is this actually for?
This is the question that quietly sits underneath everything.
The emdash announcement strongly signals an audience of:
- developers
- platform builders
- hosting providers
- technical teams
Which is fine.
Except for one small complication:
The role of developers is currently being rearranged by AI at a speed that would make a time-lapse video look slow.
So building a developer-first CMS in 2026 raises an awkward question:
What does “developer-first” even mean anymore?
the right problems, the wrong reasons
Here’s where things get interesting.
emdash is not wrong.
In fact, it is right about several things:
- CMSs do need better structure
- Plugins do need better isolation
- Systems do need to be more programmable
- The web is moving toward API-first, AI-assisted workflows
But…
It is solving these problems from the perspective of:
“How do we make this better to build?”
Instead of:
“How do we make this better to use?”
Same problems.
Different reasons.
Very different outcomes.
what i would build instead
If I were building a CMS today, I would start somewhere else.
Not with schemas.
Not with plugins.
Not with themes.
I would start with:
“What is the job the user is trying to get done?”
And then I would build around that:
- Help me get more bookings
- Help me decide what to post
- Help me understand what’s working
- Help me promote the right thing at the right time
The CMS becomes the hub.
Not the tool.
The hub.
Where:
- content
- marketing
- customer interaction
- decision-making
…all connect.
the slightly uncomfortable conclusion
emdash feels like a very modern answer…
To an older version of the CMS problem.
It’s beautifully aligned with:
- serverless infrastructure
- security models
- developer ergonomics
- AI-native tooling
But most customers are not trying to solve those problems directly.
They are trying to run a business.
And those are not the same thing.
final thought
This is what makes emdash interesting.
It solves the wrong problems for the right reasons:
- security
- structure
- scalability
- clarity
And it solves the right problems for the wrong reasons:
- yes, CMSs need to evolve
- yes, they need to work better with AI
- yes, they need better foundations
But not because developers want cleaner abstractions.
Because customers want better outcomes.
And if you never leave the building…
It’s very easy to miss the difference.
Leave a Reply