EmDash 1.0 Is Stable. Its Sandboxed Plugins Cannot Touch the Database, and That Is the Whole Pitch.

On the second day of its Birthday Week, September 28, Cloudflare declared EmDash 1.0 stable: “a stable, free, and open source CMS built on Astro, ready to power a production website, your agency’s vibe-coding platform, or your hosting company’s site-building experience.” The v0.1.0 preview we covered on April 1 now carries an MIT licence, more than 175 contributors and 1,800 commits, a plugin registry built on the AT Protocol, and a customer list that starts with Cloudflare’s own blog.

The pitch has not changed since April, and it is aimed squarely at the business every WordPress host is in. Cloudflare’s post describes the competitor in one sentence: “With WordPress, plugins run inside the same PHP process as the rest of the application, with direct access to its database, filesystem, and network.” The consequence follows: “A contact-form plugin can technically read unpublished posts, modify another plugin, or send data anywhere.” Site owners, the post adds, must trust that it will not. This month alone WordPress has shipped a comment-form XSS fix that we covered, and a page-template flaw, CVE-2026-87902, that Patchstack saw probed the day 7.1.2 was released. Whether a hosting company can sell EmDash’s answer depends on what it takes to run the thing, and that is a Node.js process or a paid Cloudflare account, not a cPanel package.

Key facts

• The release: EmDash 1.0 on September 28, 2026, MIT licence, built on Astro. It is an open-source project under the emdash-cms organisation on GitHub, started and staffed by Cloudflare employees and announced on Cloudflare’s blog, with a maintainer team that has, in the project’s words, “Cloudflare employees in the minority.” The Cloudflare Blog runs on it and, per Cloudflare, handles millions of pageviews a week and spikes of 5,000 legitimate requests per second.
• The sandbox: on Cloudflare each plugin runs as a Dynamic Worker through the Worker Loader; on Node.js EmDash starts workerd, the open-source Workers runtime, as a separate process and runs each plugin inside it. Plugins declare capabilities such as content:read in a manifest; the runtime enforces them.
• The registry: plugins.emdashcms.com is built on the AT Protocol. Publishers sign package records held in their own Atmosphere accounts, keep ownership and release history, and anyone can run a compatible registry. Free plugins only for now; paid plugins are planned.
• The hosting bill: Cloudflare route needs Workers, D1 and R2, plus the Worker Loader if the site uses marketplace, registry or sandboxed plugins; the Loader is available only on the Workers Paid plan, $5 a month. Node route needs Node.js 22.16 or later, SQLite, PostgreSQL or libSQL, local or S3-compatible media storage, a workerd child process and one always-running process for scheduled tasks.
• The migration: an admin import wizard takes a WXR export or a site URL with EmDash Exporter plugin credentials; the exporter route also brings comments, menus and site settings. Agent skills help port plugins, and Cloudflare says they took Avulux’s site over in under a day.

A Contact Form That Cannot Read Your Drafts

EmDash’s security model is the app-store model applied to a CMS. Matt Kane, who started the project and is one of its maintainers, puts it in one line in the 1.0 post: “An evil plugin can’t read anything from any other plugin, and you decide when you install it.” Cloudflare’s post is more specific about the mechanism. A plugin gets private storage of its own and nothing else by default; access to site content, media, users, secrets, the environment, the filesystem or the network has to be declared and approved. The tutorial shows the declaration: a plugin that wants saved content lists "capabilities": ["content:read"] in its manifest, because, the tutorial says, hooks such as content:afterSave expose saved content and require that capability.

The isolation is process or isolate isolation, not a PHP convention. On Cloudflare, the Worker Loader spins each plugin up as a Dynamic Worker, the primitive Cloudflare sells for sandboxing AI agents. Off Cloudflare, EmDash launches workerd as a child process and runs each plugin as an isolated service inside it. The architecture page carries the caveat that matters for anyone auditing a site: “Native plugins run with the host application’s access. Standard-format plugins can run in an isolated runtime when the site configures a sandbox runner and grants capabilities.” A site that ships native plugins, or never configured a runner, has not bought the guarantee; the Node.js documentation says marketplace and sandboxed plugins need a configured sandbox runner to run at all.

The number EmDash’s post leans on is Patchstack’s: the PHP model “means that plugins are the source of 96% of security issues for WordPress sites,” a figure Cloudflare’s April post attributed to Patchstack’s 2025 whitepaper. Kane’s framing is fair to both sides: “The plugin ecosystem around WordPress is probably its greatest strength, but it’s also its greatest weakness.”

A Registry Where Nobody Can Delete Your Plugin

The piece that is new at 1.0 is the registry, and its design is a direct comment on WordPress.org. Cloudflare’s post says publishers use Atmosphere accounts, the portable identities of the AT Protocol that also runs Bluesky, and that package records are signed by the publisher and stored in the publisher’s own account. In Cloudflare’s words, “Publishers retain control of their packages and release history, while EmDash provides a convenient place for people to find and install them.” Verification covers checksums, package name, version, requested access and build provenance. Moderation can hide harmful material from the catalogue but, in Cloudflare’s words, does not rewrite releases or erase publications. Kane adds that plugins.emdashcms.com is only the default store and that “anybody else can create one that is compatible.”

The design choice is legible: the registry operator cannot take a plugin away from its author. What the registry cannot yet do is match the scale it is measured against. The catalogue on September 29 shows about a dozen packages, among them a webhook notifier and an AT Protocol syndication plugin published by EmDash itself, a localisation plugin and an events plugin from independent developers. All are MIT-licensed and free; paid plugins are on the roadmap, not in the store.

Five Dollars on Cloudflare, or a Node Process on Your VPS

Cloudflare’s post offers EmDash as “your hosting company’s site-building experience.” The documentation says what that costs. On Cloudflare, a site needs Workers, a D1 database and an R2 bucket, with KV, Access, Email Sending and AI Search as options. The Worker Loader binding is needed only for sandboxed plugins: “If the site does not use marketplace, registry, or sandboxed plugins, omit sandboxRunner and the LOADER binding.” The Loader is the Dynamic Workers feature, which Cloudflare’s pricing page says is “currently only available on the Workers Paid plan.” That plan is $5 a month, with 1,000 unique Dynamic Workers, 10 million requests and 30 million CPU milliseconds included, then $0.002 per Dynamic Worker per day, $0.30 per million requests and $0.02 per million CPU milliseconds.

Off Cloudflare, EmDash is a Node.js application: Node.js 22.16 or later, SQLite by default, PostgreSQL where several instances share state, or libSQL for remote setups, and media on local disk or any S3-compatible store. Plugin sandboxing on Node.js runs through the @emdash-cms/sandbox-workerd package, which starts workerd as a child process. Two operational conditions follow: at least one Node.js process must run continuously for publishing and scheduled tasks, and SQLite needs persistent storage, since an ephemeral filesystem loses the site on restart. A Dockerfile is provided.

That is a VPS or container workload, not a shared-hosting one. A host whose product is PHP-FPM behind a control panel has nothing to point EmDash at; a host with a Node.js runtime, the kind Cloudways, cPanel and Cloudflare all launched or extended this month, has a place to run it. On Cloudflare the $5 goes to Cloudflare, not to the host; on a VPS, workerd is one more long-running daemon on hardware sized for short PHP requests.

Twelve Plugins Against Sixty Thousand

The 1.0 post asks “what would WordPress look like if it were built today,” and the honest answer at 1.0 is that it would look like a CMS with a strong core and an ecosystem the size of a hackathon. When we covered the April preview, WordPress had 60,000-plus plugins to EmDash’s none; the registry now has about twelve. Cloudflare’s post names the early commercial ecosystem: Lexington Themes with 44 Astro themes carrying EmDash variants, Urumi preparing an eCommerce plugin from its WooCommerce experience, and Empress, a multi-brand site management platform. The named customer beyond Cloudflare is Avulux, whose director of innovation and systems Greg Barbosa says of the microsite it moved off WordPress: “The site had to be fast to use and simple for our team to update. WordPress had become the opposite of that.”

Migration is the part EmDash has built out most. The admin panel’s import wizard takes a WordPress WXR export, or a site URL plus credentials for the EmDash Exporter plugin, which adds comments, menus, site settings and SEO fields from the live site; a public URL on its own only probes the site, and the documentation states there is no WordPress.com OAuth source. For code, the project ships agent skills to “port one from WordPress,” as Kane puts it of plugins. Everything a human can do in the admin, an agent can do through the API, CLI or the built-in MCP server with OAuth scopes.

What EmDash does not yet offer a host is the thing WordPress hosts actually sell: a customer base that arrives asking for it by name, an editor its customers already know, and a plugin for every commercial need. What it offers is a demonstration that a plugin with the run of the database is a design choice, not a law of nature. Kane’s own test is the one to hold it to: “you shouldn’t ever trust your site to a proprietary CMS.” EmDash is not proprietary. It is also, for now, small.

Contributor, commit, language and community figures, the Cloudflare Blog traffic claims and the customer quotations are Cloudflare’s and EmDash’s own and are not independently verified. The registry count is our reading of plugins.emdashcms.com on September 29. Cloudflare’s post dates the blog’s move to EmDash to August; EmDash’s post says the blog served Agents Week traffic in July, and this article does not resolve the difference. Neither Cloudflare nor EmDash was contacted for this article.