EmDash: A WordPress successor built with sandboxing from day one
Cloudflare has unveiled EmDash, a new open-source CMS designed as a modern successor to WordPress. Now in a v0.1.0 preview, EmDash is written entirely in TypeScript, runs on serverless infrastructure, and is powered by the Astro web framework. It is fully open source under the MIT license and available on GitHub.
The project is a direct response to the longevity of WordPress, which remains a dominant force but approaches its 24th year. While WordPress enabled publishing at an unprecedented scale, the technical environment around hosting has changed drastically since its creation—moving from virtual private servers to globally distributed serverless networks. EmDash aims to update the CMS for that new reality.
You can deploy the preview to a Cloudflare account or a Node.js server, try the interface in the EmDash Playground, or scaffold a new site locally with:
npm create emdash@latest
The plugin security problem
The core architectural difference between EmDash and WordPress lies in plugin security. WordPress plugins are PHP scripts with direct access to the site's database and filesystem—there is no isolation. Installing a plugin means trusting it with nearly everything. The results speak for themselves: 96% of WordPress security issues originate in plugins, and 2025 saw more high-severity vulnerabilities across the ecosystem than the prior two years combined.
EmDash changes this by putting each plugin in its own sandboxed isolate via Dynamic Workers. Plugins don´t get direct data access; instead, they declare what they need in a manifest, and EmDash grants access via bindings based on those declared capabilities. The security guarantee is strict: a plugin can only perform actions explicitly declared upfront. The model is analogous to scoped permissions in an OAuth flow.
Consider a plugin that sends an email after content is saved:
import { definePlugin } from "emdash";
export default () =>
definePlugin({
id: "notify-on-publish",
version: "1.0.0",
capabilities: ["read:content", "email:send"],
hooks: {
"content:afterSave": async (event, ctx) => {
if (event.collection !== "posts" || event.content.status !== "published") return;
await ctx.email!.send({
to: "[email protected]",
subject: `New post published: ${event.content.title}`,
text: `"${event.content.title}" is now live.`,
});
ctx.log.info(`Notified editors about ${event.content.id}`);
},
},
});That plugin requests two capabilities: content:afterSave for the content lifecycle hook and email:send for the ctx.email function. It has no external network access unless it specifies an exact hostname it needs to reach, in which case it can only communicate with that hostname. Because capabilities are static and declared in advance, administrators can decide at install time exactly what a plugin can do—or enforce rules about which permissions certain users may grant.
Escaping marketplace lock-in
WordPress.org manually reviews every plugin in its marketplace, a process that currently has an 800-plugin backlog and takes at least two weeks. The deep coupling between plugins and WordPress core also means plugins carry the GPL license forward. That combination—high security risk, manual vetting, and licensing constraints—creates a chilling effect on developers and hosting platforms.
EmDash plugins sidestep this in two ways:
- Plugins can have any license. They share no code with EmDash and run independently, leaving the licensing choice entirely to the author.
- Plugins run in a secure sandbox. A site can trust and run a plugin without ever seeing its code.
The first property makes plugin distribution analogous to publishing to NPM or PyPI—an open ecosystem where the community sets norms. The second reduces reliance on centralized marketplace reputation. With clearly bounded permissions, sites and platforms can assess a plugin's security posture directly. The trust shifts from "the marketplace vetted this" to "this plugin can only do exactly what it declared it does."
Built-in payments for the agent era
Content creators face a fundamental shift as AI agents increasingly access the web on behalf of human users. The traditional model—free access in exchange for ad views—breaks down when no human is looking at the page. To address this, EmDash includes built-in support for x402, an open standard for Internet-native payments.
With x402, a client sends a request and receives an HTTP 402 Payment Required status. The client can then pay on-demand for access. EmDash sites can charge for content without subscriptions or custom engineering—just configuration for which content requires payment, the price, and a wallet address.
True scale-to-zero architecture
WordPress is fundamentally server-bound: it requires provisioning and managing servers that run idle compute or share resources under spikes, especially for uncacheable server-rendered content. EmDash is built for serverless platforms and the v8 isolate architecture of Cloudflare's open source runtime workerd. An isolate spins up on request and scales back to zero when traffic stops, with billing based on CPU time used.
This architecture means hosting platforms using Cloudflare for Platforms can offer millions of independent EmDash instances, each scaling fully to zero between requests without sacrificing the ability to handle high RPS spikes. The economics support low-cost and free tiers, extending that capability to small sites as well as large.
Theme and frontend architecture
EmDash themes are Astro projects, making frontend work familiar to developers who already use the framework. A theme includes Astro pages (homepage, blog posts, archives), shared layouts, reusable components, CSS or Tailwind styles, and a seed file defining content types and fields.
WordPress themes carry similar security risks to plugins, and functions.php provides an all-encompassing execution environment. EmDash themes cannot perform database operations—an intentional constraint that reverses the WordPress expectation of full-power themes.
An AI-native CMS
Content migration and maintenance is tedious work—string replacements, custom field conversions, renames and reordering across a site. EmDash is designed for programmatic management by AI agents, which lowers the friction in that work:
- Agent Skills: A skill describing the capabilities EmDash can provide to plugins, available hooks, plugin structure guidance, and a skill for porting legacy WordPress themes to EmDash.
- CLI: The EmDash CLI lets agents interact with local or remote instances—uploading media, searching content, and managing schemas among other tasks available in the Admin UI.
- Built-in MCP Server: Every instance provides its own remote Model Context Protocol server with the same functionality as the admin interface.
Authentication and migrations
EmDash uses passkey-based authentication by default, eliminating password leaks and brute-force attacks out of the box. Role-based access control comes standard with distinctions between administrators, editors, authors, and contributors, and authentication is pluggable to support SSO providers and IdP-based provisioning.
Migration from WordPress is supported through two routes: a standard WXR file export, or the EmDash Exporter plugin, which exposes a secure, password-protected endpoint for direct migration. Content transfers take minutes, and attached media moves into EmDash's media library automatically. Custom post types don't require heavy plugins like Advanced Custom Fields—schemas are defined directly in the admin panel as separate collections in the database, usable for import mapping as well. For bespoke blocks, an Agent Skill can guide an AI assistant in creating them for EmDash.
EmDash is positioned as a 0.1.0 preview, with contributions welcome on GitHub and feedback sought from WordPress hosting platforms, plugin authors, and theme developers.
