EmDash 1.0 launches with a decentralized plugin registry

Stable CMS, free-plugin support

Cloudflare has announced EmDash 1.0, describing it as a stable, free, MIT-licensed content management system built on Astro. Developers build with Astro, editors manage content through the EmDash admin, and agents can use an API, CLI or built-in MCP server, according to Cloudflare’s announcement.

The release introduces a decentralized plugin registry where developers can publish sandboxed plugins and site owners can discover, inspect and install them. The registry supports free plugins at launch; Cloudflare says paid-plugin support is a future goal.

Signed releases, separate from discovery

According to Cloudflare, the registry uses AT Protocol, the decentralized protocol that also powers Bluesky. Publishers retain signed package and release records in their own accounts, while catalogs provide discovery. Other services can index the same publications without requiring developers to recreate their release histories. EmDash hosts the default registry services, so using the registry does not require publishers or site owners to operate that infrastructure themselves.

Cloudflare says EmDash uses inclusion proofs to connect exact release records to signed commits from publishers’ accounts. It then checks the plugin’s checksum, package name, version, requested access and any required build provenance, confirming that the downloaded bundle matches the signed record. Moderation can hide material from the default catalog without rewriting a release or erasing its underlying publication, according to the registry announcement.

For engineers, this separates two questions: whether a catalog displays a package and whether its release can be independently verified. Neither catalog visibility nor a matching signed record should be treated as a security audit.

Permissions govern execution

Cloudflare says sandboxed EmDash plugins run in isolated runtimes with private storage. They do not receive access to site content, media, users, secrets, the environment, filesystem or network by default. Additional capabilities must be declared by the plugin and approved by a site administrator; the runtime then limits the plugin to those approved capabilities.

The practical distinction is between release authenticity and execution authority. Verification checks the bundle against the signed publication; sandboxing constrains what installed code can access. Administrators should still compare requested permissions with each plugin’s purpose and test upgrades against representative content and editorial workflows. Permission approval remains a judgment about what data and operations to expose—not merely whether the release record verifies.