You’d think the first thing to do with a new CMS is log into the admin panel. With EmDash, that instinct is wrong. The dashboard is clean and familiar—it looks like WordPress after a minimalist makeover—but it hides the architecture that makes this CMS different. The real starting point isn’t a page builder or a plugin store. It’s a set of resources that explain why the system works the way it does.
Cloudflare launched EmDash in April 2026 as a spiritual successor to WordPress. It’s built on TypeScript, Astro, and Cloudflare Workers. Plugins run in sandboxed V8 isolates. Content is stored as structured JSON. And the admin interface is deliberately WordPress-like to lower the learning curve. But that familiarity is a trap. If you treat EmDash like WordPress, you’ll miss the security model, the serverless architecture, and the AI-native tools that justify its existence.
The most valuable EmDash resource is not a tutorial or a video. It’s a conversation between developers who are figuring out the same thing you are.
These five resources will save you time, prevent expensive mistakes, and give you a foundation that most tutorials skip.
1. The EmDash Playground (No Install Required)
The playground spins up a full EmDash instance in your browser. It lasts one hour. You can break everything, experiment with content types, and test the plugin sandbox without touching your own infrastructure.
Most beginners click around the dashboard and conclude it’s just a WordPress clone. The playground proves otherwise. Create a custom content type. Add fields. Publish a post. Then open the Network tab in your browser’s dev tools and watch how the V8 isolates handle each request. You’ll see that pages render in milliseconds and the admin operations are serverless function calls, not PHP scripts.
What to try first: Create a new content type called “Projects.” Give it a text field for client name, a date field for year, and an image field for the thumbnail. Then check the database—it’s D1 (SQLite on Cloudflare) and the schema is stored as code, not just in tables. This is the structured-content approach that WordPress lacks natively.
2. The Official GitHub Repository
The repo is MIT-licensed and contains the entire CMS source code. It’s also where the documentation lives—the README, the plugin development guide, and the architecture overview.
Skipping the README is a common mistake. The repo’s docs explain how plugins declare capabilities in a manifest file, how themes are built with Astro components, and how the MCP server works. Without this context, you’ll treat EmDash like a black box and miss the security model that makes it compelling.
Why it matters for beginners: The repo contains a skills/code directory. These are structured files that tell AI agents how to operate the CMS. If you’re using Claude or Cursor, you can point the agent at these skills and ask it to build a plugin or migrate a theme. This is the feature that WordPress co-founder Matt Mullenweg called “a brilliant strategy” in his review.
Deep tip: Look at the packages/plugin-sandboxcode directory. It shows how dynamic workers are configured—the exact permission manifests, the V8 isolate setup, and the hook system. Experienced developers will notice that the sandbox only works fully on Cloudflare’s paid Workers plan ($5/month). Self-hosted Node.js instances run plugins in-process without isolation. This is a critical nuance that marketing materials gloss over.
3. The Cloudflare Blog Post: “EmDash: The Spiritual Successor to WordPress”
This post is the canonical explainer. It covers why Cloudflare built EmDash, how the plugin sandbox works, and what the AI-native features are. It also includes the technical detail that 96% of WordPress security vulnerabilities come from plugins—a stat that frames the entire project.
Read it before you touch any code. The blog post explains the “plugin paradox” that EmDash solves: WordPress plugins run in the same process as the core, giving every plugin full database access. EmDash runs each plugin in its own V8 isolate with a capability manifest. The post includes code examples showing how a plugin declares read:contentcode and email:sendcode and nothing else.
What beginners miss: The blog mentions that EmDash was built in about two months by a single engineer (Matt Cain) using AI coding agents. This is relevant because it means the codebase is young and still evolving. Edge cases are undocumented. Bugs exist. The playground and GitHub issues are your safety net.
4. The “Dynamic Workers” Deep Dive (Cloudflare Developers YouTube)
YouTube channel: Cloudflare Developers – “Building Secure Apps with Dynamic Workers”
Dynamic workers are the engine behind EmDash’s plugin sandbox. They let you run untrusted code in a secure, isolated environment that spins up in milliseconds and disappears when done. This is not just a CMS feature—it’s a general-purpose Cloudflare tool for AI-generated code execution.
The video by Craig Dennis (a Cloudflare developer advocate) demonstrates a use case: an LLM generates a report from sensitive data without ever seeing the raw data. The LLM writes the code, passes it to a dynamic worker, and the worker returns only the result. This is the same architecture EmDash uses for plugins.
Why it matters: If you plan to build plugins for EmDash, understanding dynamic workers is non-negotiable. The video shows how to define permissions, how to pass context, and how to handle errors. It also reveals that dynamic workers are still in beta and have limits—no filesystem access by default, no direct database queries unless explicitly granted.
The experienced practitioner’s angle: Use dynamic workers outside EmDash. If you’re building an AI agent that needs to execute user-submitted code (like a code playground or a report generator), dynamic workers are a safer alternative to Docker containers. They start 100x faster and use 10x less memory. This is a pattern few beginners consider.
5. The GitHub Discussions and Issues Board
github.com/m-dash-cms/m-dash/discussions
The official documentation is thin. The real knowledge lives in GitHub discussions. Early adopters are asking—and answering—questions about deployment, plugin development, and migration from WordPress.
This is where you’ll find practical workarounds. For example, one discussion thread explains how to set up custom email sending with SMTP because the built-in email system uses Cloudflare’s Workers Mail API, which has limitations. Another thread covers how to migrate a WooCommerce store: you can import products as a custom content type, but you lose all the e-commerce logic. The thread includes a manual script for recreating cart functionality.
What to bookmark: The “Plugins” discussion category. As of launch, EmDash has zero third-party plugins in a marketplace. Developers are building their own and sharing patterns here. If you need a specific feature—a contact form with file uploads, a newsletter signup, a caching layer—the discussions are ahead of the docs.
The counterintuitive truth again: The most valuable EmDash resource is not a tutorial or a video. It’s a conversation between developers who are figuring out the same thing you are. The playground lets you break things. The GitHub repo shows you the internals. The blog post frames the problem. The dynamic worker video explains the core technology. But the discussions teach you what works in practice, today.
Start with the playground. Then read the blog post. Then open the repo. Watch the dynamic worker video. And when you hit a wall—you will—the discussions are waiting.
- What is the EmDash Playground?The EmDash Playground spins up a full EmDash instance in your browser for one hour, allowing you to experiment without touching your own infrastructure.
- Where can I find the EmDash source code?The official GitHub repository at github.com/m-dash-cms/m-dash contains the entire CMS source code under an MIT license.
- Why are GitHub discussions important for EmDash beginners?GitHub discussions offer practical workarounds and patterns from early adopters, often ahead of the official documentation.
