Why the name Kanesh

Kanesh takes its name from a Bronze Age trading city whose merchants kept their own records on clay tablets. The name connects that habit of keeping an independent archive with a self-hosted data platform where you manage collections, records, and workspace access yourself.

Where does the name Kanesh come from?

Kanesh, also written Kaniš, was a city in central Anatolia, near today’s Kayseri in Türkiye. Around the 20th to 18th centuries BC, merchants from Assur ran a trading quarter there called the kārum. The name of the software refers to that city and its records.

Archaeologists found tens of thousands of clay tablets in the merchants’ houses. These included letters between partners, shipping notes, loans, contracts, and court records, written in cuneiform. Each house kept its own archive. The point of the name is that connection between everyday work and the records people keep to support it.

The comparison is an analogy, not a technical specification. A clay tablet does not explain how a database enforces a relation or how a token is authorized. It gives the project a way to describe its purpose: a system of record you host yourself.

How does an archive relate to application data?

A collection gives related records a shared structure. Typed fields and validation describe what belongs in that structure. Relations connect records, while the schema graph helps show connections in the data model. Those are concrete software features behind the broader archive analogy.

For example, thinking about a shipping note invites questions about which fields the record needs and which other records it should reference. That is a modeling exercise, not a claim that Kanesh supplies a shipping application. You still choose the collections and the meaning of their fields.

Historical idea	Connection to Kanesh
One tablet records a transaction	Collections hold individual records
Repeated formats for loans and shipments	Typed fields and validation define structure
Tablets refer to other tablets	Relations and the schema graph connect data
Each house keeps an archive	Self-hosted workspaces keep records under your control
Sealed envelopes address a recipient	Roles and collection permissions govern access
Letters travel between cities	REST, GraphQL, and MCP expose data to clients

These connections explain the name without promising that every historical idea has an exact software equivalent. In particular, the reference to sealed envelopes is about deciding who can access records, not a claim about a specific encryption feature.

What does keeping your own records mean here?

Kanesh runs as one application image with Studio included. SQLite is the default database and keeps data locally; PostgreSQL and MySQL are supported for external deployments. The self-hosted model means that choosing storage and maintaining the installation are part of using the platform.

One installation supports independent workspaces with their own members and roles. One workspace is free, and unlimited workspaces need a Pro license at $9 per month per install (see pricing). Studio lets you define collections and work with records. REST and GraphQL expose those collections, and the OpenAPI 3.1 export comes from the live schema. Your archive is therefore also available to the application clients you authorize.

A useful first exercise is to define a small collection, add records, and inspect its API reference. The getting-started guide walks through building the image and claiming the installation. For examples of application contexts, continue to the CRM use case or internal tools use case.

How does access work for people and agents?

The archive analogy includes boundaries: a record should be available to the intended reader. Kanesh applies workspace authorization across Studio, REST, GraphQL, and MCP. Roles and per-collection permissions determine the operations a member can perform.

Codex and Claude Code can connect to a workspace through read-only MCP. The available tools inspect schema and records within the token owner’s permissions. They cannot write through MCP. Creating collections or records requires REST and an account with the necessary access.

Personal tokens inherit the owner’s permissions rather than providing an independent scope. Review that access before connecting an agent. The MCP documentation explains setup and the available tools. If you are evaluating another platform alongside Kanesh, use the Directus comparison as a further reading path.

What should the name not lead you to assume?

A name explains intent; current documentation establishes capability. Kanesh is new, at its first stable release. Realtime subscriptions, OAuth sign-in, and workflows are on the roadmap.

Read the name as a reminder to think carefully about records, structure, and ownership. Then judge Kanesh by the collection operations, access rules, and database support it actually documents. The historical story should help explain the project without replacing that evaluation.

FAQ

Why is the platform called Kanesh?

The name refers to the Bronze Age city where merchants kept clay-tablet archives in their houses. Their records included correspondence, shipping notes, loans, contracts, and court records. The software uses that history as an analogy for a self-hosted system of record.

Is Kaniš a different place from Kanesh?

Kaniš is another spelling of Kanesh in the account behind the project’s name. The city was in central Anatolia, near present-day Kayseri in Türkiye. The software name uses Kanesh, while the historical explanation includes both spellings.

Does the archive analogy describe a finished product?

Not entirely. Kanesh is new, at its first stable release. Collections, Studio, APIs, workspace permissions, and read-only MCP are documented capabilities, while realtime, OAuth, and workflows are on the roadmap. Evaluate those current capabilities separately from the story behind the name.