Why people are taking the claim seriously
The launch framing on April 1, 2026 is specific: EmDash plugins declare capabilities in advance and run in isolated sandboxes rather than inheriting broad access to the application by default. That is not vague “security” language. It is a very concrete answer to the historical WordPress plugin problem.
What is concrete today
- Manifest-style capabilities are part of the public story.
- Hooks, settings, admin pages, widgets, blocks, KV usage, and routes are visible extension surfaces.
- The Cloudflare runtime is part of how the isolation story is made credible.
- The ecosystem is still early enough that architecture is clearer than inventory.
What is not proven yet
EmDash has not yet proven broad third-party plugin depth, long operational track records, or the full range of extension patterns that a mature CMS eventually accumulates. That is why this page should help you evaluate the model, not oversell the size of the directory.
How to evaluate EmDash plugins responsibly
Start with a hard list of the behaviors your current stack truly needs. Then ask four questions. Do the visible extension points cover those behaviors. Does the capability model materially reduce your risk. Are you comfortable with how much of that story depends on Cloudflare. And if you are migrating from WordPress, how much of your current plugin layer should be rebuilt rather than ported one-for-one.
If you are planning to build your own extension, continue to Creating Plugins. If you are still deciding whether the runtime model is acceptable, read Hosting. If your real decision is migration, go next to Migration.