EmDash CMS launched as a spiritual successor to WordPress, but its security settings are far from complete. In the playground version 0.1.0, the security settings page displays \u201cNot available yet\u201d for items like self-signup domains, API token management, and user role granularity. The core security pitch\u2014sandboxed plugins via dynamic workers\u2014works only on Cloudflare\u2019s paid plan. Self-host the CMS on a Node.js server, and that isolation disappears entirely. If you\u2019re evaluating EmDash for production, you need to know what\u2019s absent and how to patch the gaps yourself.<\/p>\n
EmDash runs on Cloudflare Workers<\/a>, D1 database, R2 storage, and KV. Each page view can hit four separate billing meters simultaneously. The paid plan starts at $5\/month with 10 million requests, but after that you pay $0.30 per additional million requests plus CPU time. There is no built-in spending cap. A DDoS attack of 10,000 IPs making one request per second<\/a> each can rack up 26 billable requests in a month\u2014potentially costing thousands. Cloudflare\u2019s own forum confirms: you cannot set a global request limit. Rate limiting via WAF rules is per-endpoint, not a global cap. A distributed bot attack from thousands of different IPs goes right through.<\/p>\n The headline feature\u2014plugins running in isolated V8 isolates\u2014requires Cloudflare\u2019s paid Workers plan. On the free tier, plugins run \u201cin-process\u201d with no sandbox. Self-host on your own hardware, and there is no sandbox support at all. You lose the one architectural advantage over WordPress. If you\u2019re not paying $5\/month, the security model collapses.<\/p>\n EmDash uses passkey authentication by default, eliminating passwords and brute-force vectors. But the passkey is bound to the device and browser. For developers running multiple local instances (common in agencies), the passkey system fails. The demo video showed a reviewer getting a \u201cPage Not Found\u201d error when the magic link fallback didn\u2019t work on Linux. Passkeys also cannot be shared across team members easily\u2014no role-based delegation for multi-user staging environments.<\/p>\n The security settings page in the playground is empty. There is no way to restrict admin access by IP address, no support for TOTP (time-based one-time passwords) beyond the passkey, and no audit log for failed login attempts. For any site with sensitive content, these are table-stakes features.<\/p>\n EmDash ships with administrator, editor, author, and contributor roles. You cannot create custom roles or assign granular permissions to specific content types. In WordPress, plugins like Members or User Role Editor solve this. In EmDash, you\u2019re stuck with the four defaults\u2014no way to give a contributor read-only access to media or restrict an editor from publishing.<\/p>\nPlugin Sandbox Only on Cloudflare Paid Plan<\/h3>\n
Passkey Authentication but No Fallback for Localhost<\/h3>\n
No IP-Based Access Controls or Two-Factor Authentication<\/h3>\n
No Granular User Roles Beyond the Default<\/h3>\n
How to Compensate for EmDash\u2019s Security Gaps<\/h2>\n
Use Cloudflare\u2019s WAF and Rate Limiting<\/h3>\n