Stop building the same backend for every project

You can avoid rebuilding basic data management for every project by evaluating Kanesh for SQL collections, CRUD APIs, authentication, permissions, and an administration screen. Kanesh provides those pieces in a self-hosted platform at its first stable release, while your product still needs its own data model and any application-specific business logic.

Which backend work keeps repeating?

A new application needs somewhere to store records, endpoints to read and change them, and rules about who may do each operation. Someone also needs a way to browse records and correct data. Those requirements return even when the product itself is different.

The repeated work includes schema definitions, create/read/update/delete endpoints, sessions and tokens, collection permissions, and API documentation. Building each piece separately also means keeping the administration screen and documentation consistent with the model your application uses.

The useful question is which parts of that work need to be unique. Your collection names, field meanings, and product rules require decisions. A record editor or a generated collection API may be something you can evaluate as an existing component instead.

What does Kanesh provide for collections and APIs?

In Studio, you describe collections and fields through the data model. Collections are real SQL tables, immediately available over REST and GraphQL. The API reference includes collection-specific REST examples and an OpenAPI 3.1 export generated from the live schema.

Studio also supplies record tables, filtering, sorting, selected columns, and record sheets. That gives you a place to manage data while building the application that uses it. You can test the same collection through the interface and the API rather than first writing your own administration screen.

SQLite is the default database, and PostgreSQL and MySQL are supported. Pick the database that matches the infrastructure you already run before loading records.

How should you divide the work?

Use the following checklist to distinguish the platform evaluation from your product decisions:

• Define the records your application needs and the fields each record contains.
• Create a collection in Studio and inspect its generated API reference.
• Decide which members should read or change each collection.
• Test record operations using the intended account and permissions.
• Keep application-specific business rules in your implementation plan.
• Check whether a missing feature, such as realtime, OAuth or SSO sign-in, or workflows, excludes a requirement.
• Add agent access only after deciding which data the agent should read.

Kanesh does not make the model correct by choosing it for you. The value to evaluate is whether its existing collection, API, and administration features cover the repeated data work in your project. If the product depends on custom business logic inside the backend, Kanesh does not provide that today.

Can agents build or change the data model?

An agent can use REST to create collections or records when its token owner has the required permissions. That is separate from MCP. Kanesh’s MCP tools are read-only and expose workspace schema, saved lookups and managed indexes, and bounded record reads.

Codex and Claude Code are the agents covered by the setup documentation. Each workspace has its own MCP endpoint, and the agent sees only what its token owner may read. Follow the MCP guide to enable it and configure a personal token.

Personal tokens act as their owners; they are not separately scoped keys. They expire, can be revoked, and cannot manage credentials or change passwords. Plan member permissions first so the agent’s readable data matches the task you intend it to perform.

Can one installation support several projects?

One installation can contain multiple independent workspaces, each with members and roles. The next project can therefore start as another workspace instead of requiring another installation. You still need to define its collections and access rules. One workspace per install is free, and unlimited workspaces need a Pro license at $9 per month per install (see pricing).

A practical evaluation is to begin with one small model and confirm how Studio, APIs, and permissions behave together. The internal tools use case and ecommerce use case provide application contexts to explore. They do not change the need to check whether your specific requirements fit what Kanesh provides today.

When should you choose another approach?

Kanesh is new, at its first stable release. Realtime subscriptions, OAuth sign-in, and workflows are on the roadmap. If your current application requires those capabilities, do not assume they are available because the collection APIs already exist.

Start with Getting started, which builds the image and explains persistent storage and installation claim. Use the Strapi comparison or Appwrite comparison when reviewing other options, and base the choice on the features you need today.

FAQ

Does Kanesh replace all backend development?

No. It supplies documented data-platform features such as collections, record APIs, Studio, authentication, and workspace access. You still define the model and implement application-specific behavior. Kanesh does not provide custom business logic inside the backend today.

Can MCP create collections or update records?

No. Kanesh’s MCP tools are read-only, including when the token owner has write permission. Use REST for collection or record creation and changes, with the required workspace access. The OpenAPI export describes the API for that separate path.

How do I try Kanesh?

Follow the getting-started documentation to clone the repository, build the image, and run it with a persistent volume. Claim the installation using its single-use token, create the owner account, then create a collection in Studio and inspect the API reference.