A multi-tenant backend: one install, many workspaces
Need a multi-tenant backend that serves many clients from one install? Kanesh gives each workspace its own schema, members, roles, API and MCP endpoint.
A multi-tenant backend serves several clients or products from one installation while keeping their data, users and permissions apart. In Kanesh, each workspace has its own schema, members, roles, REST and GraphQL API and MCP endpoint, so a new client is a new workspace, not a new server. One workspace per install is free, and unlimited workspaces cost $9 per month per install.
Two meanings of multi-tenant
The term covers two designs, and they suit different problems.
- Shared schema. One set of tables with a tenant column on every row. Your own code must filter by tenant on every query.
- Separate workspaces. Each tenant gets its own schema, members and permissions inside one install.
Kanesh does the second. Workspaces are independent projects that happen to run in the same process. That fits an agency with several clients, a team with one tool per department, or a developer with several side projects. It is not a row-level tenant filter inside one schema.
What each workspace contains
| Part | What is separate |
|---|---|
| Schema | Collections, fields, relations and indexes |
| Members | Who can sign in to the workspace |
| Roles | Owner, Administrator, Editor, Viewer and Public, plus up to 20 custom roles and 50 policies |
| API | REST, GraphQL and an OpenAPI 3.1 export for that schema |
| MCP | One opt-in, read-only endpoint per workspace |
Every request carries the workspace in its path, so two clients never share an endpoint:
GET /api/v1/workspaces/WORKSPACE_ID/collections/orders/recordsPermissions are set per workspace. Personal API tokens act as the user who created them, so a token only reaches what that user can reach. Access control applies the same way to Studio, REST, GraphQL and MCP. See access control.
Why this saves operating work
With a server per client you maintain one container, one database, one backup job and one set of upgrades for each. With workspaces you maintain one of each. Kanesh is one Go binary with the Studio embedded, in an image of about 8.9 MB (arm64, measured 2026-10-04), and it idled under 10 MiB of memory in a local smoke test. That is not a benchmark, and it does not include your data or an external database.
The next client is a workspace in Studio. The owner adds members and gives each one a role for that workspace.
Workspaces compared
| Kanesh | PocketBase | Appwrite | |
|---|---|---|---|
| Projects per install | Many independent workspaces | One app per instance | Many projects per instance |
| Self-host shape | One container | Single executable | Multi-container Docker Compose stack |
| Databases | SQLite, PostgreSQL, MySQL | Embedded SQLite | Not compared here |
What many workspaces cost
One workspace per install is free, with every core feature included. To run unlimited workspaces in one install you need Pro, a flat $9 per month per install with no per-seat charges. Pro also includes the in-Studio AI assistant, which is still in development. The Kanesh core is AGPL-3.0, and the Pro code in ee/ is under the Kanesh Commercial License (draft). If a key expires, extra workspaces become read-only and nothing is deleted. See pricing.
Limits to know
An install is configured with one database, so all its workspaces share that database server. The separation is logical, with its own schema, members and roles per workspace. If a client needs a separate database server or hard infrastructure isolation, run a separate install for them.
There is one owner per installation, and ownership can be transferred. Give clients the Administrator or Editor role inside their own workspace. If you expect many tenants that all share the same schema, model the tenant as a collection and enforce it in your own service instead.
Kanesh also has no realtime, OAuth or SSO, workflows or SDKs yet. Realtime, OAuth or SSO sign-in and workflows are on the roadmap.
FAQ
What is a multi-tenant backend?
It is a backend that serves more than one customer, team or product from the same installation while keeping their data and permissions separate. Designs range from one shared schema with a tenant column to separate schemas per tenant. Kanesh uses separate workspaces.
Does each workspace have its own API and MCP endpoint?
Yes. Each workspace has its own REST and GraphQL API, its own OpenAPI export and, when MCP_ENABLED=true, its own read-only MCP endpoint. Tokens carry the permissions of the user who created them.
Can I move a workspace to another install later?
You can export records as bounded CSV or JSON and import them into a collection on another install. Recreate the collections and field types first. Test with a small collection before you rely on it for a client.
Next steps
Create your first workspace with Getting started. To see how a one-app-per-instance backend differs, read Kanesh vs PocketBase.
Keep reading
Introducing Kanesh, a small AI-first backend
Why we built a self-hosted data platform that fits in one container and speaks MCP next to REST and GraphQL.
MVP backend: when static data is enough and when you need an API
Choose an MVP backend: compare static data and APIs, weigh migration costs, and start with Kanesh collections without writing a custom backend.
One backend per client was one setup too many
Repeating Directus setups for client projects led me to build a multi-tenant backend with independent workspaces in one Kanesh install.