EmDash CMS Review: 6 Months After Release

EmDash is an open-source content management system (CMS) built with Astro, a web framework for building websites. Editors manage content in EmDash, while developers build the public site in Astro. This setup is for developers who want to manage content and build the public site within one application.

EmDash’s public beta began April 1, 2026, and version 1.0 shipped September 28. As of October 25, version 1.0 had been available for 27 days. The “six months” refers to development from beta to stable release, rather than time using version 1.0. EmDash looks promising for sites built with Astro, especially when operators need to isolate plugins. The site owner still has to manage hosting, data, deployment, and migration. Replacing a WordPress site with EmDash requires rebuilding parts of the site.

EmDash suits developers who want to own the site

EmDash separates content editing from public-site design. Editors use its administration interface to manage content; developers build the pages and their presentation in Astro. When a visitor loads a page, the Astro site can request content from EmDash. This lets the public site and CMS run together rather than as separate products.

Developers control how Astro presents the site, but they also have to run its supporting services. EmDash supports Cloudflare Workers with D1 and R2. Node.js deployments can use SQLite, PostgreSQL, or libSQL. SQLite requires persistent writable storage and backups. For multiple Node.js processes sharing a database, the database documentation lists PostgreSQL as an option. Before choosing EmDash, decide who will maintain the database, media storage, backups, and deployments.

EmDash is a better fit for an Astro project than for someone seeking a turnkey website builder. Its product guidance makes clear that a WordPress theme or plugin does not carry over as a working EmDash feature. Developers need to rebuild the site’s frontend and recreate plugin-specific behavior.

Plugin isolation depends on permissions and deployment

EmDash’s plugin design gives operators a way to limit what a plugin can access. EmDash runs a sandboxed plugin behind an isolation layer. The plugin must request specific permissions, called capabilities, such as reading content or making network requests. EmDash displays requested permissions for operator approval when installing a plugin from its registry.

Operators still need to review those permissions. A plugin granted content:write can write content broadly; the capability does not restrict it to content the plugin created. EmDash also supports native plugins, which run in the same process as the Astro site and have broader access. On Node.js, a sandbox runner must be available for sandboxed plugins to load. If an operator runs a plugin in the Astro site’s process instead, the plugin loses that isolation. The capabilities documentation warns against using that mode in production.

Before installing an extension, check the permissions it requests and confirm that the deployment has a sandbox runner configured. If a required plugin only runs natively, treat that as a security and maintenance tradeoff rather than assuming it receives the same isolation.

Cloudflare’s performance results need context

Cloudflare has reported production use of EmDash on its own blog, including traffic bursts and high cache usage. The company said the blog served up to 450 requests per second during a publishing period, while caching 99.5% of static files and 70% of requests. Those figures come from one site using Cloudflare’s infrastructure and cache settings. They do not show how much traffic every EmDash site can handle.

Cloudflare also reported testing a sudden 7,000-requests-per-second burst with k6, a tool for simulating traffic. The test shows how one deployment handled a simulated burst. It does not establish that other deployments can sustain the same rate. The reported 28,000-requests-per-second DDoS attack describes traffic faced by Cloudflare’s denial-of-service defenses, not the CMS’s serving capacity. The Cloudflare deployment report also mentions editor-side quirks and scheduled-post bugs during migration, a reminder that strong traffic handling does not establish that every publishing feature is polished.

An independent operator reported faster page-load measurements on one migrated site, but that comparison was limited to the operator’s own page and setup. Treat it as a case study, not a benchmark for choosing a host or predicting results. For a real evaluation, measure your own representative pages with the same content, caching, and hosting conditions you expect in production.

WordPress imports move content, not the whole site

EmDash supports importing WordPress content from an export file or through its exporter plugin. The import documentation says the public WordPress REST source helps with probing and counts, but does not import content. A successful import therefore does not mean the new site reproduces the old one.

During migration, developers also need to check page layouts, theme behavior, plugin features, menus, custom fields, and URLs. An operator reviewing five sites on EmDash 1.1.0 reported issues involving nested pages, custom fields, menus, and date-based URLs. Those findings were checked on October 5, 2026, and later releases followed, so they should be treated as dated observations rather than confirmed current defects. Before changing production traffic, run a test import and compare representative content and URLs. Confirm that redirects preserve important paths before making the change.

EmDash 1.0 also removed APIs deprecated during the beta period. Anyone upgrading from a pre-1.0 release should follow the upgrade instructions rather than treating the change as a routine patch. The project’s 1.0 announcement describes the release as the result of months of stabilization and development. EmDash 1.1 later added features including a publishing calendar and Microsoft sign-in, so evaluations should record the exact version tested. Its 1.1 release notes distinguish those additions from what shipped in 1.0.

The verdict: a credible option for Astro sites

EmDash is worth evaluating when developers are already building with Astro, editors need structured content management, and the site owner is prepared to run the supporting services. Its plugin capability model offers a meaningful security boundary when the deployment supports sandboxing and operators review permissions.

It is a poor fit for a site that depends on WordPress themes or plugins, or for an owner expecting a hosted, no-code service. The site owner still has to account for hosting, storage, migration, development, and ongoing operating costs. Estimate those costs for the intended deployment, then test the migration and editorial workflow before committing.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com