EmDash puts the CMS inside an Astro site
EmDash lets editors define content collections through an admin interface while developers build the site in Astro. That is a useful division of work for a small publication: changing a collection needn't mean asking a developer to edit its definition in code. This review concerns emdash-cms/emdash, the TypeScript content-management system. It has no connection to the similarly named desktop coding-agent application.
The attraction is an editorial backend that belongs with the website. The README documents an Astro integration with authentication, a media library, and a REST API. I'd consider it for an Astro team prepared to own its publishing workflow. Our successful source build earns it a trial, but the failed test command leaves a specific verification job before moving a working publication.
What happened when we ran it
Our sandbox installed EmDash commit 9a06701 in 59 seconds and built it in 98 seconds on October 20, 2026. Installation recorded 1,672 dependencies occupying 2,341 MB. The test step failed with exit 1 after 36 seconds. The supplied Vitest summary reports 17 passed and 0 failed out of 17, yet the command as a whole failed. Those are different observations, and both belong in the decision.
The log tail shows passing registry-package summaries alongside an admin-package error. Under packages/admin, it lists 252 test files, says no tests, and reports 1 error. The final line is an ELIFECYCLE failure. The excerpt omits the error's cause. It cannot establish whether the problem came from the sandbox, a prerequisite, or the application, and the partial passing counts cannot certify the workspace.
Our checkout had 5,298 files, about 1,149,300 source lines, and occupied 82.3 MB. The scan recorded 27 CI workflow files, a Dockerfile, a Compose file, and monorepo workspaces. It detected no tests directory, despite the actual test command running package suites. Directory-name detection clearly has limits here. No vulnerability-audit result was supplied for this run, so there is no security count to report.
The recorded configuration was 3 CPUs and 8 GB RAM with image label lab-node:22. That name does not establish the actual Node.js version or operating system. These measurements describe the contributor checkout, rather than the footprint of a deployed website. They also say nothing about editor usability, migration fidelity, or publishing throughput. We have not earned those conclusions by compiling the repository.
Choose Cloudflare services or a Node.js deployment
The README offers Cloudflare with D1, R2, and Workers, plus a Node.js path with SQLite. Its local demo does not require a Cloudflare account. The practical choice is who operates the database and media storage. For a hosted deployment, budget time for the selected platform's account access and configuration instead of treating a successful contributor build as a finished website.
Storage choices also affect recovery. Before importing publication data, decide where the database and uploaded media will persist, then verify that you can restore them. That is adoption advice, not a backup exercise our lab completed. Keeping the initial trial disposable lets you inspect the admin workflow without confusing sample content with a migration you can reverse safely.
Plugin permissions deserve a trial, not a security guarantee
EmDash documents capability manifests and sandboxed plugin execution, using Worker isolates on Cloudflare and a workerd child process on Node.js. Declared permissions make a plugin's intended access easier to inspect. The README's stronger claim that this solves WordPress's plugin-security problem goes beyond our evidence: our source run did not probe isolation or permissions.
The versioning boundary matters sooner. First-party plugins and plugin tooling remain on 0.x and may change between minor releases. A team depending on custom publishing behavior should check those package versions separately from the core CMS. If maintaining an extension through those changes is unacceptable, that is a concrete reason to wait. A stable core label cannot promise an unchanged plugin interface.
An open email report makes account flows worth checking
Issue 4311 reports that development-mode email can continue going to the console after a real provider is configured. The report concerns astro dev and explicitly distinguishes production behavior. It was open when checked on October 20, 2026. This is a reported development-mode problem, not the diagnosed cause of our admin test error or evidence that production email fails.
GitHub recorded a push on October 20 and 327 open issues and PRs combined. A proposed email fix was also visible in that day's queue, which indicates active work without proving the fix has shipped. Try the invitation and recovery flows your editors will use, with your chosen provider. A provider's own successful check may not answer whether the CMS selected it for delivery.
Pick Astro integration only if it matches your publication
Payload describes a CMS that runs inside a Next.js app, making it the closer alternative for a team already committed to that framework. Ghost offers a managed publishing service as well as a self-hosted route. Pick Ghost's managed option when operating the CMS is work you want to buy from someone else. These are product and hosting distinctions, without comparative benchmarks from our lab.
EmDash also publishes skills with a Claude Code installation path and includes an MCP server for agent access. Neither feature resolves the failed workspace check. Keep the first decision smaller: can an editor create the content your Astro site needs and recover access through the configured account flow? Resolve the missing test error and exercise that workflow on a disposable site before importing the publication's archive.