EmDash CMS vs Webiny: Which One Should You Choose?

EmDash CMS vs Webiny: Which One Should You Choose?

Webiny and EmDash are both open-source, self-hosted, TypeScript-based CMS platforms with no per-seat pricing traps — but they take genuinely different infrastructure approaches. Webiny is built entirely around AWS serverless (Lambda, DynamoDB, S3), scaling automatically and billing per request. EmDash runs on more conventional server infrastructure. This comparison is largely about whether serverless architecture specifically is something you want or need.

Table of Contents
  1. Quick Answer
  2. Fully Serverless, AWS-Native
  3. Pricing
  4. Multi-Tenancy: Built In vs. Not a Core Feature
  5. Website Builder Plus Headless API
  6. AI and MCP Support
  7. Plugin and Extension Security
  8. Where Webiny Pulls Ahead
  9. Where EmDash Pulls Ahead
  10. Frequently Asked Questions
  11. Do I need to already use AWS to use Webiny?
  12. Is serverless architecture actually cheaper than EmDash's conventional hosting?
  13. Does EmDash have multi-tenancy like Webiny's Business tier?
  14. Which platform is easier to get started with for a small team?
  15. The Bottom Line
  16. Sources

Quick Answer

Webiny is the stronger choice if you're already committed to AWS and want a CMS that scales automatically with serverless billing, particularly for traffic that spikes unpredictably. EmDash is the stronger choice if you want more conventional, predictable infrastructure that isn't tied to a specific cloud provider's serverless ecosystem.

Fully Serverless, AWS-Native

Webiny is open-source, self-hosted CMS platform on AWS serverless (Lambda, DynamoDB, S3) — a TypeScript framework with multi-tenancy, lifecycle hooks, GraphQL API, and AI-assisted development via MCP server, built for developers at large organizations.

That serverless-first architecture has a real, practical advantage: you pay per request rather than provisioning infrastructure ahead of traffic spikes — genuinely useful for a site with unpredictable or seasonal traffic (a Black Friday sale, a viral post) where a conventionally-hosted server would need to be sized for peak load year-round. EmDash runs on more traditional server infrastructure — simpler to reason about and not tied to AWS specifically, but without serverless's automatic scale-to-zero cost model during quiet periods.

Read also:

Pricing

Webiny's 2026 tiers: Community Edition (MIT license, free forever, includes headless CMS, website builder, and file manager), Business Edition (commercial, from $79/month, adds RBAC, multi-tenancy, publishing workflows), and Enterprise (custom, adds SSO, audit logs, managed hosting). Notably, every tier — including free — includes unlimited content entries, pages, assets, API calls, roles, and workflows, with no per-seat pricing and no API metering trap. EmDash follows a similar philosophy at its free, self-hosted tier — no seat fees, no artificial usage caps — though EmDash doesn't have a directly equivalent $79/month mid-tier with Webiny's specific RBAC/multi-tenancy feature set.

Multi-Tenancy: Built In vs. Not a Core Feature

Webiny's Business and Enterprise tiers include genuine multi-tenancy — running multiple isolated sites or clients from one Webiny deployment, a real advantage for agencies or platforms managing many properties. EmDash doesn't currently offer built-in multi-tenancy; each EmDash deployment is more naturally scoped to a single site, similar to the limitation we've noted against other multi-tenant-capable platforms in this series.

Website Builder Plus Headless API

Webiny includes both a headless CMS with a GraphQL API and a visual drag-and-drop Website Builder with a Next.js SDK, letting you render pages through your own front end while still giving less technical team members a page-building interface. EmDash doesn't have an equivalent built-in visual page builder — page composition happens through the Astro codebase, a developer task rather than something available directly in the admin.

AI and MCP Support

Both platforms have adopted Model Context Protocol support for AI-assisted development — Webiny ships MCP server integration as part of its core offering, and EmDash similarly includes a built-in MCP server for programmatic, AI-native content management. This is one of the more evenly matched areas between the two platforms.

Plugin and Extension Security

Webiny's extensibility runs through its lifecycle hooks and plugin system within its serverless AWS architecture, with access control managed through its RBAC system at the Business tier and above. EmDash's plugins run in sandboxed, isolated environments with explicit, granted permissions by default at every tier — a stricter baseline that doesn't require upgrading to a paid tier to get meaningful access control on installed extensions.

Where Webiny Pulls Ahead

  • Genuine serverless architecture with automatic scaling and pay-per-request billing on AWS.
  • Built-in multi-tenancy for agencies or platforms managing multiple client sites from one deployment.
  • A visual drag-and-drop Website Builder alongside the headless API.
  • Unlimited entries, pages, and API calls with no metering, even on the free Community Edition.

Where EmDash Pulls Ahead

  • Not tied to a specific cloud provider's serverless ecosystem — deployable on any conventional hosting.
  • Sandboxed, permission-scoped plugin security included at every tier, not gated behind a paid RBAC upgrade.
  • Simpler infrastructure model for teams that don't need — or want to manage — serverless-specific architecture.
  • A built-in MCP server for AI-native content management as a standard, unconditional feature.

Frequently Asked Questions

Do I need to already use AWS to use Webiny?

Effectively yes — Webiny's architecture is built specifically around AWS serverless services (Lambda, DynamoDB, S3). If your infrastructure is on a different cloud provider or you prefer conventional hosting, that's a real friction point Webiny doesn't have a good answer for.

Is serverless architecture actually cheaper than EmDash's conventional hosting?

It depends heavily on your traffic pattern. For spiky, unpredictable traffic, serverless's pay-per-request model can be genuinely cheaper than provisioning a server for peak load. For steady, predictable traffic, conventional hosting (what EmDash uses) is often more cost-effective and easier to budget for.

Does EmDash have multi-tenancy like Webiny's Business tier?

Not currently — EmDash deployments are scoped to a single site. Managing multiple client properties means separate EmDash installations, unlike Webiny's built-in multi-tenant option at its paid tiers.

Which platform is easier to get started with for a small team?

EmDash's more conventional infrastructure model has a shorter on-ramp if your team doesn't already have AWS/serverless expertise. Webiny's free Community Edition is equally accessible feature-wise, but assumes comfort with AWS deployment specifically.

The Bottom Line

If you're building on AWS and want genuine serverless scaling, multi-tenancy, or a built-in visual page builder alongside your headless API, Webiny is a strong, thoughtfully priced option. If you'd rather avoid a cloud-provider-specific architecture and want sandboxed plugin security included at every tier without a paid upgrade, EmDash is the more portable choice. See how it compares to another open-source, self-hosted platform in Strapi for a related comparison.

Sources

Share

Comments

Write a comment

Related Articles

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

July 16, 2026

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

July 16, 2026

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

July 16, 2026

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

TL;DR — A custom session-cookie login flow appeared to succeed on localhost (the OTP verified, the response looked fine) but every subsequent request to a login-gated page treated the visitor as logged out. Identical code worked fine on the live HTTPS site. The cookie's Secure attribute was hardcoded to true — and per the cookie spec, browsers never store or send a Secure cookie over a plain, non-HTTPS connection.

Table of Contents
  1. Diagnostic
  2. Root cause
  3. Fix
  4. Lessons learned

Diagnostic

Check the actual Set-Cookie response header and the browser's own cookie storage panel — on localhost over http://, the cookie is sent by the server but never actually stored by the browser.

Root cause

// before -- assumes the app is always served over HTTPS
setCookie("session", token, { secure: true, httpOnly: true });
emdashkits.com

A cookie config that quietly assumes "we're always on HTTPS" breaks the instant you test over plain HTTP, which local dev servers commonly are.

Read also:

Fix

// after -- derive secure from the actual request protocol
const isHttps = request.url.startsWith("https://");
setCookie("session", token, { secure: isHttps, httpOnly: true });
emdashkits.com

Lessons learned

  • Any Secure-flagged cookie needs to key off the real request scheme, not an assumption baked in once at cookie-creation time.
  • "Works in production, silently fails in local dev" is a strong signal to check cookie flags before anything else in an auth flow.
  • Check other cookies in the same codebase for the same hardcoded assumption — if one cookie has this bug, sibling cookies set the same way are worth auditing too.
Share
Previous Article

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

Comments

Write a comment

Related Articles

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

July 16, 2026

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

July 16, 2026

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

Uploaded Images Disappear After Every Deploy on Shared Hosting (and Other Reverse-Proxy Gotchas)

July 16, 2026

Uploaded Images Disappear After Every Deploy on Shared Hosting (and Other Reverse-Proxy Gotchas)

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

TL;DR — GA4's gtag.js snippet was installed correctly, the page loaded with no visible JavaScript error, and GA4's real-time report still showed zero activity. The CMS's default Content-Security-Policy had no allowance for analytics domains and no config option to add one — so every request to Google's tracking endpoints was blocked at the browser level before it could fail loudly.

Table of Contents
  1. Diagnostic
  2. Root cause
  3. Lessons learned

Diagnostic

Check the browser's dedicated CSP violation reporting, not the regular console error list — CSP blocks are reported through their own channel, not thrown as normal script errors, so "no console errors" doesn't mean nothing was blocked.

Root cause

The CSP's script-src and connect-src directives had no entry for googletagmanager.com or google-analytics.com, and the CMS exposed no configuration surface to add one — the only way in was patching the CSP directives directly.

// patch-package: add analytics domains to the existing CSP directives
scriptSrc.push("https://www.googletagmanager.com");
connectSrc.push("https://www.google-analytics.com", "https://www.googletagmanager.com");
emdashkits.com
Read also:

Lessons learned

  • "No console errors" is not proof nothing was blocked — CSP violations live in their own reporting surface and are easy to miss if you're only scanning for red error text.
  • Before adding any third-party script tag to a site with a CSP already in place, check the CSP's directives first rather than assuming a silently-empty analytics dashboard means a snippet-installation mistake.
Share
Previous Article

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

Next Article

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

Comments

Write a comment

Related Articles

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

July 16, 2026

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

July 16, 2026

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

Uploaded Images Disappear After Every Deploy on Shared Hosting (and Other Reverse-Proxy Gotchas)

July 16, 2026

Uploaded Images Disappear After Every Deploy on Shared Hosting (and Other Reverse-Proxy Gotchas)