Introduction
What Chelabase is, who it is for, and where to start.
Alpha
Chelabase is a database-as-a-service control plane on Neon. Each database gets its own Neon tenant, timeline and compute, plus branches, login roles, encrypted and re-revealable credentials, a data API with row-level security, and app-user auth. Studio is the only user-facing app.
It is for app developers (full-stack and product engineers) who build on Postgres. You use the typed client, @chelabase/client, and the data API from your app, and Studio while you build: projects, databases, branches, schema, data, API keys, row-level security and your app's users.
Success is going from sign-up to a working, secured database that your app queries through the typed client, without reaching for a second tool.
What you get
- Databases and branches. A database is a Postgres cluster with its own storage and compute. Branch it at any point in its history, reset a branch to its parent, or restore it. See Projects and databases and Branches.
- Login roles. Create Postgres roles in Studio, through the API or in plain SQL; their passwords are stored encrypted and can be shown again. See Login roles.
- A data API. A typed JSON query endpoint,
POST /data/v1/query, with a builder client and generated types. It runs as theanonandauthenticatedroles, so row-level security decides what rows come back. See Data API and TypeScript client. - App users. Sign-up, sign-in and sessions for your own app's users, so their identity reaches your row-level security policies. See App users.
- Studio. The browser app for all of the above, including a SQL editor. See SQL editor and Studio tour.
Principles
- Safe by default. The secure option is the default and the easiest one. Risky states, such as missing row-level security or exposed keys, are shown rather than hidden.
- Developer flow first. Building, querying and inspecting happen in one place.
- Postgres stays legible. Branches, roles and policies are shown as what they are, not behind abstractions.
- Our own design. Chelabase solves each problem directly. The data API is a typed query endpoint, not a URL grammar; auth is its own.
Modes
Chelabase runs in one of two modes, set with CHELABASE_MODE.
| Mode | What it is |
|---|---|
self-hosted (default) | What runs today, and the dev mode. Email verification is off, everyone who signs up shares one tenant, and some safety checks (such as password strength) are opt-in. |
platform | The hosted cloud. Not built yet; where this page mentions it, it describes what the code already does when the mode is set. |
Limits today
- The Management API takes only a member access token (from Studio's sign-in, or
POST /auth/v1/token). There are no API keys for it yet. Data API keys exist, but they open only the data API. - The gateway does not terminate TLS. It serves plain HTTP on
:8000and rejectshttps://upstreams; put a TLS-terminating proxy in front of it for anything beyond local use. It keeps anX-Forwarded-Protoset by such a proxy. - No tenant per sign-up. In self-hosted mode everyone who joins (by invite, or by sign-up when an admin opens it) is in the same tenant, a shared team workspace.
- Postgres wire access is Neon's proxy. Connections go through Neon's proxy (
<endpoint>.localtest.me:4432in dev); Chelabase has no wire proxy of its own.
Where to start
Follow the Quickstart to bring the stack up, create a database and query it. The error codes are listed in the Reference section, along with every endpoint, and Architecture explains how the pieces fit.