Feature Request: Multi-tenancy through dynamic bindings

[jpumfrey]

I am looking to manage multiple independent sites from a single EmDash installation/monorepo. Currently, EmDash appears focused on single-instance deployments. For devs managing dozens of client sites/properties, maintaining separate deployments for each site increases DevOps overhead and complicates global updates.

I would like to see native multi-tenancy support (similar to Payload CMS), allowing a single EmDash instance to:

• Identify tenants via domain name or request headers.

• Isolate data using either a shared database with tenantID scoping or separate D1 databases per tenant.

• Shared Codebase: Update the core CMS logic in one place (the monorepo/Worker) and have it reflect across all tenant sites immediately.

• Tenant-specific Configuration: Allow different themes or plugin settings based on the active tenant.

[MattieTK]

For some context: we had some thoughts of doing this with Durable Objects, which effectively provide a database per object (and each object would represent its own tenant). It's actually how the demo site works: when you open it, you are given a new site running on its own Durable Object for 1hr.

The problem is that Durable Objects are not really built for that fan-out effect that you're describing, and WordPress's attitude of treating all sites as siblings in the same database makes a bit more sense for that.

[ascorbic]

@joeblew999 yes. The implementaiton is in the Cloudflare plugin: https://github.com/emdash-cms/emdash/blob/main/packages/cloudflare/src/db/do-preview.ts

You can see usage in the playground demo: https://github.com/emdash-cms/emdash/tree/main/demos/playground

[ascorbic]

As @MattieTK says, the DO preview adapter there was originally designed to support multisite, but after talking internally it became clear that DOs weren't the right approach. I just like them so much I want to use them for everything!

[schiste]

Hi,

My two cents as I'm currently on this for my use case (operating different website with a single stack) and haring how I'm approaching this in practice with emdash. I opted for separated DBs and a shared layer built through plugins rather than a tenant_id / RLS approach.

Each site gets its own D1 and R2. I then build an abstraction layer for everything that needs to be shared, while keeping sites genuinely isolated. Plugins handle the sync between them. Given the current stage of things it made the most sense, but I'm also starting to think it may make sense on the long run.

Why this approach:

• Best isolation and most secure. With everything behind Cloudflare, auth management isn't an issue. More importantly, leakage or plugin bugs are not a topic. One site's broken plugin can't touch another site's data.
• All typing and shared concerns live at a package level. Sites consume shared types, tokens, and config from workspace packages. The shared layer is code, not database coupling.
• Three shared "collections" Files, Data, and Plugins to let each site pull from shared packages what needs to be shared. This keeps the sharing explicit and auditable. I did that for payload, I'm upgrading it but it's pretty boilerplate libraries at the end.
• CF pricing makes isolation essentially free. D1 charges per DB are negligible, R2 has zero egress. Free isolation is a great perk.

The shared layer is a stepping stone toward a federation tool. The three shared collections (Files, Data, Plugins), depending on how you would move forward with the muli tenancy topic, I consider them a coordination layer that sits above individual EmDash instances and manages what's shared between them.

A bit like the control plane for a network of sovereign sites. Each site stays independent, but the federation layer handles discovery (which sites exist, what they share), sync orchestration (what changed, who needs it), and conflict resolution (one site owns each piece of shared content, etc... there's always a source of truth, and it's always a real site with an admin UI, not a phantom in the repo).

Not my use case, but it could also could be a great brick to make it easier for freelancers / IT companies / etc to operate websites for their customers. The Federation approach would make by design the capacity to "onboard" a website in a consultants "realm". It's a bit of a random thought though.

The remaining problem: schema migrations across N sites. I don't have an elegant answer to that yet. It probably would mean having to build an orchestrator for migrations. Right now I'm managing it through seed files and CLI tooling in the monorepo but that won't scale. Perhaps there are existing tools in CF I didn't identify that could help.

Anyway that's my two cents :)

[vikramrojo]

@schiste @MattieTK has there been any formal conclusion on multitenancy in the recent releases?

[marks-zyz]

@schiste your setup is the most concrete multi-site EmDash operation described anywhere — I'm building toward the same shape (agency, dozens of client sites, one core) and I'd rather learn from yours than rediscover it. Four specific questions, if you're willing:

1. Is any of it public? I found schiste/temis (the snapshot→static pattern is excellent), but not the multi-site/shared-layer setup. Even a skeleton would save people here a lot of head-scratching.
2. What exactly do the plugins sync in your three shared collections (Files, Data, Plugins) — and over which channel? REST with a PAT from site to site, hooks pushing on content:afterPublish, or something out-of-band? One-way (source-of-truth site → consumers) or reconciled?
3. How does a request find its site in your deployment — one Worker per site with its own route/domain (so routing is just Cloudflare config), or a dispatcher in front?
4. The migrations problem you named ("seed files and CLI tooling... won't scale") — what does a release day actually look like today with N sites? Sequential CLI against each? Any canary/rollback story?

One thing I can offer back from reading the current adapter code, since it bears on the "DOs weren't the right approach" conclusion upstream: the per-request DB contract now already receives the request URL — RequestScopedDbOpts in packages/cloudflare/src/db/do-sql.ts carries url: URL and cookies, and DatabaseDescriptor.entrypoint lets an external package supply the dialect. Which means a hostname→DO adapter looks buildable as a third-party package today, no core changes — the open questions are the singleton/init path, per-DO migrations on first hit (the playground middleware already does this), and cache-epoch scoping. I'm planning to prototype exactly that; happy to compare notes with your separated-D1s approach, since they're two answers to the same operational problem.

[marks-zyz]

Adding my case here, as suggested on Discord.

I run an agency on WordPress multisite. The part of multisite I actually use is operational, not runtime: dozens of client sites on one core — one upgrade, one place to provision a new site in minutes, one dashboard to see them all. Each site is otherwise fully independent: own domain, own content, own users — and crucially its own schema. Different clients get entirely different content types and fields, defined at runtime in the admin; they don't share a schema package. (This is also why I'm here rather than on code-first-schema CMSs: EmDash keeping the schema in the database is exactly what a multi-client setup needs.) I'm moving the frontends to Astro and would love EmDash to be the backend for all of them, so I'm trying to understand where this lands before building tooling around N independent deploys.

A few things changed since this thread went quiet in April, and I think they're relevant to the original objection:

1. The DO backend exists now (feat(cloudflare): Durable Objects SQL database backend with read replication #1492): durableObjects() stores the whole CMS in one DO's SQLite. The instance name is config-time — idFromName(config.name ?? "emdash") in packages/cloudflare/src/db/do-sql.ts — and the config comment already anticipates the override: "Override only if you intentionally run multiple isolated databases behind a single binding."
2. The playground already runs one-DO-per-site in production: playground-middleware.ts provisions a DO per visitor token (idFromName(token)), migrates it, seeds it, and TTL-reaps it. That's per-site isolation working today — keyed by cookie instead of hostname.
3. The public perf-monitor now shows the DO backend beating D1 substantially on the authenticated admin path in far-from-primary regions, so per-site DOs have a measured upside beyond isolation.

On the fan-out concern from the first reply — I think it's right if the DOs are the whole system. But in a hosted-N-sites setup, the cross-site operations (list sites, usage, upgrade orchestration, billing) naturally live in a small control plane (a D1 table mapping hostname → site), and per-site DOs hold only that site's content. The fan-out never touches the DOs. The WordPress model (all sites as siblings in one database) buys cross-site SQL, but pays twice: row-level scoping discipline in every query (#2575 recently showed how that fails silently when the discipline slips), and a harder story for per-site schema — sibling sites sharing one database can't each have their own _emdash_collections/ec_* catalog without per-site table prefixes. One DO per site gets divergent schemas for free: each database carries its own catalog, which is how EmDash already works per installation.

So instead of asking for multi-tenancy in core, a much smaller question:

Would you accept making the DO instance name request-resolvable? e.g. name: string | ((ctx: { hostname: string }) => string) on DurableObjectsConfig, keeping the static default. Host→site mapping, provisioning, quotas and any network admin could then live outside core as an integration — additive, no schema changes, single-tenant remains the default and the only documented path.

And if the answer is "no — run one deploy per site and orchestrate upgrades yourself (monorepo + CI matrix, or Workers for Platforms past the account script limit)", that's genuinely useful to know too: it means the ecosystem should build that orchestration layer as tooling around EmDash rather than wait for a Network feature.

Happy to do the work behind either door.

[vikramrojo]

And if the answer is "no — run one deploy per site and orchestrate upgrades yourself (monorepo + CI matrix, or Workers for Platforms past the account script limit)", that's genuinely useful to know too: it means the ecosystem should build that orchestration layer as tooling around EmDash rather than wait for a Network feature.

Same, would love to know which way to move forward generally.

[etewiah]

Plus one.

Looking forward to clarification around this.

[viztor]

I think a plugin injection point for prefix and db resolution is the best way to do this, while multi-instance is basically free, it add unnecessary complexity to maintain the database, user should also be able to use a CAS for media lib