EmDash began as an April 1 announcement — a “spiritual successor to WordPress” that drew plenty of conference-floor chatter and, with it, suspicion that the whole thing was a joke. It was not. EmDash 1.0 is now stable, free and open source, built on Astro. Developers build with Astro, editors work through the EmDash admin, and agents can drive the system through the API, the CLI or the built-in MCP server. Editorial, media, localization, migration and deployment workflows ship as production-tested.
What five months of production use produced
During the beta, developers were shipping real sites on EmDash while telling us plainly that they wanted confirmation of stability, upgrade safety and long-term maintenance before committing. Most of the work since then has gone into exactly those areas: data safety, database migrations, editorial workflows, localization, plugin security, performance, and the reliability of the admin, API, MCP and media experiences.
Production deployments surfaced much of this. Avulux moved a custom microsite off WordPress after tiring of its maintenance burden; using the EmDash Agent Skills, the conversion took under a day. “The site had to be fast to use and simple for our team to update,” said Greg Barbosa, Avulux's Director of Innovation and Systems. “WordPress had become the opposite of that. With EmDash, we now have a shared platform that developers can extend and marketers can edit content.”
Cloudflare's own migration of the Cloudflare Blog in August, part of a “Customer Zero” approach, exercised localization, media management, the admin editor and scaling. Handling the blog's load meant coping with millions of pageviews per week, spikes to 5,000 requests per second of legitimate traffic, and occasional DDoS attacks. Three features came out of that project and are now generally available: optional KV object caching, the Hyperdrive database adapter, and Workers Cache compatibility.
Community, license and momentum
Because a CMS holds an organization's most important data and is typically used by dozens of editors daily, EmDash is released under the MIT license with no vendor lock-in and no dependence on shifting business priorities.
More than 175 contributors have produced over 1,800 commits. Because agentic coding tools cut both ways for open-source projects, the project was deliberately structured so agents assist human developers rather than overwhelm them. Core contributors include @swissky, @danielmlr, @MA2153, @marcusbellamyshaw-cell and many others; translators have brought the CMS to 25 languages, from Arabic to Ukrainian. Noah Pham, who joined as an intern and became EmDash's second maintainer alongside Matt, contributed more than 80 changes and owns significant parts of the media library, content editor and admin interface.
Non-code contributions — translations, documentation, testing, design, triage and user support — are equally welcome; the Discord community has passed 800 members.
Ecosystem activity
Themes, plugins and platforms are already appearing around EmDash:
- Lexington Themes offers 44 Astro themes with EmDash variants, including reusable components and built-in content collections.
- Urumi is shipping EmDash's first eCommerce plugin, drawing on its WooCommerce background.
- Empress is launching a platform for multi-brand entities, managing fleets of sites through either natural language or a conventional admin panel.
“Empress's delightful multisite experience would not be possible without the foundations EmDash has laid: sites that are fast, safe to extend, and easy for people and agents to read and act on,” said Empress founder Raj Makker. “EmDash unlocks powerful control over a website, and Empress builds on it to give you complete control over as many sites as you want.”
Publishing plugins without a gatekeeper
Plugin authors publish sandboxed plugins to the EmDash plugin registry, where site owners can search, inspect and install them. Conventional registries bundle three roles into one company: the publisher's account, the authoritative package record, and the discovery catalog. That is convenient, but it makes a single vendor the gatekeeper over both identity and distribution; a suspended account, a delisted plugin, changed rules or a shutdown leaves publishers unable to carry the same identity and release history elsewhere.
EmDash separates the plugin from the catalog. Publishers keep their packages and release history, EmDash supplies the discovery surface, and other services are free to index the same publications, build competing catalogs and apply different policies without forcing developers to begin again. The catalog applies default content moderation over the names, descriptions, links and images it shows; moderation may hide harmful or inappropriate material, but it cannot rewrite a release, seize ownership or erase the publication underneath.
Signed records instead of catalog trust
The registry runs on AT Protocol (atproto), the decentralized network that also underpins Bluesky. Authors publish through an Atmosphere account, the portable identity used across those applications, and the package and release records are signed by the publisher and kept in the publisher's own account. Cloudflare hosts the default registry services so nobody has to run infrastructure, and all of them are open source: the aggregator behind the registry, the labeler service that uses Workers AI to moderate package descriptions, and an Astro live content loader for embedding plugin listings in any Astro site.
No central controller can seize or arbitrarily remove plugins; the thinking is that security belongs in code rather than in a central authority or a code of conduct. Decentralization is not an excuse for unverified code, either. Atproto repositories use signed Merkle Search Trees, so an inclusion proof links a release record to a signed commit from the publisher's account — EmDash verifies the record independently rather than trusting the catalog's copy. It then checks the checksum, package name, version, requested access and any required build provenance, and confirms the downloaded bundle matches the signed record.
The registry supports free plugins today. Paid plugins are planned on the same decentralized model, and we are watching the Atproto Spaces Alpha with interest: a secure paid marketplace should be runnable by anyone, publishing should be able to earn money, and site owners should be able to see exactly what a plugin may do before running it — without asking EmDash for permission.
What sandboxing actually buys you
Plugins exist because reinventing the same integration is wasted work. For agents the payoff is larger still: rather than deriving a one-off integration, testing it, and owning its maintenance, an agent can install a plugin that already encapsulates that effort.
The counterweight is obvious — plugin code runs next to valuable content and customer data. In WordPress, plugins share the application's PHP process, and with it direct access to the database, filesystem, and network. A contact-form plugin can read unpublished posts, alter another plugin, or ship data anywhere. Site owners are left trusting that it won't, and that no future update will change that behavior.
EmDash's sandboxed model breaks that assumption. A plugin runs in an isolated runtime with its own private storage and no default access to content, media, users, secrets, environment, filesystem, or network. Every additional ability must be declared by the plugin and approved by the site administrator.
Installation therefore resembles adding a mobile app rather than a traditional CMS plugin: the requested abilities are visible before anything executes, and the runtime holds the plugin to exactly that set.
Useful work remains possible without over-granting:
A plugin could… | It might need to… | It still cannot… |
Index published articles for search | Read content and contact the search service | Edit articles or contact other hosts |
Optimize uploaded images | Read and manage media | Read user content |
Send publishing notifications | Observe publishing and send email | Change the content being published |
Provide configurable webhooks | Read selected events and contact public destinations | Reach private networks or other plugins’ storage |
Crucially, the abilities are separate. Media access does not carry user or unpublished-content access with it; reaching one external service does not open the network. The runtime enforces the boundary — plugin authors don't get to self-certify.
Isolation also isn't Cloudflare-only. There, each plugin is executed as a Dynamic Worker through the Worker Loader. On Node.js, EmDash launches workerd, the open-source Workers runtime, in a separate process and runs every plugin as an isolated service within it. Manifests and capability-gated APIs are identical across both. Setup steps and runtime differences are covered in the plugin sandbox documentation.
Content infrastructure for hosting businesses
Beyond a single Astro site, EmDash targets companies whose product is website creation and hosting. Workers for Platforms lets them run every customer site as a Worker on Cloudflare's network, avoiding per-site server provisioning and the surrounding deployment and networking plumbing. What's left for them is the experience their customers actually use.
EmDash supplies the content layer underneath it. A platform can adopt the admin interface as-is, build its own on the API and CLI, or front the built-in MCP server with an agent — for example, a bakery owner stating a change to opening hours in plain language, with the platform's agent handling the read, update, and save.
Sandboxing matters at platform scale too. Extensions distributed across many customer sites can be held to approved access to content, media, users, email, or external services instead of unrestricted application access, and a platform can run a marketplace drawing on the full registry or a curated pre-approved set.
Cloudflare is looking for additional hosting partners to collaborate on agent-oriented CMS experiences.
EmDash Build, open-sourced as an alpha
Alongside 1.0, Cloudflare is releasing an alpha of EmDash Build, an AI site builder that hosting providers, website builders, and platforms can self-host and integrate. A demo and the source are available.
The premise is that new sites rarely start in an IDE anymore; they start with a chat box and a description. The friction arrives after that, when small edits force a return to the prompt and a gamble on the output or another credit spent on a one-line change.
EmDash Build instead creates an EmDash site, with the full stack attached: server-rendered Astro pages, a database, media storage, and an admin interface. The agent derives a content model from the brief, populates it through EmDash's MCP server, and writes the display pages. From there, editing happens on the page itself — by a person or by an agent — along with scheduling posts.
Every project in EmDash Build occupies its own Cloudflare Sandbox container, where the agent, built on the Agents SDK, checks its own work. Artifacts records each change as a git commit. Publishing moves content into a production EmDash site and deploys to the host's Workers for Platforms namespace.
Try it, extend it, join in
Or generate a site locally through the CLI:
npm create emdash@latestThe same can be done from the Cloudflare dashboard:
For plugin authors, the documentation includes a step-by-step guide to creating and publishing to the registry, and contributors are welcome on Discord — engineers and non-engineers alike, including translators, issue triage managers, UX designers, and marketers.
