EmDash feels less like a WordPress replacement and more like a CMS experiment for the Cloudflare era

tl;dr

• EmDash is a CMS built with Astro, TypeScript, Cloudflare Workers, D1, and R2.
• I do not see it as something that replaces WordPress right away. I see it more as a design sample for where CMSs may be heading.
• At our company, we run Find goods on EmDash and Glow Edit on WordPress.
• The interesting parts are server operations, plugin permissions, and authentication.
• That said, EmDash is still a v0.1.0 preview. It is too early to recommend it broadly for normal store sites or business websites.
• If a client strongly wanted to use it, I could probably deliver it. But I would not proactively recommend it yet.

EmDash is a CMS from Cloudflare. Cloudflare’s official blog presents it as something like a spiritual successor to WordPress, and it is available as open source under the MIT license.

In rough terms, it is an attempt to rebuild a WordPress-like CMS for the Astro, TypeScript, Cloudflare Workers, D1, and R2 era.

We are actually running both EmDash and WordPress at our company. The EmDash site is Find goods, and the WordPress site is Glow Edit. So this is not just me reading a release announcement and saying “looks nice.” It is still early, but these are notes from touching both in practice.

Let me say this first: I do not see EmDash as the thing that kills WordPress tomorrow. It feels more useful to look at it as a technical preview of what a CMS could look like in the AI and Cloudflare era.

What makes it interesting

Compared with WordPress, I think EmDash is interesting in three main areas.

1. It changes the server operations model.
2. It tries to narrow plugin permissions.
3. It does not assume password-based login.

I’ll go through them in order.

Moving away from always-on servers

WordPress, roughly speaking, means preparing a server that runs PHP and MySQL, then deploying the application there. Managed hosting can make this much easier. Even so, you still have to think about servers, PHP, the database, plugins, themes, backups, WAF settings, and updates.

EmDash changes that premise a bit. It can run on Cloudflare Workers, use D1 as the database, and store media in R2. Instead of keeping a server running all the time, it is closer to running code on Workers when requests come in.

That is attractive for people who operate many small sites.

For example, our Find goods site runs on EmDash as a small media site for gift ideas and “treat yourself” products. It already has the pieces I would expect from a CMS: article lists, categories, search, and media rendering.

This kind of site does not constantly perform heavy work. It publishes articles, people read them, and the site gets updated from time to time. That makes the Cloudflare Workers model feel like a good fit.

The use cases I imagine are in the same direction:

• managing many websites for small and medium-sized businesses
• operating multiple sites for different agencies
• running many small blogs or landing pages
• maintaining sites that do not change often, but still need an admin UI

For these cases, a CMS that does not require keeping a server alive all the time is a strong idea. You do need to understand Cloudflare, so I would not call it easy for everyone. But for someone already comfortable with Cloudflare, the setup can become pleasantly lean.

A plugin model that does not hand over everything

Plugins are WordPress’s strength. They are also one of its weaknesses.

WordPress plugins are convenient, but they tend to have broad power over the whole site. One vulnerable plugin can become a risk for the entire site, and sometimes for the server side as well. The longer a WordPress site is operated, the more this kind of risk starts to matter.

EmDash seems to face this problem directly. Plugins run in an isolated environment, similar in spirit to Cloudflare Workers, and plugins declare the permissions they need. For example, permissions can be separated by capabilities such as reading content, sending email, or touching storage.

I like this direction.

Plugin systems in web apps usually bring convenience and danger as a pair. So designing around “plugins are useful, but they should not be able to do everything” feels right to me.

Of course, a good design does not automatically create a safe ecosystem. Still, it feels like EmDash is trying a different design after understanding the painful parts of WordPress.

Passkey-first authentication also makes sense

The authentication story is also interesting. EmDash is passkey-first, meaning it starts from passkeys rather than password login.

Passwords depend a lot on user behavior. Password reuse, weak passwords, not using a password manager, and continuing to use leaked passwords are all common. No matter how hard the operator tries, it is difficult to completely control that side.

Starting with passkeys is a fairly strong stance. But for a CMS admin screen, I think that stance makes sense.

If you combine it with Cloudflare Access, you can also bring it closer to an organization’s existing authentication layer. That is very different from putting a WordPress login screen directly on the internet and trying to defend it there.

But I would not rush it into production everywhere

I have praised it so far, but it is not all upside.

EmDash is still a v0.1.0 preview. It is not mature enough to treat as a full WordPress replacement yet.

WordPress has a long history. The familiar admin UI, plugin ecosystem, themes, hosting options, number of people who can work on it, and searchability when something breaks are all real strengths. Those things do not disappear just because a newer architecture is cleaner.

For example, our Glow Edit site runs on WordPress. It is a beauty media site, and WordPress’s normal strengths still matter there: categories, article lists, search, post management, existing themes, and plugin choices. For a media site where the job is to keep publishing articles steadily, WordPress still has a lot of practical strength.

On the other hand, while running Find goods on EmDash, I can also feel the gap between a clean design and day-to-day operation. Admin usability, permission design, backups, migration, explaining the system to clients, and recovery procedures during incidents all matter. A CMS is not finished just because it can save articles.

So I would not tell a typical store owner or blogger, “Use this instead of WordPress” yet. For now, I think it is better suited for developers and people already comfortable with Cloudflare who want to try a possible future CMS.

How I would use it

If a client told me, “I really want to build this with EmDash,” I could probably deliver it. I understand the Astro and Cloudflare stack, and I think there are cases where it can work if the requirements are narrow enough.

But would I proactively recommend it today? Not yet. The reason is simple: with a CMS, operations last much longer than the initial build.

I would consider it for a small experimental site, an internal site, a technically literate client, or a project that already assumes Cloudflare. Those are good places to try it.

On the other hand, for a business website updated daily by non-engineers, a long-term maintenance project, or a site where the client expects plugins to solve everything, WordPress is still the more realistic choice. For steadily growing a media site like Glow Edit, WordPress still gives a lot of practical confidence.

Closing

What I find interesting about EmDash is that it keeps the CMS, theme, and plugin ideas from WordPress, while rebuilding them for an era of serverless infrastructure, permission separation, passkeys, and AI agent compatibility.

The question is not really “Will it defeat WordPress?” The more interesting question is, “If we were designing a CMS again today, what would we change from the beginning?”

That is the lens I want to keep using as I follow EmDash.