One backend per client was one setup too many

Working with many clients meant setting up a separate Directus instance for every project, each with its own server, updates and admin. Repeating that work is why I built Kanesh to support many independent workspaces in one install.

The problem

Directus is a good product. It gave me a way to manage data without building an admin interface for every client. The difficulty came from repeating the surrounding setup whenever another project arrived.

For each client, I spun up another instance. That meant another server to look after, another installation to update, and another admin to return to when something needed changing. Each individual setup was reasonable. Keeping several of them going was the part I wanted to change.

The repetition became familiar enough that I started questioning the unit of deployment. Was a new client always a reason for a new backend installation? The client needed their own data model and access. I wanted to keep those boundaries without repeating the entire operating setup.

That distinction matters to this story. I was not trying to prove that Directus was wrong. I had a recurring cost in my own work, and I wanted a different way to handle it. The Directus comparison describes the broader differences, including how much newer Kanesh is.

What I wanted

I wanted to open the same installation and create a workspace for the next project. That workspace needed its own schema, members and roles. Clients have different data and different people responsible for it; putting them under one installation should preserve those differences.

I also wanted the boundary to carry through to integrations. An application should use the API for its workspace. An agent should connect to that workspace’s MCP endpoint. Sharing the installation should not mean treating every project as one collection of data.

My aim was modest: spend less time repeating infrastructure setup and more time working on the actual project. I still expected to maintain the installation, review access and keep backups. Consolidating that work changes where the responsibility sits; it does not remove it.

How workspaces solve it

Kanesh gives each workspace its own schema, members, roles, API and MCP endpoint. I can keep independent projects inside one install while managing their access separately. The access control guide explains how workspace permissions apply across Studio, REST, GraphQL and MCP.

This is the operating change I wanted, compared with my previous setup:

Responsibility	One instance per client	One install, many workspaces
Servers	A separate server for each client in my setup	One shared Kanesh install; workspaces share its database server
Updates	Repeat the update for every instance	Update the shared installation
Backups	Maintain a backup plan for each instance	Plan backups for the shared installation and its data
Admin logins	Return to each client’s separate admin	Use one Studio with workspace membership and roles
API endpoints	A separate instance endpoint per client	Workspace-specific API endpoints within the same install

The backup row needs care. Fewer installations give me fewer places to manage, but they also put several projects under the same operational responsibility. I still need a backup and recovery plan that accounts for all of them. A workspace boundary is not a separate database server.

For agent access, MCP is opt-in and read-only today. It uses the same workspace authorization as the other interfaces. The agent data use case is a useful next read if that is part of your project.

I explain the workspace model further in one install, many workspaces. One workspace per install is free, and unlimited workspaces need Pro at $9 per month per install; see pricing. To try it, start with getting started.

What it does not do yet

Kanesh is new, at its first stable release. Realtime, OAuth, workflows and functions are on the roadmap. I do not want this account of why I built it to suggest that those features are already available.

There is one owner per install. Every workspace shares the install’s database server, even though its schema, members and roles are separate. If a client requires a separate database server or control over their own installation, I would keep a separate install for that client.

FAQ

Is this a reason to stop using Directus?

For me, it was a reason to build around a recurring setup cost. Directus remains a good product. If its features and deployment model fit your work, this story is not an argument that you need to replace it.

Does each client get an independent owner?

No. Kanesh has one owner per installation. Workspaces have their own members and roles, but they are managed within that ownership boundary. I would not describe a workspace as a fully independent installation that a client owns.

Does one install mean the maintenance is finished?

No. I still have a server, updates, backups and access decisions to manage. The outcome I wanted was less repetition across client projects. Workspaces let me consolidate the installation while keeping each project’s schema and permissions separate.