Introducing Kanesh, a small AI-first backend

Kanesh is a self-hosted headless data platform that combines SQL collections, a visual Studio, REST, GraphQL, and read-only MCP in one application container. This is its first stable release: it is new, free to self-host for one workspace, and gives Codex or Claude Code permission-aware read access to your application data.

What does Kanesh include today?

The starting point is a collection: a real SQL table with fields you define through Studio. You can create collections, work with records, and manage the data model without first building a separate administration screen. Studio includes sortable and filterable tables, selected columns, table and list layouts, and record sheets.

Each collection becomes available through REST and GraphQL. The API reference provides collection-specific examples, while an OpenAPI 3.1 export describes the live schema. That puts the data model, record editor, and API reference in the same installation. It does not remove the need to decide what your application should store or who should access it.

Kanesh also supports file and image fields that reference workspace uploads. Uploads are stored in the database by default, or in S3, MinIO, or Cloudflare R2 when you set STORAGE_DRIVER=s3. Invitation and password recovery email goes through Resend or an SMTP relay.

How do databases and workspaces fit together?

SQLite is the default database, with data stored locally. PostgreSQL and MySQL are supported for external database deployments. Choose a database based on the operations your model needs and the infrastructure you already run.

The data model supports relations with actual foreign keys and managed indexes. Optional fields can be added to populated collections; adding a required field needs an empty table. Those limits matter when you are testing how a model changes after records already exist.

One installation can hold multiple independent workspaces, each with members and roles. One workspace per install is free with every core feature. Pro costs $9 per month per install and adds unlimited workspaces and an in-Studio AI assistant, which is still in development. See pricing. Workspace separation does not replace permission design: decide which collections each person needs before giving them access.

What can Codex and Claude Code do through MCP?

With MCP enabled, each workspace has its own endpoint. Codex and Claude Code can inspect the readable schema, inspect saved lookups and managed indexes, and request bounded pages of records. The tools are read-only, even when the token owner can edit records elsewhere.

Writes require the REST API and appropriate permissions. Keep that distinction clear when planning an agent workflow: reading a collection through MCP is different from creating a collection or changing its records. The MCP guide explains the endpoint and personal-token setup.

Personal tokens act as their owners. They expire, can be revoked, and are stored as hashes, but they are not separately scoped credentials. Scoped or read-only API keys and service accounts are planned. Choose the account’s workspace access accordingly.

What should you check before you start?

Use this checklist to keep your setup tied to what exists:

• Build the image from the repository, as Getting started describes.
• Keep the persistent data volume when running the container.
• Claim the installation and create the owner account.
• Create a collection and inspect its generated API reference.
• Check member permissions before connecting an agent.
• Confirm that read-only MCP matches the agent task.
• Treat realtime subscriptions, OAuth or SSO sign-in, and workflows as roadmap items, not features.

The original image smoke test reported about 8.9 MB for the image and under 10 MiB of idle memory. Those are measurements from that smoke test, not a capacity estimate for your records, queries, or deployment. Start with the documented setup and test with your own data.

Where should you start?

Follow Getting started to build the image, run it with persistent storage, and claim the installation. Then create a small collection that represents the data you actually need. Check record editing, API reads, and access using that collection before expanding the model.

For application context, read the blog use case or agent data use case. If you are comparing options, the PocketBase comparison provides a separate place to review the choice, and pricing explains the plans and the license. These are next steps, not a claim that Kanesh fits every application.

FAQ

Is Kanesh ready for production?

Kanesh is at its first stable release. It is new, so it has less time in the field than established platforms, and we make no benchmark or customer claims. Realtime subscriptions, OAuth or SSO sign-in, and workflows are on the roadmap and should not be dependencies of your project today.

Is Kanesh free?

Yes for one workspace per install, with every core feature included. Pro costs $9 per month per install and adds unlimited workspaces and the in-Studio AI assistant, which is still in development. The core is AGPL-3.0, and the Pro code in ee/ is under the Kanesh Commercial License (draft).

Can an agent create records through MCP?

No. MCP tools only read workspace schema, schema-model metadata, and records. An agent that needs to create collections or records must use REST with a token whose owner has the required permissions. Write access on the owner account does not turn MCP into a write interface.

Does Kanesh require PostgreSQL?

No. SQLite is the default and stores data locally. PostgreSQL and MySQL are supported when you want an external database.