Skip to content

~/writingbuilding-this-site-on-emdash

Why this blog runs on EmDash, and why nothing else of mine does yet

This blog is my first real EmDash site. Why I picked Cloudflare's agent-first CMS for it, what I'm testing, and why I'm not moving anything else yet.

Jon Phillips4 min read#agents#astro#cloudflare#wordpress
A short bar of green neon light glowing on a dark concrete wall

This blog runs on EmDash, the free, open-source content management system Cloudflare released as a "spiritual successor" to WordPress. It's built on the Astro web framework, and it was designed from the start to be run by AI agents: every EmDash site has its own built-in MCP server, with permissions you can narrow for each agent. This is my first real EmDash site. Before it, I'd only run a throwaway sample on my own machine. I'm exploring EmDash as a CMS in place of WordPress, and this blog is where I'm doing it.

Why put a personal blog on a months-old CMS?

Because a personal blog is exactly where a new CMS should be tested. If something breaks here, the only person it costs is me.

It also fits the rule I use for when EmDash is even a candidate. It's a new build, not a working site being moved. The front end is Astro, which I already use for content sites. The content is posts and pages, and I'm the only editor. There's no store, membership or course system. And I'm happy with Cloudflare as the host.

It runs on Cloudflare Workers, with D1 for the database and R2 for the media, on EmDash 1.0.1 and Astro 7.

The bigger reason is the way I work. I manage websites through AI agents most days. EmDash is aimed squarely at that. Unlike WordPress, it lets me limit an agent's access to exactly the permissions a job needs.

What did I find when I let an agent in?

Before building this site, I set up a sample EmDash 1.0.1 site on my Mac (an AI agent did the clicking, as it does for most of my work) and connected an agent to it through the site's MCP server. What I saw:

  • Setup has no password at all. The admin account signs in with a passkey (fingerprint, face or device PIN) or an emailed link.
  • Agent tokens start with nothing. There are fifteen permission scopes, none ticked by default, and tokens expire after 30 days unless you choose otherwise. I gave my test token only Content Read and Content Write, for seven days.
  • It refused what the token didn't cover. Asked to change a site setting or delete a field, it answered with an insufficient-scope error.
  • New posts landed as drafts, and an edit to a live post was held as a draft while the public page kept the old text.
  • It had to read before it could write. An edit sent with an out-of-date version marker was rejected as a conflict.
  • But nothing stopped it publishing. The same content-only token published its draft straight to the site. Because it belonged to an admin account, it could also delete a post permanently.

That last one matters most. Scopes limit which kinds of things an agent can touch. They don't add a human checkpoint.

What am I testing on this blog?

The rules I'd want before trusting EmDash with anything that matters:

  • Agents draft, a person publishes. An agent gets its own user account with the Contributor role, which can create drafts but not publish.
  • The MCP server is off unless I'm using it. It's on by default. When it's on: one token per agent, the fewest scopes that work, and tokens revoked when the work is done.
  • Real backups. EmDash's built-in JSON export can't restore a site; its docs say so. Recovery means a database backup plus a separate copy of the media.
  • The content model in version control. EmDash's seed file makes that easy.

Why not move anything else yet?

Because it's young, and young software earns trust slowly.

The first stable release, 1.0.1, shipped in September, after 55 releases in six months with breaking changes along the way. One company runs it, with two named maintainers and no independent foundation. Its official plugin registry has about a dozen plugins; the WordPress.org directory has nearly 70,000. Its changelog shows serious fixes since launch, including one where an editor could reach admin-only actions. That's normal for new software, and it's also why a track record matters.

So I wouldn't move a working WordPress site to EmDash yet. I won't put a client's live site on it until the 1.x releases have had at least a month of fixes behind them. For now it's personal projects, starting with this one.

What happens next?

This blog is the test. I'm keeping a close eye on EmDash's development, and if it holds up here, the next step is more personal projects, not a client's site.

Stack: EmDash 1.0.1, Astro, Cloudflare, passkey sign-in, and EmDash's built-in MCP server with scoped agent tokens.

Jon Phillips builds websites, web apps and automations atMatchless Web in Clinton, Mississippi.

~/writing · keep reading