Spokes.wiki Search About
Blog Posting T3 volatile source ↗ source url
Published
Created
Updated

EmDash 1.0: the stable CMS with a secure plugin registry (Cloudflare Blog)

Scott Buscemi, Matt Kane and Noah Pham, on the cloudflare blog, 28 September 2026 (Birthday Week). The announcement that EmDash reached 1.0: a free, MIT-licensed CMS that developers build in astro and editors run through an admin UI. It was first announced on 1 April as a WordPress successor, and some people took that for an April Fools' joke. Beta, then about five months of hardening, then 1.0.

Tier T3. The post is the maker describing its own product. What it says the thing is (the plugin runtime, the registry design) is checkable against the open-source code; what it says about how well the thing works (the Cloudflare Blog's traffic, the Avulux "under a day" migration, 175 contributors) is the vendor speaking and is flagged below. Nothing in it is a measurement by a third party.

Why it is in this spoke

It is not a static site generator. EmDash renders on the server, keeps content in a database, stores media, and ships an admin interface, so it falls on the full-stack side of the line ../static-site-wiki draws and this spoke inherits. It is also the corpus's first framework that decides who may touch what at runtime, which is the question application-architecture asks of every unit. Runner-up spoke: static-site-wiki (Astro is the developer surface); recorded as cross-spoke context, nothing written there.

The structural claims

  • A plugin is a boundary, enforced by isolation. WordPress plugins share the site's PHP process with direct access to the database, filesystem and network. EmDash plugins run in an isolated runtime with private storage only. By default a plugin cannot reach site content, media, users, secrets, the environment, the filesystem or the network. Extra access must be declared by the plugin and approved by the admin, one permission at a time ("granting media access does not expose user data").
  • One manifest, two runtimes. On Cloudflare each plugin is a Dynamic Worker loaded through the Worker Loader (cloudflare-workers). On Node.js, EmDash starts workerd as a separate process and runs each plugin as an isolated service inside it. Same manifests and capability-gated APIs on both.
  • A registry that does not own the packages. Built on AT Protocol (the protocol behind Bluesky). The publisher signs package and release records and stores them in their own account; the catalog only indexes them. EmDash checks an inclusion proof against the publisher's signed commit, then the checksum, package name, version, requested access and any build provenance, and confirms the downloaded bundle matches the signed record. Moderation can hide a listing but cannot rewrite a release, take over a plugin or delete the publication. The labeler uses Workers AI; the aggregator, labeler and an Astro live content loader are open source.
  • Three roles, three surfaces. Developers build in Astro, editors use the admin, and agents work through the API, the CLI or a built-in MCP server (model-context-protocol). Host platforms run each customer site as its own Worker (Workers for Platforms). EmDash Build, an open-source AI site builder, is alpha: one Cloudflare Sandbox container per project, every change recorded as a git commit.

Vendor-sourced figures (T3, flagged)

Claim Whose
Cloudflare Blog moved to EmDash in August as "Customer Zero": millions of weekly pageviews, bursts of 5,000 legitimate req/s, survives DDoS Cloudflare, about its own site
Three features came out of that migration: optional KV object caching, a Hyperdrive database adapter, Workers Cache compatibility Cloudflare
Avulux moved a microsite in under a day using the Agent Skills Cloudflare, relaying a customer
175+ contributors, 1,800+ commits, 25 translations, 800+ Discord members Cloudflare

The first row is the useful one, and it is a production case study with no method attached: no latency, no error rate, no comparison with the previous system.

What it does not say

  • Only free plugins work today. Paid plugins are planned, and the team is "watching" the Atproto Spaces Alpha. Whether the permission model holds up against a marketplace with money in it is untested.
  • Nothing is reported about escapes. The sandbox is the headline claim and the post cites no audit, penetration test or incident history. "Secure" is in the title and is argued from design, not evidence.
  • The runtime that gives the strongest guarantee is the one Cloudflare sells. The Node.js path runs the same model through workerd, which is Cloudflare's open-source runtime, so the dependency is real even when the hosting is not.

See synthesis ("Enforcement has a fourth mechanism") for how this fits the spoke's thesis.