# The backend in one file — Hanzo AI

> Everything your app or business needs on the backend — database, auth, file storage, realtime, and server-side logic — in one embedded, deployable file, with…

Hanzo Base · App backend

# An app backend in one file

Base is a single Go binary that serves your data, your users, your files, live updates and scheduled work over one HTTP API. The store is a SQLite file on disk, so deploying is copying a binary and backing up is copying a file.

[Start free](https://console.hanzo.ai)[Read the docs](https://docs.hanzo.ai/docs/projects/hanzoai/base)[View on GitHub](https://github.com/hanzoai/base)

Open source (MIT). Runs as one binary — self-host or deploy managed on Hanzo Cloud.

What is Hanzo Base

## Declare a collection, get an API

A collection is a real table with a schema you write down. The moment it exists it answers over HTTP, carries an access rule, streams its changes, and shows up in the admin. There is no code generation step and nothing to wire together.

01

### Data

Records answer at /v1/collections/{name}/records — list, read, create, update, delete, with paging, sorting and a filter language over every field you declared. Schema changes are migrations. SQLite is the default store; hand Base a Postgres DSN and the same API runs on that instead.

02

### Auth is Hanzo IAM

Base keeps no password and has no login form. It verifies the token IAM signed and reads the identity out of it — that is the whole of authentication. One account everywhere Hanzo runs, and no reset flow of your own to get wrong.

03

### Files and live updates

Uploads go to object storage and are served through the same rule that guards the record pointing at them. Clients open one stream and receive records as they change, so a page stays current without asking again every few seconds.

Capabilities

## What you get

### The schema is the API

Define a collection and its records are addressable the same second, with an admin UI to browse and edit them. Nothing is scaffolded into your repo, so there is nothing to regenerate when the schema moves.

### One stream, no polling

Subscribe over server-sent events and records arrive as they change. A browser cannot put a header on that request, so the stream is opened with a short-lived grant minted on an ordinary authenticated call — your access token never travels in a URL.

### Rules run before the count

An access rule is a predicate on the collection, folded into the query ahead of paging and ahead of the count — so a row you may not read is not counted either. With nobody signed in, a rule naming the caller matches nothing.

### Files behind the same rule

An upload is guarded by the rule on the record that references it, and reading one takes a token minted per request rather than a URL that works forever.

### A file per tenant

Each org gets its own SQLite file, opened under a key derived for that org — a different tenant is a different file, so no query can reach across two. Point Base at object storage and the write-ahead log streams there continuously, encrypted before it leaves the process, and you can restore to a moment.

### Server-side logic, fenced in

A function is a record in a collection, so the collection’s rules decide who may run it. It runs in-process with two calls bound — read a record, read a list — and no network, no filesystem, no shell. Whatever the first version binds is supported forever, which is why that list is short.

## Run the binary

Deploy Base managed on Hanzo Cloud, or run it yourself on a laptop, a box, or a cluster. Same API in all four places.

[Deploy on Hanzo Cloud](https://console.hanzo.ai)[Read the docs](https://docs.hanzo.ai/docs/projects/hanzoai/base)[GitHub](https://github.com/hanzoai/base)

## Open source

License: MIT[hanzoai/base](https://github.com/hanzoai/base)

## Get Base

Embedded data backend with IAM-native auth

[Deploy to Cloud](https://console.hanzo.ai/deploy)[Self-host](https://docs.hanzo.ai/docs/projects/hanzoai/base)