Cloudflare wants you to believe EmDash is free, open source, and portable. The code is MIT licensed. You can fork it, run it locally, even deploy it to a bare Node.js server. But the headline feature — sandboxed plugins — requires Cloudflare’s paid infrastructure to function. That’s not an accident. That’s architectural lock-in dressed in open-source clothing.
The question isn’t whether EmDash can be ported. It’s whether the thing that makes it worth using survives the move.
The code is portable. The features are not.
What Actually Locks You In
EmDash ties you to Cloudflare across three distinct layers: compute, database, and storage. Each layer has a portability story. None of them are equally portable.
Compute: The Plugin Sandbox Dies Outside Cloudflare
This is the painful one. EmDash’s entire security pitch rests on dynamic workers — Cloudflare’s proprietary V8 isolate runtime that spins up in milliseconds, executes plugin code, and vanishes. Every plugin declares its capabilities in a manifest. The runtime enforces those boundaries at the hardware level using Linux namespaces, seccomp filters, and memory protection keys.
Run EmDash on a standard Node.js server. Plugins execute in-process. No sandbox. No isolation. A compromised plugin can read your entire database, modify files, exfiltrate data. The feature that justifies EmDash’s existence simply does not exist on self-hosted infrastructure.
The Cloudflare Workers Paid Plan costs $5/month. That’s cheap. But the dependency is structural. You cannot replicate the V8 isolate sandbox on any other cloud provider. AWS Lambda, Google Cloud Functions, Azure Functions — none of them offer a runtime that can dynamically create and destroy sandboxed execution environments with sub-millisecond cold starts. EmDash’s plugin architecture is a Cloudflare-specific capability.
Database: D1 Is SQLite, But It’s Cloudflare’s SQLite
EmDash uses D1 by default, Cloudflare’s serverless SQLite database. D1 is built on top of SQLite, which is portable in theory. You can export your data. But D1 has features that standard SQLite doesn’t — global replication, HTTP-based query API, integration with Workers. Migrate away from Cloudflare, and you’re running raw SQLite on your own server. No replication. No global read distribution. Your site’s performance profile changes completely.
The migration path exists. D1 exports to standard SQLite format. But the operational model you designed around — zero-effort global reads — disappears.
Storage: R2 Is S3-Compatible, but the Integration Isn’t
R2 is Cloudflare’s object storage. It uses the S3 API. AWS S3, Backblaze B2, and MinIO all speak S3. In theory, you can point EmDash at any S3-compatible provider.
In practice, EmDash’s media handling assumes R2’s specific behavior — zero egress fees, integration with Cloudflare’s image optimization pipeline, Workers-based access patterns. Switch to AWS S3, and you’re paying egress. Switch to Backblaze, and you lose the tight Workers integration. The code still works. The economics and performance change.
The Strongest Counterargument — and Why It Falls Apart
The most common defense of EmDash’s portability goes like this: “The data is portable. D1 is SQLite. R2 is S3. You can move your content anywhere. The code is MIT licensed. You’re not locked into anything except your own preferences.”
This sounds reasonable. It’s also incomplete.
Data portability and operational portability are different things. Yes, you can export your SQLite database and dump your R2 bucket into AWS S3. But EmDash’s value proposition isn’t just “store content.” It’s “store content securely, run plugins in isolation, and serve pages at the edge with zero cold starts.” Move off Cloudflare, and two of those three features disappear. You’re left with a basic Node.js CMS that has fewer plugins, less community support, and no security advantage over WordPress.
The lock-in isn’t about data. It’s about the runtime. Cloudflare owns the runtime that makes EmDash worth using. That’s not a bug — it’s the product.
The Billing Risk Nobody Is Talking About
Serverless billing is unpredictable. EmDash on Cloudflare uses Workers (per-request billing), D1 (per-row billing), R2 (per-operation billing), and KV (per-read/write billing). A single page view can hit four different billing meters simultaneously.
Traditional WordPress hosting: $20/month, flat rate, no surprises. EmDash on Cloudflare: $5/month base, but a traffic spike or bot attack can drive costs into the hundreds or thousands. Cloudflare does not offer a global spending cap. You can set CPU time limits per request. You can configure WAF rate limiting per IP. But a distributed attack from thousands of unique IPs bypasses per-IP limits. Your bill climbs. You have no kill switch.
WordPress hosts throttle or crash under load. Your bill stays the same. EmDash keeps running and charging.
What Leaving Actually Costs
Let’s be specific about the migration effort. You have:
- A D1 database with your content, user data, and plugin state
- R2 buckets with your media library
- Workers running your site’s frontend and plugin execution
- KV stores for sessions and plugin metadata
- Zero egress fees on R2 (you lose this immediately)
Moving to a standard Node.js server means:
- Export D1 to SQLite, configure a new database connection
- Migrate R2 files to S3-compatible storage (pay egress)
- Rewrite any plugin that depends on Workers-specific APIs
- Accept that plugins now run without sandbox isolation
- Set up your own caching and CDN (losing Cloudflare’s edge network)
This is a days-to-weeks engineering project for a small site. For a site with custom plugins, WooCommerce-like functionality, or complex content structures, it’s a rewrite.
The Real Comparison
WordPress runs on any server with PHP and MySQL. You can switch hosts in an afternoon. Your plugins, themes, and content move with you. The code is GPL, which has its own licensing friction, but the infrastructure is free.
EmDash’s code is MIT. The infrastructure is Cloudflare. The code is portable. The features are not.
That’s not necessarily a dealbreaker. Cloudflare is a reliable, well-funded company. Their infrastructure is excellent. But “open source” implies a certain kind of freedom. EmDash offers freedom from licensing restrictions — not freedom from vendor dependency.
What Would Real Portability Look Like?
A genuinely portable EmDash would need a standardized plugin sandbox runtime that works on any cloud provider or bare metal. That doesn’t exist today. Cloudflare’s dynamic workers are proprietary. No other provider offers an equivalent.
The MIT license means you could build an alternative runtime. But that’s a massive engineering effort — likely larger than building EmDash itself. And it would defeat the purpose: Cloudflare built EmDash to drive adoption of Cloudflare infrastructure.
The Honest Bottom Line
EmDash is a smart product with a real security advantage over WordPress. But the advantage is tied to Cloudflare’s platform. If you adopt EmDash, you are choosing Cloudflare as your infrastructure partner. Not just for hosting, but for the runtime that powers your CMS’s core differentiator.
That’s fine if you trust Cloudflare and accept the dependency. It’s not fine if you want the portability that “open source” traditionally promises.
The strongest argument for EmDash is its architecture. The strongest argument against it is that the architecture locks you in. Both are true.
- What locks users into Cloudflare with EmDash?EmDash ties users to Cloudflare across three layers: compute (plugin sandbox), database (D1), and storage (R2). Each layer has portability limitations.
- Can EmDash's plugin sandbox run outside Cloudflare?No. The plugin sandbox requires Cloudflare's proprietary V8 isolate runtime, which is not available on other cloud providers or self-hosted servers.
- Is EmDash's database D1 portable?D1 exports to standard SQLite, but features like global replication and HTTP-based query API are lost, changing the operational model.
- Does EmDash's storage R2 work with other providers?R2 uses the S3 API, so other providers work in theory, but EmDash assumes R2's zero egress fees and tight Workers integration, affecting economics and performance.
