Everyone says the same thing about evaluating a new CMS: “Skip the demo. Install it locally. That’s the only way to really know if it works for you.” For WordPress, that advice made sense — a 5-minute install on any shared host, full access to the file system, real plugins to test. For EmDash, Cloudflare’s new open-source CMS, that advice is worse than wrong. It’s misleading.
The EmDash Playground at emdashcms.com isn’t a watered-down demo. It’s a live, full-stack instance running on Cloudflare’s actual production infrastructure — Workers, D1, R2, KV — all spinning up in your browser with zero setup. And it reveals something a local Node.js install cannot: the core architectural bet behind the entire project.
EmDash is not a standalone CMS you can fully evaluate offline. Its differentiating features — sandboxed plugins, serverless scaling, edge deployment — are Cloudflare infrastructure features.
What the Playground Actually Shows
Fire up the playground. You get a complete, working EmDash site — admin dashboard, front-end theme, content editor, the works. It lasts one hour. You can break anything. Nobody else sees it.
But here’s what the “install locally” crowd misses.
The playground runs on Cloudflare’s edge. Every page load, every admin click, every plugin sandbox invocation — that’s a real worker execution on real infrastructure. You experience the actual performance profile: sub-100ms cold starts, instant plugin isolation, passkey authentication against a live D1 database.
A local install with SQLite and Node.js gives you none of that. It runs plugins in-process, without sandboxing. It uses your laptop’s file system, not R2’s zero-egress storage. It simulates nothing about the actual deployment model.
The Architecture You Can’t Reproduce Locally
EmDash’s headline feature — sandboxed plugins via dynamic workers — requires Cloudflare’s V8 isolate runtime. The playground is the only free way to see this work in practice.
Here’s the specific test the playground enables that a local install cannot:
- Create a plugin that declares only
read contentcodecode andemail sendcodecode capabilities - Watch it fail to access anything else
- Observe the worker cold-start time (under 5ms)
That third point matters. A Docker container cold-start takes 2-5 seconds. A V8 isolate in a dynamic worker takes milliseconds. The playground demonstrates this gap with real latency numbers. Your local Node.js install simply runs the plugin in the same process — no isolation, no cold-start measurement, no security boundary to observe.
When the “Install Locally” Advice Fails
Three specific scenarios where the playground outperforms a local install for evaluation:
You’re evaluating for a client who needs predictable security. The playground’s plugin sandbox is the actual security model. A local install’s in-process mode is not. Testing locally gives you false confidence about what production looks like.
You’re comparing hosting costs. The playground uses real Cloudflare Workers billing meters. You can estimate actual per-request costs. A local Node.js server with SQLite tells you nothing about serverless pricing, and serverless pricing is the biggest surprise for WordPress migrants — no fixed $20/month host, but pay-per-millisecond compute.
You’re testing AI agent integration. EmDash ships with a built-in MCP server. The playground exposes this. You can point Claude or Cursor at it and say “create a new content type called ‘case study’ with fields for client name, industry, and results.” The agent interacts with the live CMS. A local install requires you to configure your own MCP endpoints and authentication.
The Honest Caveat: When Local Install Wins
The playground is ephemeral. One hour. No persistence. You cannot:
- Test long-running content workflows across days
- Benchmark database performance at scale (D1 vs SQLite vs Postgres)
- Evaluate the WordPress import tool with your actual site (the playground has sample data only)
- Measure real-world egress costs for media-heavy sites
For those, yes — install locally. npm create emdash@latestcodecode, pick a template, run bun devcodecode. You get a working CMS with SQLite and local file storage. But remember: plugins run in-process without sandboxing. The security model you’re evaluating is not the security model you’d deploy.
What the Playground Reveals That Nothing Else Does
The playground exposes one thing a local install actively hides: EmDash is not a standalone CMS you can fully evaluate offline. Its differentiating features — sandboxed plugins, serverless scaling, edge deployment — are Cloudflare infrastructure features. The MIT-licensed code is portable. The runtime is not.
That’s not a flaw. That’s the product. WordPress runs anywhere because its architecture is 24 years old and demands a server. EmDash runs at the edge because it was designed for Cloudflare’s network. The playground is honest about that dependency. A local install obscures it.
If you’re genuinely evaluating EmDash for production, do both. Start with the playground to see the sandbox in action and estimate real costs. Then install locally to test content migration and custom theme development. But skip the playground, and you miss the entire point of why EmDash exists.
Go to emdashcms.com. Click Playground. Break something. Learn what serverless CMS actually feels like.
- What does the EmDash Playground reveal that a local install cannot?The playground exposes EmDash's core architectural bet: sandboxed plugins via dynamic workers and edge performance. A local install hides these Cloudflare infrastructure features.
- Why is the 'install locally' advice misleading for EmDash?Local installs run plugins in-process without sandboxing and use SQLite, not real Cloudflare services. The playground provides the actual security model and performance profile.
- What specific test does the playground enable that a local install cannot?You can create a plugin with limited permissions and observe it fail to access restricted resources, plus measure worker cold-start times under 5ms.
