The default hosting story
Public material places EmDash squarely in a Cloudflare-shaped architecture: Workers for execution, D1 for relational data, R2 for stored assets, and supporting runtime services like KV and Durable Objects. That matters because the plugin trust model is easier to believe when it sits on top of explicit isolation primitives.
Where Node still fits
Node matters for softer onboarding. If your team wants to test EmDash without committing to Cloudflare on day one, the Node path lowers the learning curve. It is useful for local prototyping and for separating “do we like the CMS?” from “do we want the full Cloudflare operating model?”.
But Node is not the main strategic story. If you are evaluating EmDash because it feels like a post-WordPress runtime rethink, Cloudflare is the center of gravity.
The decision tree most teams should use
- Choose Cloudflare-first if plugin isolation, scale-to-zero economics, or Cloudflare platform alignment are core reasons you are here.
- Choose Node-first if you mainly want to prototype the editorial model, frontend shape, and migration effort before learning new infrastructure.
- Pause adoption if your team needs conventional hosting familiarity more than new runtime properties.
What to verify before committing
- How your expected content volume and media usage map to D1 and R2 assumptions.
- Whether planned plugins or extensions rely on Cloudflare-only capabilities.
- How much operational comfort your team already has with Workers, storage services, and Cloudflare observability.
- Whether your migration plan changes if the final production target is Cloudflare rather than traditional hosting.