Discover EmDash : A Comprehensive Guide from WhatSiteIs

Announcing EmDash: The Spiritual Successor to WordPress That Fixes Plugin Security Once and For All

The cost of building software has plummeted. Recently, Cloudflare rebuilt Next.js in just one week using AI coding agents. But for the past two months, our agents have been tackling an even more ambitious project: rebuilding the entire WordPress open source platform from scratch.

WordPress powers over 40% of the internet. That's an incredible success story—it has enabled anyone to become a publisher and created a global community of developers. But this year, WordPress turns 24 years old. In that time, the way Cloudflare host websites has changed dramatically. When WordPress was born, AWS EC2 didn't even exist. Since then, we've gone from renting virtual private servers to uploading JavaScript bundles to a globally distributed network at almost zero cost. It's time to upgrade the world's most popular CMS to take full advantage of these changes.

Cloudflare call this new CMS EmDash—the spiritual successor to WordPress. Here's what makes it different:

Written entirely in TypeScript
Serverless by design, but you can run it on your own hardware or any platform you choose
Plugins are securely sandboxed in their own isolates using Dynamic Workers, solving WordPress's fundamental security flaw
Powered by Astro, the fastest web framework for content-driven websites

EmDash is fully open source under the MIT license and available on GitHub. While Cloudflare aim for compatibility with WordPress functionality, Cloudflare built EmDash from the ground up without using any WordPress code. That allows us to offer the more permissive MIT license, and Cloudflare hope it encourages more developers to adapt, extend, and contribute.

You can deploy the EmDash v0.1.0 preview to your Cloudflare account or any Node.js server today as part of our early developer beta. Or try out the admin interface right now in the EmDash Playground.

What WordPress Has Accomplished (And Why Cloudflare Need More)

WordPress's story is an open source triumph. Few projects have had such a recognizable impact on the internet generation. The contributors to WordPress core, along with thousands of plugin and theme developers, built a platform that democratized publishing for millions of people—transforming lives and livelihoods.

There will always be a place for WordPress. But the world of content publishing still has room to grow. A decade ago, anyone picking up a keyboard learned to blog with WordPress. Today, that same person is just as likely to reach for Astro or another TypeScript framework.

The ecosystem needs an option that empowers a wide audience, just as WordPress did 23 years ago. EmDash builds on what WordPress created—an open source publishing stack anyone can install and use at little cost—while fixing the core problems that WordPress can't solve.

Solving the WordPress Plugin Security Crisis

WordPress's plugin architecture is fundamentally insecure. Consider these facts:

96% of security issues in WordPress sites originate in plugins
In 2025, more high-severity vulnerabilities were found in the WordPress ecosystem than in the previous two years combined

Why is WordPress plugin security so problematic after more than two decades?

A WordPress plugin is a PHP script that hooks directly into WordPress to add or modify functionality. There's no isolation—a plugin has direct access to the site's database and filesystem. When you install a WordPress plugin, you're trusting it with access to nearly everything, and trusting it to handle every malicious input or edge case perfectly.

EmDash solves this completely.

In EmDash, each plugin runs in its own isolated sandbox: a Dynamic Worker. Instead of giving direct access to underlying data, EmDash provides plugins with capabilities via bindings, based on what the plugin explicitly declares in its manifest.

Here's the guarantee: An EmDash plugin can only perform the actions explicitly declared in its manifest. Before installing a plugin, you know exactly what permissions you're granting—just like going through an OAuth flow and granting a third-party app specific, scoped permissions.

For example, here's 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: "editors@example.com",
          subject: `New post published: ${event.content.title}`,
          text: `"${event.content.title}" is now live.`,
        });

        ctx.log.info(`Notified editors about ${event.content.id}`);
      },
    },
  });

This plugin explicitly requests two capabilities: content:afterSave to hook into the content lifecycle, and email:send to access the email function. It's impossible for the plugin to do anything else. It has no external network access. If it does need network access, it can specify the exact hostname it needs to talk to—and be granted only that specific communication ability.

Because plugin needs are declared statically upfront, a platform or administrator could define rules about which plugins different user groups can install based on the permissions they request—no more relying on an allowlist of "approved" plugins.

Solving Plugin Security Means Breaking Marketplace Lock-In

WordPress plugin security is such a serious risk that WordPress.org manually reviews and approves every plugin in its marketplace. Right now, that review queue has over 800 plugins and takes at least two weeks to process. The vulnerability surface is so wide that everyone ends up relying on marketplace reputation, ratings, and reviews.

And because WordPress plugins run in the same execution context as WordPress itself and are deeply intertwined with WordPress code, some argue they must carry WordPress's GPL license forward.

These realities create a chilling effect on both developers building plugins and platforms hosting WordPress sites.

Plugin security is the root cause. Marketplaces exist to provide trust when parties can't easily trust each other. In WordPress's case, the plugin security risk is so large that your customers can only reasonably trust your plugin through the marketplace. But to be in that marketplace, your code must be licensed in a way that forces you to give it away for free everywhere else. You're locked in.

EmDash plugins have two important properties that break this lock-in:

Any license is allowed — Plugins run independently of EmDash and share no code. The plugin author chooses the license, just like publishing to NPM, PyPi, or Packagist.
Code runs independently in a secure sandbox — A plugin can be provided to an EmDash site and trusted without the site ever seeing the code.

This second point is where EmDash truly breaks free from centralized marketplaces. Consider the example plugin above that sends emails after content is saved. It declares three things:

It only runs on the content:afterSave hook
It has the read:content capability
It has the email:send capability

That plugin could have tens of thousands of lines of code, but unlike a WordPress plugin that has access to everything and can talk to the public internet, the person adding the plugin knows exactly what access they're granting. Clearly defined boundaries let you make informed security decisions and focus on risks directly related to the capabilities the plugin is given.

The more that sites and platforms can trust the security model to provide constraints, the more they can trust plugins—and break free from centralized control of marketplaces and reputation. Think of it like food safety: if you trust inspections in your city, you'll try new restaurants. If you can't trust there might be a staple in your soup, you'll research every single place before visiting, and it's harder for anyone to open a new restaurant.

Built-In x402 Support: Charge for Content Access

The web's business model is at risk, especially for content creators and publishers. The old approach—making content widely accessible and giving free access in exchange for traffic—breaks when there's no human looking at the site to advertise to, and instead the client is an AI agent accessing the web on their behalf.

Creators need new ways to make money in this world of agents, and to build websites that serve what people's agents need and will pay for.

Enter x402—an open, neutral standard for internet-native payments. It lets anyone on the internet easily charge, and any client pay on-demand, on a pay-per-use basis. A client (like an agent) sends an HTTP request and receives a 402 Payment Required status code. The client pays for access, and the server lets them through to the requested content.

Every EmDash site has x402 support built in. Anyone with an EmDash site can charge for access to their content without subscriptions and with zero engineering work. Just configure which content requires payment, set the price, and provide a wallet address.

That's right: every EmDash site comes with a built-in business model for the AI era.

Solving Scale-to-Zero for WordPress Hosting Platforms

WordPress is not serverless. It requires provisioning and managing servers, scaling them up and down like a traditional web application. To maximize performance and handle traffic spikes, you inevitably need to pre-provision instances and run some amount of idle compute—or share resources in ways that limit performance. This is especially true for sites with content that must be server-rendered and can't be cached.

EmDash is different. It's built to run on serverless platforms and takes full advantage of the v8 isolate architecture in Cloudflare's open source runtime, workerd.

On an incoming request, the Workers runtime instantly spins up an isolate to execute code and serve a response. It scales back down to zero if there are no requests. And you only pay for CPU time—actual work done.

You can run EmDash anywhere, on any Node.js server. But on Cloudflare, you can run millions of EmDash instances using Cloudflare for Platforms. Each one instantly scales fully to zero or up to as many requests per second as you need, using the same network and runtime that the world's biggest websites rely on.

Beyond cost optimizations and performance benefits, we've bet on this architecture because Cloudflare believe in low-cost and free tiers. Everyone should be able to build websites that scale.

Modern Frontend Theming and Architecture via Astro

EmDash is powered by Astro, the web framework for content-driven websites. To create an EmDash theme, you create an Astro project that includes:

Pages — Astro routes for rendering content (homepage, blog posts, archives, etc.)
Layouts — Shared HTML structure
Components — Reusable UI elements (navigation, cards, footers)
Styles — CSS or Tailwind configuration
A seed file — JSON that tells the CMS what content types and fields to create

This approach feels familiar to frontend developers who are increasingly choosing Astro, and to LLMs that are already trained on Astro.

WordPress themes, though incredibly flexible, carry many of the same security risks as plugins. The more popular and commonplace your theme, the bigger a target it becomes. Themes run through functions.php—an all-encompassing execution environment that makes themes both incredibly powerful and potentially dangerous.

EmDash themes turn this expectation on its head. Your theme can never perform database operations.

An AI-Native CMS: MCP, CLI, and Skills for EmDash

The least fun part of working with any CMS is doing rote content migration: finding and replacing strings, migrating custom fields, renaming, reordering, and moving things around. This is either boring repetitive work or requires one-off scripts and "single-use" plugins and tools that are neither fun to write nor to use.

EmDash is designed to be managed programmatically by your AI agents. It provides the context and tools your agents need:

Agent Skills — Each EmDash instance includes Agent Skills that describe to your agent what capabilities EmDash can provide to plugins, which hooks can trigger plugins, guidance on structuring a plugin, and even how to port legacy WordPress themes to EmDash natively. Give an agent an EmDash codebase, and EmDash provides everything the agent needs to customize your site.
EmDash CLI — Enables your agent to interact programmatically with your local or remote EmDash instance. Upload media, search for content, create and manage schemas—anything you can do in the Admin UI.
Built-in MCP Server — Every EmDash instance provides its own remote Model Context Protocol (MCP) server, allowing you to do the same set of things you can do in the Admin UI.

Pluggable Authentication with Passkeys by Default

EmDash uses passkey-based authentication by default—no passwords to leak and no brute-force vectors to defend against. User management includes familiar role-based access control out of the box: administrators, editors, authors, and contributors, each scoped strictly to the actions they need. Authentication is pluggable, so you can set EmDash up to work with your SSO provider and automatically provision access based on IdP metadata.

Import Your WordPress Sites to EmDash

You can import an existing WordPress site either by exporting a WXR file from WordPress admin, or by installing the EmDash Exporter plugin on your WordPress site. The exporter configures a secure endpoint exposed only to you and protected by a WordPress Application Password you control. Migrating content takes just a few minutes and automatically brings any attached media into EmDash's media library.

On WordPress, creating custom content types that aren't posts or pages has meant installing heavy plugins like Advanced Custom Fields and squeezing everything into a crowded WordPress posts table. EmDash does things differently: you can define a schema directly in the admin panel, which creates entirely new EmDash collections, separately ordered in the database. On import, you can take any custom post types from WordPress and create an EmDash content type from them.

t Skill to instruct your agent of choice and build them for EmDash.

Try It Today

EmDash is v0.1.0 preview. We'd love for you to try it, give feedback, and contribute to the EmDash GitHub repository.

Just want to play around first? Try the admin interface in the EmDash Playground.

To create a new EmDash site locally via the CLI, run:

npm create emdash@latest

Or do the same through the Cloudflare dashboard.

Here is a detailed comparison of EmDash (a new CMS announced by Cloudflare) and WordPress.

The core difference is that EmDash is a modern, serverless, security-first CMS designed to be the "spiritual successor" to WordPress, directly addressing WordPress's fundamental architectural issues—particularly around plugin security and scalability.

Feature	EmDash	WordPress
Core Philosophy	"Spiritual successor to WordPress" designed for the AI and serverless era.	Legacy open-source CMS powering over 40% of the web. Mature but aging.
Plugin Security	Fundamentally secure. Plugins run in isolated sandboxes (Dynamic Workers) with explicit, declared capabilities (e.g., `read:content`, `email:send`). No direct database or filesystem access.	Fundamental security risk. 96% of security issues originate in plugins. Plugins have full access to the database, filesystem, and WordPress core.
Plugin Marketplace	No lock-in. Any license is allowed. Code is never shared with the host site. Trust is based on the security model, not marketplace reputation.	Marketplace lock-in. Requires GPL license and manual approval (800+ plugin queue). Trust relies heavily on marketplace ratings and reviews.
Hosting & Scaling	Serverless & scale-to-zero. Built for v8 isolates (Cloudflare Workers). No idle compute costs. Scales instantly from zero to millions of requests.	Traditional server-based. Requires provisioning and managing servers. Must run idle compute to handle traffic spikes.
Theme Architecture	Powered by Astro. Themes are Astro projects (pages, layouts, components). Cannot perform database operations, making them inherently safer.	Uses `functions.php`. An all-encompassing, powerful, but potentially dangerous execution environment for themes.
Content & AI	AI-native. Includes an MCP server, CLI, and "Agent Skills" to allow AI agents to manage content, migrate sites, and build plugins programmatically.	Requires third-party plugins or custom scripts for AI integration. Not designed for programmatic agent interaction.
Business Model	Built-in x402 payments. Can charge for content access on a pay-per-use basis (HTTP 402) without subscriptions.	Relies on third-party plugins, memberships, or ad-based models. No native, granular payment standard.
Authentication	Passwordless by default. Uses passkeys. No passwords to leak or brute-force. Pluggable SSO.	Traditional username/password. Password leaks and brute-force attacks are common.
License	MIT License (permissive, allows proprietary use).	GPL License (requires derivative works to also be GPL).
Migration from WordPress	Supported. Can import via WXR file or a dedicated exporter plugin. Can convert custom post types to EmDash collections.	N/A
Current Status	v0.1.0 preview (early developer beta, as of April 1, 2026).	Stable, mature, production-ready.

Key Insights from the Article

The "Insecure by Design" Problem of WordPress Plugins: The article is highly critical of the WordPress plugin architecture, stating it is "fundamentally insecure." EmDash solves this by sandboxing each plugin and requiring a capability manifest (similar to an OAuth scope request). You know exactly what a plugin can do before you install it.
EmDash is Built for Modern Development: It is written entirely in TypeScript, uses Astro for theming (popular with modern frontend developers), and is designed to run on serverless platforms. This makes it attractive to developers who find WordPress's PHP and traditional hosting model outdated.
Native Support for the "AI Agent" Era: EmDash is not just a CMS for humans. It includes an MCP server and Agent Skills so that AI agents can programmatically manage content, build plugins, and perform migrations. This is a forward-looking feature WordPress lacks.
A New Business Model for Publishers: The built-in x402 payment standard allows any EmDash site to charge for content on a per-access basis. This is positioned as a solution for content creators in an era of AI agents that browse the web, replacing the traditional ad-based model.
Breaking Marketplace Lock-in: By solving plugin security through sandboxing, EmDash eliminates the need for a central, gatekept marketplace. Plugin authors can use any license (e.g., proprietary, MIT, GPL) and can distribute their plugins directly, without being forced into a marketplace that requires giving away the code for free.

Summary Verdict

Choose WordPress if: You need a battle-tested, mature ecosystem with an enormous library of existing plugins and themes, and you are comfortable managing the inherent security risks and server infrastructure. It remains a powerful choice for millions of sites.
Choose EmDash if: You are starting a new project and prioritize security (especially for multi-tenant or client sites), serverless scaling (cost-effective, zero idle compute), modern development (TypeScript, Astro), and want to future-proof your content for AI agents and new payment models. It is a radical rethinking of the CMS for dflare's official channels for a real, usable project.