{"id":98008,"date":"2026-10-04T19:50:00","date_gmt":"2026-10-04T23:50:00","guid":{"rendered":"https:\/\/overcentral.com\/en\/?p=98008"},"modified":"2026-09-29T07:52:42","modified_gmt":"2026-09-29T11:52:42","slug":"emdash-self-hosting-plugin-sandbox-98008","status":"publish","type":"post","link":"https:\/\/overcentral.com\/en\/emdash-self-hosting-plugin-sandbox-98008\/","title":{"rendered":"The Dark Side of EmDash: Why Self-Hosting Means Losing Its Killer Feature"},"content":{"rendered":"

Everyone says the same thing about EmDash<\/a>: it’s open source, MIT-licensed, and you can run it anywhere \u2014 your own server, AWS, a Raspberry Pi. “Not locked in.” That’s the pitch. You hear it from Cloudflare’s own blog, from early adopters, from every Hacker News comment that wants to sound reasonable.<\/p>\n

They’re technically right. The code is on GitHub. You can npm create emdash-latest<\/code>codecodecodecodecode and deploy to any Node.js host. But here’s what nobody tells you in those glowing first impressions: the one feature that justifies EmDash’s existence \u2014 the plugin sandbox \u2014 vanishes the moment you leave Cloudflare’s runtime. Self-hosting EmDash is like buying a bulletproof car and removing the armor before you drive it.<\/p>\n

Let’s be specific about what you lose.<\/p>\n

The Plugin Sandbox Is Not Optional \u2014 It’s the Product<\/h2>\n

Cloudflare<\/a> built EmDash to solve a single, well-documented problem. 96% of all WordPress security vulnerabilities come from plugins. In 2025 alone, researchers disclosed 11,334 new WordPress vulnerabilities \u2014 a 42% increase from the year before. Nearly half were exploitable without any authentication. The root cause isn’t bad plugin code; it’s the architecture. Every WordPress plugin runs in the same process as the core, with full access to the database, file system, and user sessions. Install a contact form plugin with a bug, and an attacker can read your entire database.<\/p>\n

EmDash’s answer: every plugin runs in its own V8 isolate, a lightweight sandboxed environment that cannot touch anything unless a capability manifest explicitly grants it. A plugin that declares read content<\/code>codecodecodecodecode and send email<\/code>codecodecodecodecode can literally do nothing else \u2014 no database queries, no file system access, no unrestricted network calls. This isn’t policy; it’s architectural enforcement via dynamic workers.<\/p>\n

That’s the killer feature. That’s the reason to switch from WordPress.<\/p>\n

Now read the fine print.<\/p>\n

Self-Hosted EmDash: No Sandbox, No Isolation<\/h3>\n

The EmDash documentation is honest about this. When you<\/a> self-host on a regular Node.js server, plugins run in-process<\/strong> \u2014 the same model WordPress uses. No V8 isolate, no capability manifest enforcement, no sandbox. The plugin has full access to your database, your file system, your user data. Exactly the problem EmDash was supposed to fix.<\/p>\n

Cloudflare’s lead engineer Matt Cain confirmed this in a podcast interview: “For the kind of plugins that very often end up having the biggest blast area in taking down your entire site, this does solve the vast majority of those kind of problems.” But he was talking about the sandboxed environment that only runs on Cloudflare’s runtime.<\/p>\n

Even on Cloudflare’s free tier, plugins run in “in-process mode” \u2014 no real isolation. The sandbox only activates when you’re on the Workers Paid Plan, which starts at $5\/month and requires dynamic workers. Without that, you’re running a brand-new CMS with zero plugins and no security advantage over WordPress.<\/p>\n

So the common advice \u2014 “self-host to avoid vendor lock-in” \u2014 ignores a critical trade-off: you’re trading Cloudflare lock-in for a fundamentally less secure product.<\/p>\n

The Architecture That Makes the Sandbox Possible Is Proprietary<\/h2>\n

Dynamic workers are not a standard Node.js feature. They’re a Cloudflare-specific product that runs on V8 isolates across Cloudflare’s 300+ data centers. The isolation model uses Linux namespaces, seccomp filters, and hardware memory protection keys \u2014 none of which exist in a typical Node.js deployment.<\/p>\n

When you self-host, you get none of that. The code that makes the sandbox work is open source, but the runtime that enforces it is not. Cloudflare’s own blog post admits: “Plugins run in their own isolated container called a dynamic worker.” That container is a Cloudflare Workers feature, not something you can replicate on a $5 VPS.<\/p>\n

One widely upvoted Hacker News comment put it bluntly: “Open source, but architecturally locked in.” WordPress runs on any server with PHP and MySQL; you can switch hosting providers in an afternoon. EmDash’s data is portable \u2014 D1 is SQLite-based, R2 is S3-compatible \u2014 but the security model isn’t. The feature that justifies EmDash’s existence requires Cloudflare’s paid infrastructure.<\/p>\n

What You Actually Get on a Self-Hosted Instance<\/h3>\n

Let’s walk through what a self-hosted EmDash installation looks like today.<\/p>\n