EmDash CMS review: enterprise fit vs Payload

EmDash CMS has my attention. It puts a CMS inside an Astro project, gives editors a visual schema builder, generates TypeScript types for developers, and includes an MCP server with its own authorization model. That is a coherent set of choices.

The official repository labels it beta preview. The first-party documentation describes several limits that would matter in an enterprise review today. I would put EmDash on a shortlist for the right Astro project, then run a focused prototype before making it the content platform.

At WAYF, we know Payload much better. We have built and contributed to Payload projects, including enterprise content platforms, and we are an official Payload partner and top contributor. That experience shapes the comparison below. It also makes me interested in EmDash, because it approaches some familiar full-stack CMS problems from the Astro side.

What EmDash CMS is

EmDash is an open-source CMS built as an Astro integration. Its architecture documentation describes the CMS, admin panel, database access, and site as one application. Astro Live Collections query the live content in the same runtime.

EmDash requires Astro. Its documentation describes it as a full-stack CMS, with REST and CLI access for integrations alongside the native Astro queries.

The content model also takes an unusual route. Editors and administrators can create collections and fields visually. Developers can then generate TypeScript types from that live model and export it as a JSON seed. Editors gain direct control over the model, and the application gets typed content.

Teams that require pull-request approval for every schema change need to test this workflow carefully. A database-backed live model moves that control into the CMS. I would test the exact development, staging, and production process before approving it for a governed content estate.

The parts I find most interesting

Its content guide documents drafts, revisions, scheduling, previews, media, taxonomies, menus, and structured rich text. The editor uses TipTap and stores Portable Text rather than serialized page HTML.

EmDash stores each translation as an independent entry with its own slug, status, and revision history. The internationalization guide also covers fallbacks, locale-aware menus and taxonomies, sitemap alternates, and independent publishing. Teams should check Astro routing configuration because prefixDefaultLocale needs an edge redirect workaround for the injected admin.

Passkeys are the default authentication method. The authentication documentation also covers GitHub, Google, AT Protocol, magic links, and a Cloudflare Access mode with identity-provider group mapping. That Cloudflare mode becomes the exclusive authentication path when enabled, which is useful to know during an SSO review.

The built-in MCP server supports OAuth 2.1 with PKCE, personal access tokens, device flow, scopes, role checks, and revision tokens for optimistic concurrency. Agent access increases the number of actions the authorization and audit model must cover. EmDash has put those concerns in the documented design.

Plugins use declared capabilities. In sandboxed mode, EmDash can isolate storage, restrict network hosts, and require fresh consent when an update asks for more access. The capability model and sandbox documentation are unusually direct about what the runtime can and cannot enforce.

Is EmDash CMS good for enterprises?

For a single-brand Astro site with a known editorial team, it may already cover the requirements that matter. The architecture is compact, the editorial feature set is credible, localization treats translations as independently publishable content, and Cloudflare Access can provide an enterprise identity boundary on Cloudflare deployments.

I would not make it a general enterprise default today. EmDash uses five fixed hierarchical roles, from Subscriber through Admin. Payload can run access functions at the operation, collection, document, and field level. That difference becomes material when an organization needs regional permissions, field-specific controls, or rules that depend on the document and user together.

I also found no documented first-class multitenancy feature in the complete EmDash documentation index. I could not find a public enterprise support plan, SLA, compliance certification, or native SAML documentation either. These are procurement and operating requirements for many enterprises, even when the software itself covers the publishing workflow.

Recovery needs a closer look. The backup documentation covers downloadable JSON archives, daily archives, database dumps, and D1 Time Travel. JSON backups exclude authentication data, secrets, and media binaries, and guided JSON restore is still planned. A production evaluation should include a restore drill using the chosen database and media storage.

The biggest security caveat is in the project’s own secrets documentation. Plugin secrets are currently stored unencrypted in the database. The encryption key is validated, but the planned encryption layer is not active yet. Sandboxed plugins also receive fairly broad capabilities once approved. For example, content:write can edit any content.

Isolation varies by deployment. Cloudflare provides the stronger sandbox and requires a Workers Paid plan. The Node runner cannot enforce per-plugin CPU or memory limits. Native and in-process plugins run with full host access. Any enterprise security review should evaluate the actual deployment mode and every enabled plugin. The phrase “sandboxed plugins” does not describe one uniform guarantee.

EmDash CMS vs Payload

The two sit differently against an Astro project. EmDash is the Astro site: the CMS, the admin panel, and the pages are one application. Payload’s app and admin run in Next.js and serve Astro and other decoupled frontends through REST and GraphQL, so an Astro site consumes Payload rather than containing it.

Decision	EmDash CMS	Payload
Where the CMS app runs	Inside the Astro app	A Next.js app, serving any frontend via REST and GraphQL
Content model	Editors can change schemas visually; developers generate types from the live model	Developers define schemas in TypeScript and ship migrations
Application access	Astro Live Collections, REST, CLI, built-in MCP	Local API, REST, GraphQL, first-party MCP plugin
Permissions	Five fixed hierarchical roles plus token scopes	Programmable operation, collection, document, and field access functions
Multitenancy	No documented first-class feature	Official multi-tenant plugin
Localization	Each translation is a separate entry with its own slug, status, and revisions	Field-level localization
Plugins	Native plugins or capability-gated sandboxes	Application code, hooks, and plugins run in the Payload application
Hosting	Cloudflare or Node with several SQL and media-storage options	Suitable Next.js infrastructure with MongoDB, PostgreSQL, or SQLite
Maturity	Beta preview, public repository created in 2026	Public repository since 2021, broader documentation and commercial enterprise options

EmDash has the more accessible schema workflow for editors. Payload puts the schema, migrations, hooks, and access rules in TypeScript. I prefer Payload’s model when content structure is treated as application infrastructure and changes must go through code review. I can see EmDash working better when content specialists need to shape the model directly and the team accepts a controlled admin workflow for those changes.

Payload has the stronger documented case for complex enterprise authorization. Its access-control functions can evaluate the current user and data at several levels, and its official multitenancy plugin applies tenant filters and access checks. Payload also markets enterprise SSO, audit logs, publishing workflows, and paid support. Licensed features and contract terms still need direct confirmation during procurement.

Both expose MCP, in different shapes. EmDash ships it in core, with OAuth 2.1 and PKCE, device flow, scopes, and revision tokens for optimistic concurrency. Payload offers it through its first-party MCP plugin, which can allow or disallow find, create, update, and delete operations per collection. A team building agent-assisted editorial operations in Astro should compare the two authorization models directly rather than read MCP as a point of difference on its own.

EmDash documents Cloudflare Workers with D1 and R2, plus Node deployments using SQLite, libSQL, or PostgreSQL and local or S3-compatible media. Payload can run on suitable Next.js infrastructure and remains self-hostable. Payload Cloud says new project deployments are paused following Figma’s acquisition of Payload in June 2025, so a new Payload project should plan around self-hosting or confirm the latest hosted option directly.

My current recommendation

EmDash is worth testing for new Astro sites. I would start with one representative content type, a preview and publishing flow, one translation, the intended SSO path, a realistic plugin, and a backup restore drill. The actual editors and security team should use that prototype.

For a project that needs fine-grained permissions, first-class multitenancy, formal compliance evidence, or contractual support, Payload has the stronger documented position today. EmDash becomes more convincing when the project is already committed to Astro and values its visual schema workflow, per-locale entry model, and built-in MCP access.

I am interested enough to test it ourselves. I am not ready to treat beta software as a blanket enterprise recommendation. The requirements and the prototype should make that decision.