Cloudflare Releases EmDash 1.0, an Agent-Friendly Open-Source CMS

If you have built websites, you have probably used a content management system (CMS, the back office where editors write posts, upload images and manage page content) such as WordPress. Cloudflare has made a new open-source CMS called EmDash, which it calls the "spiritual successor" to WordPress. It was first announced on April Fools' Day, so plenty of people suspected a joke. Now EmDash 1.0 is out: stable, free, open source under the MIT license, and ready to run a production website.

What follows is organized around what an ordinary reader would ask first: what it is, which problems of traditional CMSs it tackles, what its highlights are, who should use it and when, how to get started, and what to keep in mind.

What is EmDash?

In one sentence: a free, open-source, Agent-friendly back office for websites. It separates the work of three kinds of people:

• Developers build the site with Astro (a front-end framework for building websites);
• Editors write posts and manage media in the EmDash admin, much like using WordPress;
• Agents (AI that can do work on its own) can read and write content directly through the API, the command line, or the built-in MCP server.

1.0 brings more than "stable": a plugin registry (a plugin directory) launches at the same time, along with EmDash Build (alpha), an open-source AI site builder.

Which problems of traditional CMSs does it tackle?

From how Cloudflare tells the story, four pain points can be drawn out.

One: heavy maintenance. Avulux is the most direct example. Tired of the maintenance burden of WordPress, they moved a custom microsite to EmDash. Their director of innovation and systems says a site has to be quick to use and simple for the team to update, and WordPress had become the opposite; now they have a shared platform that developers can extend and marketers can edit directly.

Two: plugins with no boundaries. A WordPress plugin runs in the same PHP process as the whole application, with direct access to the database, filesystem and network. A contact-form plugin can, technically, read unpublished posts, modify other plugins, or send data anywhere. Site owners can only trust that it will not, and that a future update will not change its behavior.

Three: a plugin store controlled by one company. Traditional plugin stores usually combine three roles: the publisher's account, the authoritative record of the package, and the catalog where users find plugins. If an account is suspended, a listing is removed, the rules change or the service shuts down, publishers cannot take the same identity and release history somewhere else.

Four: small changes are costly after an AI builds the site. Sites today are often started from a chat box by describing to an Agent what you want. But once you have something, changing a small thing means going back to the prompt box and rolling the dice, or burning credits for a one-line change.

The answers EmDash gives to these four points are the sections that follow.

Highlight 1: Agent-friendly, not just an API you can call

Traditional CMSs are made for people clicking a mouse. EmDash opens three doors to Agents at once: the API, the command line, and the built-in MCP server, and it also ships EmDash Agent Skills (a skills pack for Agents) to help Agents get started. Cloudflare's phrase is that EmDash is "an agent's best friend". Avulux, mentioned above, finished its migration in under a day with the help of Agent Skills.

For website-building and hosting companies, this road goes one step further. Such companies can use Workers for Platforms (Cloudflare's service that lets a platform run each customer's website as its own Worker), so they do not have to provision a server for every site and can focus on how customers create and manage a website. EmDash provides the content layer: a platform can use the admin interface directly, build its own interface on the API and command line, or put an Agent in front of the built-in MCP server. Cloudflare's example: a bakery owner asks the platform's Agent, in plain language, to change the opening hours, and the Agent reads, updates and saves the content. Cloudflare is also looking for more hosting partners who want to build new Agent-oriented CMS experiences.

Highlight 2: Plugins in a sandbox, permissions visible before installing

Plugins are the core of a CMS ecosystem: site developers do not have to rebuild the same integrations and workflows, and experts can share what they know, even build a software business. Cloudflare argues that Agents make this reuse more valuable: an Agent can build a one-off integration for you, but it has to understand the problem, write and test the code, and maintain it afterward; a plugin captures that work, and another Agent can install and configure a proven solution instead of starting again.

EmDash's sandboxed plugins use a different model: each plugin runs in an isolated runtime with access to its own private storage, but not to the site's content, media, users, secrets, environment, filesystem or network. It gains additional abilities only when the plugin declares them and the site administrator approves them.

Look at the example on the right: a plugin approved only to read media (media:read) that asks to write posts (posts:write) is met by the gatekeeper, which finds it lacks that capability and returns nothing; another plugin approved to read posts (posts:read) is let through when it asks to read posts. Resources are isolated, and the impact of a vulnerability is limited to what that Worker can access.

So installing a sandboxed plugin feels more like installing a mobile app than a traditional CMS plugin: before it runs, EmDash shows you what it wants to do, and at runtime it limits the plugin to the approved abilities. The image below is the page of the Cloudflare Email Sending plugin in the registry. Its "Before you install" section lists three requested permissions: making network requests to a declared external host (api.cloudflare.com), observing and modifying outgoing email, and providing the email transport, replacing the current way of sending.

This lets plugins do useful work without getting unrelated access:

The key is that these abilities are independent: access to media does not also expose users or unpublished content, and permission to contact one service does not open up the rest of the network. The runtime enforces these boundaries; they are not left to the plugin author's good intentions.

The isolation is not limited to Cloudflare. On Cloudflare, EmDash runs each plugin as a Dynamic Worker through the Worker Loader; on Node.js, EmDash starts workerd (Cloudflare's open-source Workers runtime) as a separate process and runs each plugin as an isolated service inside it. Both platforms use the same manifests and capability-gated APIs.

Highlight 3: A plugin catalog that no company owns

Permissions limit what a plugin can do at runtime, but one question remains: where do plugins come from, and can they be trusted? The plugin catalog site plugins.emdashcms.com launches with 1.0: developers can publish sandboxed plugins, and site owners can search, inspect and install them.

EmDash separates the plugin from the catalog. Publishers keep control of their packages and release history, while EmDash provides a convenient place to find and install them. Other services can index the same publications, build their own catalogs and apply their own policies, without developers having to start again. The EmDash catalog applies default moderation to the names, descriptions, links and images it displays; moderation can only hide harmful material from this catalog, and it does not rewrite a release, take ownership of a plugin, or erase the underlying publication.

This is built on the AT Protocol (atproto for short), the decentralized network protocol that powers Bluesky. Plugin authors publish with an Atmosphere account, the portable identity used across this ecosystem. The package and release records are signed by the publisher and stored in the publisher's own account.

"Decentralized" does not mean accepting unverified code. Atproto repositories use signed Merkle Search Trees, so an inclusion proof connects the exact release record to a signed commit from the publisher's account. EmDash can therefore verify the record independently instead of trusting the catalog's copy. It then checks the plugin's checksum, package name, version, requested access and, where required, build provenance, and confirms that the downloaded bundle matches the signed record.

EmDash hosts the default registry services so publishers and site owners do not have to run infrastructure themselves. Cloudflare has also open-sourced all of these services: the aggregator that powers the registry, the labeler service that uses Workers AI to moderate package descriptions, and a loader for embedding plugin listings in any Astro site. Only free plugins are supported today; Cloudflare aims to support paid plugins in future under the same decentralized model, and is watching the Atproto Spaces Alpha, with the goal that anybody should be able to run a secure, paid plugin marketplace and publishers can make money from their software. Cloudflare's position: there is no central controller that can take over plugins or remove them on a whim, and the security of plugins and the registry should be baked into code rather than depend on trusting any authority or code of conduct.

Highlight 4: EmDash Build, where an Agent builds a whole site from a single prompt

EmDash Build (alpha), released and open-sourced at the same time, is an AI site builder that hosting providers, website builders and platforms can run themselves and integrate with their own systems. Try the demo at build.emdashcms.com; the code is open source at github.com/emdash-cms/emdash-build.

It answers the fourth pain point above: what EmDash Build produces is a complete EmDash site with the full stack: server-rendered Astro pages, a database, media storage and an admin interface. The Agent designs a content model from the brief, fills it in through EmDash's MCP server, and writes the pages that display it. After that, you or your customer can edit text right on the page, schedule posts, or let an Agent do it for you, without returning to the prompt box each time.

In EmDash Build each project gets its own Cloudflare Sandbox container, where an Agent built on the Agents SDK verifies its own work; Artifacts tracks every change as a git commit. When the site is published, the content moves into a production EmDash site and is deployed to the host's Workers for Platforms namespace.

What makes 1.0 trustworthy?

After the first beta of EmDash, developers launched real websites with it. But Cloudflare kept hearing the same reasonable response: "This looks interesting. Let me know when it is 1.0." People wanted confidence that it was stable and secure, that upgrades would protect their content, and that Cloudflare is fully committed to maintaining it.

Over the past five months, Cloudflare has worked with contributors and production users on the parts every site depends on: data safety, database migrations, editorial workflows, localization, plugin security, performance, and the reliability of the admin, API, MCP and media experiences. The most representative case is Cloudflare itself: this summer it migrated the Cloudflare Blog to EmDash as part of its "Customer Zero" approach, meaning it went first as its own customer. The blog has to handle millions of pageviews per week, spikes up to 5,000 requests per second of legitimate traffic, and sporadic DDoS attacks. The migration produced three optional features that are now available to all customers: KV object caching, the Hyperdrive database adapter (Hyperdrive is Cloudflare's service for speeding up database connections), and Workers Cache compatibility.

A CMS holds an organization's most important content and is often used by dozens of editors every day, so Cloudflare stresses that it must not lock anyone in: EmDash is completely free and open source under the permissive MIT license. At the time of writing, more than 175 people have contributed to the project, across more than 1,800 commits, and the interface has been translated into 25 languages. Cloudflare also says it deliberately built the project so that agents help the human developers rather than overwhelm them. Noah Pham joined Cloudflare as an intern and became EmDash's second maintainer, contributing more than 80 changes and taking ownership of major parts of the media library, content editor and admin interface.

The ecosystem is growing too: Lexington Themes offers 44 Astro themes with EmDash variants; Urumi is using its WooCommerce expertise to release EmDash's first eCommerce plugin; Empress is launching a platform for multi-brand entities, managing a fleet of sites with natural language or a conventional admin panel.

Who is it for, and in which scenarios?

Going by what Cloudflare says, you can find your place:

• Teams building a production website: a company's marketing or content site. Cloudflare suggests now is a great time to migrate your company's marketing site, and its own blog is the precedent. The prerequisite is someone who can develop with Astro; editors then work in the admin day to day.
• Agencies: one of the uses Cloudflare names is "your agency's vibe-coding platform" (a service where AI builds a site from conversation), which can offer its service on top of EmDash.
• Hosting companies and site-building platforms: give each customer an independent site with Workers for Platforms, offer extensions to many customer sites through sandboxed plugins, and run your own plugin marketplace, opening up the whole registry or curating a set of pre-approved plugins.
• A one-person side project: Cloudflare mentions having an Agent spin up the side project you have been talking about; Avulux's microsite migration also took under a day.
• Plugin developers: people who want to build extensions and make money from them can publish without asking EmDash's permission; site owners can see what a plugin is allowed to do before they run it.
• Organizations managing many sites: a platform like Empress, aimed at multi-brand entities, manages a fleet of sites with natural language or a conventional admin panel.

How to get started

1. Try it first: open the playground at try.emdashcms.com, or try the EmDash Build demo at build.emdashcms.com.
2. Create a site locally: run this in a terminal:

npm create emdash@latest

3. Deploy: you can also deploy the official blog template in one click from the Cloudflare dashboard.
4. Migrate an existing site: Cloudflare mentions using EmDash Agent Skills to have an Agent help with the migration; the admin menu also has an Import entry.
5. Build a plugin: the official documentation has a step-by-step guide to creating a plugin and publishing it to the plugin registry.
6. Read the source, or host it yourself: the main EmDash project is at github.com/emdash-cms/emdash; the code for the AI site builder EmDash Build is at github.com/emdash-cms/emdash-build, which hosting providers and platforms can run themselves and integrate with their own systems; the registry's aggregator, labeler service and Astro loader are open source too, and live in the main project.
7. Join the community: Discord already has more than 800 people; contributing does not have to mean writing code, since translations, documentation, testing, design, issue triage and answering questions all count.

How to read this

EmDash is more than "another WordPress replacement". Taken together, the sections above make a CMS answer three questions: can an Agent read and write content (API, command line, MCP), will the extensions an Agent or a person installs overstep (no permissions by default, declare then approve, enforced by the runtime), and can the origin of those extensions be verified independently (signed release records, with the catalog only an entry point). If you are building a product that lets Agents install extensions, these three points are worth comparing against your own.

But be clear about where things stand: the registry supports only free plugins for now, and a paid marketplace is still planned; EmDash Build is an alpha; the site itself has to be built with Astro, so getting started on your own takes development skills, while editors who do not write code mostly use the admin day to day once it is set up.