You’ve read the pitch. Cloudflare’s EmDash is the spiritual successor to WordPress. TypeScript, not PHP. Sandboxed plugins. Serverless by design. MIT licensed. Open source.<\/p>\n\n
That last part is doing a lot of heavy lifting.<\/p>\n\n
Open source code doesn’t mean portable infrastructure. And portable infrastructure doesn’t mean portable operations. The gap between those three things is where the real cost lives. Most early coverage of EmDash skips this entirely. They compare feature lists. They run the playground. They declare it promising or premature.<\/p>\n\n
The lock-in question is more subtle than “can I fork the repo.” You can. You absolutely can. The question is whether the thing you fork still works the way you need it to.<\/p>\n\n
This is EmDash’s headline feature. Every plugin runs in its own isolated container. It cannot touch your database, file system, or user sessions unless the capability manifest explicitly allows it. That’s the architectural fix for WordPress’s biggest vulnerability class.<\/p>\n\n
But here’s the non-obvious part: that sandbox only exists on Cloudflare’s runtime. Dynamic Workers are a Cloudflare-specific product. They run on Cloudflare’s infrastructure, orchestrated by Cloudflare’s control plane, billed through Cloudflare’s pricing model.<\/p>\n\n
Self-host EmDash on a Node.js server and plugins run in-process. No isolation. No security advantage over WordPress. The feature that justifies the entire project \u2014 the solution to 96% of WordPress vulnerabilities \u2014 requires you to be on Cloudflare’s paid plan.<\/p>\n\n
The code is MIT. The runtime that makes it valuable is proprietary.<\/p>\n\n
WordPress runs anywhere you can put PHP and MySQL. A $5 VPS. A Raspberry Pi. AWS, GCP, Azure, literally any shared host from 2004. That portability is not an accident. It’s the result of 24 years of compatibility engineering.<\/p>\n\n
EmDash runs on two runtimes: Cloudflare Workers and Node.js. Those are not equivalent.<\/p>\n\n
On Workers, you get the full feature set. D1 for database. R2 for storage. KV for sessions. Workers AI for inference. The entire Cloudflare ecosystem is available, and the CMS is designed to use it. The deployment tooling assumes Cloudflare. The CLI defaults to Cloudflare. The playground spins up on Cloudflare.<\/p>\n\n
On Node.js, you get SQLite and local storage. No sandboxed plugins. No edge deployment. No automatic CDN. No zero-egress storage. You are running a headless CMS with a local database and no plugin security model. The experience is fundamentally different.<\/p>\n\n
This is not a bug. It’s a design choice<\/a>. EmDash is built to demonstrate Cloudflare’s infrastructure. The Node.js option exists for development and evaluation, not for production parity.<\/p>\n\n WordPress uses MySQL or MariaDB. You can dump the database, move it to another host, and restore it. The SQL is standard. The schema is documented. Migration tools exist for every platform.<\/p>\n\n EmDash uses D1 on Cloudflare and SQLite everywhere else. D1 is built on SQLite, but it’s not portable SQLite. It’s a distributed SQLite implementation that runs across Cloudflare’s edge network. You cannot export a D1 database and import it into PostgreSQL, MySQL, or even vanilla SQLite without rewriting the storage layer.<\/p>\n\n The migration path out of EmDash is not “dump and restore.” It’s “extract and transform.” Every relationship, every content type definition, every field configuration \u2014 you write custom scripts for all of it.<\/p>\n\n The import tool works one direction. WordPress to EmDash. There is no EmDash to anywhere.<\/p>\n\n WordPress stores media files in a directory. EmDash on Cloudflare uses R2. R2 is S3-compatible, which sounds portable. It is, at the API level. But the migration is not API-compatible. You download objects from R2 and upload them to S3, or Google<\/a> Cloud Storage, or Backblaze. You rebuild the URL structure. You update every media reference in the database.<\/p>\n\n That’s a migration project, not a migration script.<\/p>\n\n This is where the lock-in becomes financially dangerous.<\/p>\n\n WordPress hosting is predictable. You pay a flat monthly rate. Traffic spikes might crash your server, but they don’t increase your bill. You know what you owe before the month starts.<\/p>\n\n EmDash on Cloudflare is serverless. You pay per request, per CPU millisecond, per database read, per storage operation. One page view can hit five different billing meters simultaneously. Workers, D1, R2, KV, and possibly Workers AI if you use moderation features.<\/p>\n\n The paid plan starts at $5\/month and includes 10 million requests. That sounds generous. It is, for a small blog. But the cost scales with traffic, and there is no spending cap. Cloudflare does not offer a kill switch. If your site gets hit by a botnet, your workers keep firing and your credit card keeps charging.<\/p>\n\nLayer Three: The Database<\/h3>
Layer Four: The Storage<\/h3>
wp-content\/uploads<\/code>codecodecodecode. You can rsync it, SCP it, mount it via NFS, or sync it to S3 with a plugin. The storage model is simple and portable.<\/p>\n\nLayer Five: The Billing Model<\/h2>