Building EmDash Plugins: Why Sandboxed TypeScript Beats WordPress PHP Every Time
When Cloudflare launched EmDash on 1st April 2026, the headline feature for most people was the idea of a "WordPress successor." But for developers like us at Forty Miles West, the most exciting part was something deeper: the plugin architecture. EmDash has completely rethought how CMS plugins should work, and after digging into the documentation and building our first EmDash website, we believe this approach could change the game for web development agencies everywhere.
If you have spent any time building or maintaining WordPress plugins, you will know the frustration. Every plugin shares the same PHP process, has full access to the database and filesystem, and can interfere with any other plugin on the site. It is a trust-based system with no guardrails, and it is the single biggest source of security vulnerabilities in the WordPress ecosystem. In 2025, Patchstack reported over 11,300 new plugin vulnerabilities, with 91% of all WordPress security issues originating from plugins.
EmDash takes a fundamentally different approach, and it is one that every developer should understand.
The Capability Manifest: Permissions Done Properly
Every EmDash plugin starts with a manifest. This is not just metadata like a WordPress plugin header. It is a security contract. The manifest declares exactly what capabilities the plugin needs, and the plugin physically cannot do anything outside those declarations.
Think of it like an OAuth permissions screen. When you install a WordPress plugin, you are handing over the keys to the entire house. When you install an EmDash plugin, you see a clear list of what it wants to do: read content, send emails, make network requests to specific domains. If a plugin with 50,000 lines of code only declares read:content and email:send, it literally cannot access the database directly, modify other plugins, or make any network request. The runtime enforces this at the isolate level.
The available capabilities include reading and writing content, sending emails, making network requests to declared hostnames, accessing key-value storage, and interacting with media. Each one is opt-in. You do not get anything by default. This is a massive improvement over WordPress, where a plugin gets everything by default and there is no way to restrict it.
Dynamic Workers: Isolation That Actually Works
The technical foundation for all of this is Cloudflare's Dynamic Workers, which use V8 isolates to sandbox each plugin. If you are familiar with how Cloudflare Workers operate, this will make sense immediately. Each plugin runs in its own lightweight isolate with its own memory space. There is no shared state between plugins, no way for one plugin to read another plugin's data, and no way to escape the sandbox.
This is not the same as running plugins in separate Docker containers, which would be heavy and slow. V8 isolates spin up in milliseconds, use minimal memory, and are designed for exactly this kind of multi-tenant isolation. Cloudflare has been running billions of these in production for years. The technology is proven.
For self-hosted deployments on Node.js, the sandboxing still works but without the full V8 isolate benefits. The capability manifest is still enforced, so you still get the permission model, but the isolation is not quite as strong as on Cloudflare Workers. For most use cases, this is still a massive step up from WordPress.
How EmDash Plugins Are Built
Building an EmDash plugin looks natural if you are comfortable with TypeScript. You start with a definePlugin() function that takes a configuration object. This is where you declare your name, version, capabilities, and lifecycle hooks.
The lifecycle hooks are where the real power lives. EmDash provides hooks like onContentPublish, onContentUpdate, onContentDelete, onMediaUpload, and onUserLogin, among others. Each hook receives a context object with the relevant data and only the capabilities your manifest declared.
For example, a content notification plugin might declare read:content and email:send capabilities, then use the onContentPublish hook to send an email whenever a new article goes live. The plugin never touches the database directly. It receives the published content through the hook context and uses the email capability to send the notification. Clean, predictable, and secure.
A webhook integration plugin might declare read:content and network:fetch with a specific allowed hostname, then use the same onContentPublish hook to POST the content to an external service. The plugin cannot reach any domain other than the one declared in its manifest. Try doing that with a WordPress plugin.
Why This Excites Us as an Agency
At Forty Miles West, we have already been developing WordPress plugins using AI-assisted workflows. We use agentic coding tools to scaffold, build, and test custom functionality for our clients. It works well, but WordPress plugin development still comes with baggage: you are always thinking about conflicts with other plugins, worrying about security implications, and testing in an environment where any plugin can interfere with any other.
EmDash's sandboxed architecture removes most of that overhead. Because each plugin is isolated and capability-restricted, you spend far less time worrying about side effects and conflicts. That makes it a perfect fit for AI-driven development. An AI agent can generate a plugin, and you can be confident that it can only do what its manifest declares. The blast radius of any mistake is contained by design.
We have not built EmDash plugins yet, but having already built a full website with EmDash in around five hours, we are genuinely excited about what the plugin ecosystem will look like. Our research into the architecture tells us that the combination of TypeScript, sandboxed isolation, and agentic workflows is going to make plugin development dramatically faster and safer than anything we have experienced with WordPress.
Testing and Debugging
EmDash provides a local development server that simulates the sandbox environment. You can test your plugin locally with the same capability restrictions that will apply in production. This is a huge quality-of-life improvement over WordPress plugin development, where testing often means spinning up a full WordPress installation and hoping your plugin does not conflict with the 30 others on the site.
The EmDash CLI includes commands for scaffolding new plugins, running the test environment, and deploying to a live instance. Debugging output is structured and scoped to your plugin, so you are not sifting through a shared PHP error log trying to figure out which plugin threw the warning.
Licensing Freedom
Here is something that WordPress plugin developers will appreciate. EmDash is MIT-licensed, which means plugins built for EmDash can use any license you choose. You can build commercial plugins, open-source plugins, or anything in between. There is no GPL inheritance to worry about, no licence compatibility debates, and no restrictions on how you distribute your work.
For agencies like Forty Miles West, this means we can build bespoke plugins for clients without worrying about licensing constraints. We can create proprietary integrations, package them for resale, or open-source them for the community. The choice is ours.
Why This Matters for the WordPress Ecosystem
WordPress plugin security is so problematic that WordPress.org manually reviews every submitted plugin, creating a queue of over 800 plugins with wait times of two weeks or more. This centralised gatekeeping creates a bottleneck that slows innovation and locks developers into the WordPress.org marketplace.
EmDash's sandbox model changes this dynamic entirely. Because plugins are isolated and capability-restricted, platforms can trust plugins without centralised review. This breaks the marketplace lock-in cycle and opens the door for a more distributed, developer-friendly ecosystem.
It also means that AI agents can safely generate and deploy plugins. If an AI-generated plugin can only do what its manifest declares, the risk of unintended side effects drops dramatically. This is where agentic workflows really start to shine, and it is exactly the direction we are heading at Forty Miles West.
Looking Ahead
EmDash is at v0.1.0. The plugin API will evolve, new capabilities will be added, and the ecosystem will grow. But the core principles of sandboxed isolation, capability-based permissions, and TypeScript-native development are not going to change. These are the foundations, and they are good ones.
Having already built our first EmDash site and seen how productive the developer experience is, we are looking forward to building our first plugins next. The combination of TypeScript, isolated sandboxing, and AI-assisted development feels like the natural next step from what we are already doing with WordPress. We expect the transition to be smooth and the results to be even better.
For developers who have been frustrated with the WordPress plugin model, EmDash offers a genuinely better way to build. For agencies looking to ship custom functionality faster and more securely, it is worth serious attention. And for the WordPress ecosystem as a whole, this kind of competition can only be a good thing.
Want Custom EmDash Plugins Built for Your Business?
Forty Miles West is exploring EmDash plugin development and helping businesses understand what this new platform can do. Whether you need a custom integration, want to migrate your WordPress site to EmDash, or are curious about building your next project on a more secure, modern CMS, we would love to chat. Get a free quote and let us build something brilliant together.