Skip to content

CLOUDFLARE 2026-09-28

Read original ↗

EmDash 1.0: the stable CMS with a secure plugin registry

Summary

Cloudflare released EmDash 1.0, the stable, MIT-licensed, open-source Astro-based CMS it first previewed on 2026-04-01 as the "spiritual successor to WordPress." The 1.0 milestone hardens the parts every production site depends on (data safety, database migrations, editorial/localization workflows, plugin security, admin/API/MCP/ media reliability), validated in part by Cloudflare running its own blog on EmDash as "Customer Zero" (millions of pageviews/week, spikes to ~5,000 RPS). The headline architecture is a decentralized plugin registry built on the AT Protocol (atproto, the protocol behind Bluesky): it separates the plugin (a signed record the publisher owns) from the catalog (a convenient discovery surface anyone can rebuild), so no single company gatekeeps both publisher identity and distribution. Plugins install with app-store-style capability approval because each EmDash plugin runs in a capability-based sandbox — a Dynamic Worker via the Worker Loader on Cloudflare, or an isolated workerd service on Node.js — with no ambient access to the site's content, media, users, secrets, filesystem, or network unless the manifest declares it and the administrator grants it. The post also open-sources EmDash Build, an AI site builder that scaffolds a full EmDash stack from a prompt inside a Cloudflare Sandbox container.

Key takeaways

  1. Registry design: separate the plugin from the catalog. Traditional registries fuse three roles — publisher account, authoritative package record, and discovery catalog — making one company the gatekeeper for both identity and distribution; if an account is suspended or the service shuts down, publishers cannot take the same identity and release history elsewhere. EmDash splits them: publishers retain their packages and release history; EmDash is "a convenient place for people to find and install them"; other services can index the same publications and apply their own policies. (Source: this article)
  2. Built on AT Protocol / atproto. Plugin authors publish with an Atmosphere account — the portable identity also used across Bluesky and other atproto apps. "The package and release records are signed by the publisher and stored in the publisher's own account." This is the decentralized-identity move: the publisher owns the identity, not the marketplace. (See systems/at-protocol.)
  3. Verification without trusting the catalog. "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 verifies the record independently rather than trusting the catalog's copy, then checks the plugin's checksum, package name, version, requested access, and any required build provenance, and confirms the downloaded bundle matches the signed record. "Decentralized publishing does not mean accepting unverified code."
  4. Content moderation without ownership. The EmDash catalog applies default moderation to the names, descriptions, links, and images it displays — it "can hide harmful or inappropriate material from this catalog, but it does not rewrite a release, take ownership of the plugin, or erase the underlying publication." The moderation service is the open-source labeler, which uses Workers AI to moderate package descriptions.
  5. Sandboxed plugins with declared capabilities (the security thesis). With WordPress, plugins run in the same PHP process with direct access to the database, filesystem, and network. EmDash inverts this: "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 they are declared by the plugin and approved by the site administrator." Installing feels "more like installing a mobile app than a traditional CMS plugin." (See concepts/capability-based-sandbox.)
  6. Capabilities are independent (non-composition of grants). "Giving a plugin access to media does not also expose users or unpublished content. Allowing it to contact one service does not open the rest of the network. These boundaries are enforced by the runtime, not left to the plugin author's good intentions." Worked examples: a search-indexer can read content and contact the search service but cannot edit articles or contact other hosts; an image-optimizer can read and manage media but cannot read user content.
  7. Cross-platform isolation: Worker Loader on Cloudflare, workerd on Node.js. "On Cloudflare, EmDash runs each plugin 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 as an isolated service inside it. Plugins use the same manifests and capability-gated APIs on either platform." The isolation model is portable, not Cloudflare-locked.
  8. Single site → website platform via Workers for Platforms. Workers for Platforms lets hosting companies run each customer's site as a Worker on Cloudflare's global network without provisioning per-site servers; EmDash provides the content layer (admin, API, CLI, or an agent in front of the built-in MCP server). The sandboxed plugin model also lets platforms offer extensions across many customer sites safely, and run their own marketplaces (full registry, or a curated pre-approved selection).
  9. Customer Zero validation + spawned features. Migrating the Cloudflare Blog to EmDash in 2026-08 ("Customer Zero") had to handle millions of pageviews/week, spikes up to 5,000 RPS of legitimate traffic, and sporadic DDoS. That project spawned features now GA for all customers: optional KV object caching, the Hyperdrive database adapter, and Workers Cache compatibility.
  10. EmDash Build: AI site builder on a full stack. Open-sourced in alpha, EmDash Build creates a real EmDash site (server-rendered Astro pages, database, media storage, admin) instead of throwaway prompt output. 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; on publish, content moves into a production EmDash site and deploys to the host's Workers for Platforms namespace.
  11. Community + openness. 175+ contributors across 1,800+ commits; translated into 25 languages; MIT license. Registry services open-sourced: the aggregator (powers the registry), the labeler (Workers-AI moderation), and an Astro live content loader (registry-loader) for embedding listings in any Astro site.

Systems, concepts & patterns extracted

Systems - EmDash — the CMS reaching 1.0; primary subject. - AT Protocol (atproto) — decentralized network protocol underlying the registry; signed records + Merkle Search Trees + portable Atmosphere identity. New page. - Dynamic Workers — per-plugin isolate via the Worker Loader on Cloudflare. - workerd — subprocess runtime giving the same plugin isolation on Node.js. - Workers for Platforms — multi-tenant hosting substrate for EmDash-as-a-platform. - Workers AI — powers the labeler moderation service. - Cloudflare Sandbox — per-project container for EmDash Build's self-verifying agent. - Artifacts — git-commit change tracking in EmDash Build. - KV / Hyperdrive — object cache + DB adapter spawned by the Customer-Zero migration. - MCP / Agent Skills — built-in agent surfaces (the Avulux migration used Agent Skills; done in <1 day).

Concepts - Capability-based sandbox — canonical concept for the plugin isolation model; declared-then-approved capabilities, no ambient authority. - concepts/least-privileged-access, concepts/defense-in-depth, concepts/attack-surface-minimization — the security principles the plugin model realizes. - concepts/scale-to-zero — the per-isolate hosting economics under Workers.

Recorded as prose/tags (taxonomy gate — NOT minted as pages) - Merkle Search Tree / signed inclusion proof — canonical verifiable-data- structure idea, but single-source here; recorded as prose + tag on this page and systems/at-protocol, left for Lint promotion if it earns ≥2 sources. - Decentralized / portable publisher identity — reusable idea, single-source here; recorded on systems/at-protocol + tags. - Build provenance / software-supply-chain verification — single-source; recorded as prose + build-provenance tag. - Separate-the-plugin-from-the-catalog registry topology — an EmDash-specific instance of anti- marketplace-lock-in; recorded as prose, not a new pattern.

Operational numbers

  • 5,000 RPS legitimate-traffic spikes handled by the Cloudflare Blog on EmDash; "millions of pageviews per week."
  • 175+ contributors; 1,800+ commits; 25 languages; 800+ Discord members.
  • Noah Pham (intern → 2nd maintainer) contributed 80+ changes.
  • Avulux migrated a custom microsite to EmDash in <1 day using EmDash Agent Skills.
  • Lexington Themes ships 44 Astro themes with EmDash variants.

Caveats

  • This is a 1.0 release / product-launch post; it clears scope because the registry (atproto + signed Merkle Search Trees + inclusion proofs), the capability-based plugin sandbox (Worker Loader / workerd), and the multi-tenant platform model are substantive architecture, well above the AGENTS.md 20% bar.
  • No independent benchmarks; RPS/pageview figures are Cloudflare's own from the Customer-Zero migration.
  • Paid plugins are not yet supported ("we aim to add support… in future"); the post references watching Atproto Spaces Alpha with interest.
  • Some CLI/dashboard code snippets in the original render as empty blocks in the scraped markdown.

Source

Last updated · 766 distilled / 2,225 read