Skip to content

SYSTEM Cited by 1 source

EmDash

EmDash (emdash-cms/emdash, emdashcms.com) is Cloudflare's open-source TypeScript CMS, positioned as "the spiritual successor to WordPress." v0.1.0 preview launched 2026-04-01. Written entirely in TypeScript; powered by Astro for frontend rendering; runs serverless on Cloudflare Workers (workerd) or any Node.js server; MIT licensed.

Design thesis

WordPress's plugin architecture is structurally insecure — 96% of WordPress CVEs originate in plugins — because plugins are PHP scripts with direct access to WordPress's database and filesystem (no isolation). The WordPress.org marketplace exists to provide trust the platform can't, and because plugins run in the same execution context as WordPress itself, the GPL-inheritance argument locks plugin authors to the marketplace. EmDash inverts this: plugins are sandboxed; the marketplace becomes optional. See concepts/plugin-marketplace-lock-in.

Plugin architecture — capability-manifest per Dynamic Worker

EmDash plugins run as Dynamic Workers with a capability manifest. Each plugin is a fresh capability-based sandbox isolate. The manifest declares exactly which hooks and capabilities the plugin needs:

definePlugin({
  id: "notify-on-publish",
  version: "1.0.0",
  capabilities: ["read:content", "email:send"],
  hooks: {
    "content:afterSave": async (event, ctx) => {
      if (event.content.status !== "published") return;
      await ctx.email!.send({ /* ... */ });
    },
  },
});

Runtime-enforced properties:

  • No ambient authority. No filesystem access, no database access, no arbitrary network — unless granted via a capability.
  • Per-hostname network egress. Plugins specify exact hostnames in their definition; network calls to anything else fail at the runtime boundary.
  • Declared hooks only. A plugin can only observe content lifecycle events it declared.
  • Capabilities are install-time inspectable. An administrator can grant or refuse based on what the plugin requests, without reading plugin code.

Canonical instance of patterns/capability-manifest-plugin-isolation.

License-independent plugins

Two structural consequences of the sandbox model:

  1. Plugins can have any license. They run independently of EmDash core and share no code. Plugin authors pick the license — MIT, proprietary, AGPL, anything.
  2. Plugin code can be trusted without being seen. "A plugin can be provided to an EmDash site, and trusted, without the EmDash site ever seeing the code." The manifest + capability boundary is what's inspected, not the implementation.

Canonical instance of patterns/license-independent-sandboxed-plugins.

Theming — Astro

EmDash themes are Astro projects. Familiar to frontend developers, trained into LLMs, optimised for content sites. A theme includes:

  • Pages (Astro routes)
  • Layouts (shared HTML structure)
  • Components (reusable UI)
  • Styles (CSS or Tailwind)
  • Seed file (JSON describing content types and fields)

Themes cannot perform database operations — explicitly contrasted with WordPress themes' functions.php execution environment, which has the same power (and same risks) as plugins. EmDash themes inherit the sandbox model.

Scale-to-zero serverless hosting

EmDash is built to run on workerd (the open-source V8-isolate runtime under Workers). Workers instantly spins up an isolate per request, scales back to zero when idle, bills only for CPU time. See concepts/scale-to-zero. Platform operators can host millions of EmDash instances via Cloudflare for Platforms.

Portability: EmDash also runs on any Node.js server. The scale-to-zero economics are Cloudflare-specific; the code is not locked in.

Built-in x402 / agentic commerce

Every EmDash site has x402 support built in. Configure which content requires payment, set the price, provide a wallet address — HTTP 402 Payment Required-based per-request pricing works out of the box. Canonical agentic paywall primitive in a CMS.

AI-native management surfaces

Three programmatic-management surfaces ship with every EmDash instance:

  • Agent Skills — skill documents describe plugin capabilities, triggering hooks, a plugin-authoring skill, and a WordPress-theme-to-EmDash porting skill. Agents pointed at an EmDash codebase find the skills and work from them.
  • EmDash CLI — programmatic equivalents of Admin UI actions (media upload, content search, schema create/manage).
  • Built-in MCP Server — every EmDash instance exposes its own MCP server with the Admin UI's capability set.

Collapses the "rote migration of content" class of CMS work (find-and-replace, custom-field migration, bulk rename/reorder) from "one-off scripts or single-use plugins" to "agent tells the MCP server what to do."

Authentication — passkeys by default

Passkey / WebAuthn is the default — "no passwords to leak and no brute-force vectors to defend against." RBAC roles out of the box: administrator, editor, author, contributor.

Pluggable. Alternative auth backends (SSO via IdP) can auto-provision access based on IdP metadata.

WordPress migration path

Two options:

  • WXR export. Standard WordPress export file, imported via EmDash admin. Works for content + attached media.
  • EmDash Exporter WordPress plugin. Installs on a live WordPress site, exposes a secure endpoint protected by a WordPress Application Password, migrates content continuously.

Custom post types (previously requiring heavy plugins like Advanced Custom Fields) map onto EmDash's native schema/collections model — defined in the admin panel, stored in separate collections rather than squeezed into the posts table.

Openness

  • MIT license. Permissive; can be forked, extended, relicensed in combinations.
  • No WordPress code used. Clean-room TypeScript reimplementation of WordPress's functionality set. The "no WordPress code" claim is what unlocks the permissive license relative to WordPress's GPL.
  • GitHub-hosted, community PRs welcome, developer beta as of 2026-04.

Architectural relationship to Project Think / Dynamic Workers

EmDash applies the same capability-based sandbox primitive that Project Think uses for LLM-generated code, at a different layer: third-party plugins in a CMS. The manifest-then-grant shape is identical — Project Think's {network: ["api.github.com"], workspace: "read-write"} agent-extension manifest is the same move as EmDash's capabilities: ["read:content", "email:send"] plugin manifest. EmDash is the "user-uploads-a-plugin" variant of the "agent-writes-its-own-tool" pattern.

Seen in

Last updated · 200 distilled / 1,178 read