Write a TypeScript schema. Supatype generates your Postgres database, REST API, GraphQL API, auth, storage, realtime, and CMS — automatically.
One schema. Everything generated.
import type { Model, UUID, Slug, RichText, RelatedTo, Public, LoggedIn, OwnerFrom, SupatypeAuthUser } from '@supatype/types'
export type Post = Model<{
id: UUID
title: string
slug: Slug
body: RichText
authUser: RelatedTo<SupatypeAuthUser>
}, {
access: {
read: Public
create: LoggedIn
update: OwnerFrom<'authUser'>
}
}>Why Supatype
The tools you're stitching together today each solve one piece of the problem. Supatype solves all of it.
Supabase
Supabase gives you Postgres, auth, and storage — but you still write SQL for every migration and build your own CMS for content editors.
Payload CMS
Schema-driven content management — but you're still integrating your own auth, storage, and realtime from scratch.
Convex / Firebase
Reactive and type-safe — but you're on a proprietary database, have no CMS, and your data isn't in Postgres.
One TypeScript schema. Your database, API, auth, storage, realtime, and CMS — all generated, all in sync, all type-safe.
Platform
TypeScript is your migration file. Push your schema, get forward and rollback SQL with risk analysis showing row-level impact before you apply.
Authentication is built in. Declare access: { read: Public, create: LoggedIn, update: OwnerFrom<'authUser'> } on a model and Supatype generates the Postgres RLS policies. No SQL.
Add an image or file field and a storage bucket is automatically created with the right permissions. Image transforms included.
Every model gets a WebSocket subscription generated. React to database changes in your frontend with a single hook — no separate WebSocket infrastructure to operate.
A full content management UI — list views, edit forms, rich text, media library, version history, scheduled publishing, and live preview — all generated from your schema.
No separate CMS neededPostgREST and pg_graphql are wired up automatically. Your schema defines the API surface with full TypeScript client generation and OpenAPI docs.
Row-level, schema-level, or database-level isolation — declare the strategy in your config and Supatype generates the isolation logic. No custom boilerplate.
Coming soonWebhooks, scheduled jobs, email templates, rate limiting, audit logging, field encryption — all declarative in your schema. One source of truth.
Coming soonDevelop locally with native supatype-server, or run the full stack on your own server with Docker Compose (supatype/server on Docker Hub).
Get started
Install the CLI, scaffold a project, and choose local development or self-hosted Docker Compose.
Native supatype-server and the schema engine run on your machine. Postgres is native by default, or you can run only Postgres in Docker.
npm install -g @supatype/cli
First run downloads engine, server, Postgres (native), and Deno into ~/.supatype/cache/.
mkdir my-app && cd my-app supatype init npm install supatype keys
supatype init scaffolds package.json, supatype.config.ts, schema, and public/.
Add the printed keys to .env if needed.
supatype dev supatype push
API gateway: http://localhost:54321 — REST /rest/v1/, auth /auth/v1/, storage, realtime.
In supatype.config.ts: database: { provider: "docker", image: "supatype/postgres:17-latest" }
Engine and supatype-server stay native; only Postgres uses Docker.
/ (local dev)Configure the app once in committed supatype.config.ts (see Deploy changes). For day-to-day coding with Vite or Next dev, use a proxy in supatype.local.config.ts (gitignored) so production can stay static:
# supatype.local.config.ts — laptop only, not on the server
export default {
app: { mode: "proxy", upstream: "http://localhost:5173" },
}
Restart supatype dev after changing config. Routes / to your dev server; APIs stay on /rest/v1/, /auth/v1/, …
Run the full stack on a server with Docker. Use the same project layout as local dev in your own directory.
Ubuntu 22.04+ (or similar), Docker + Compose v2, Node.js 22+, and npm install -g @supatype/cli.
mkdir my-app && cd my-app supatype init npm install supatype keys
Set strong JWT_SECRET and URLs in .env.
Defaults use :latest on Docker Hub (supatype/postgres:17-latest, supatype/server, supatype/storage, supatype/studio, supatype/schema-engine, supatype/functions-worker, supatype/control-plane). Realtime runs inside supatype/server. Pin via SUPATYPE_*_IMAGE in .env only if needed.
supatype self-host compose render supatype self-host compose up -d supatype push
Gateway: http://<your-host>:18473 — Studio at /studio/. Use a reverse proxy for HTTPS.
supatype app add --static ./public
Writes app.mode: "static" to supatype.config.ts — the same file local dev and self-host both read. Commit it; you do not run app add again on the server.
After the first deploy, use Deploy changes for schema and frontend updates.
Local dev and self-host use the same project: one supatype.config.ts in git, plus .env for secrets on each machine. The CLI merges optional supatype.local.config.ts on top (gitignored) for laptop-only overrides such as proxying to Vite.
supatype.config.ts — shared: schema path, app routing, version pins. Commit this.supatype.local.config.ts — optional: overrides, dev-only app: { mode: "proxy", … }. Never required on the server..env — per machine: DATABASE_URL, JWT keys, API_EXTERNAL_URL. Not committed.| Change | Local dev | Self-host server |
|---|---|---|
Schema (schema/index.ts) |
supatype push |
supatype push (Postgres on localhost:5432 via Compose) |
Frontend build (public/ or dist/) |
npm run build — refresh browser (proxy serves your dev server) |
npm run build then supatype self-host compose render and compose up -d |
supatype.config.ts (app path, versions, …) |
Restart supatype dev |
compose render + compose up -d |
Secrets / URLs (.env) |
Edit .env, restart supatype dev |
Edit .env on server, compose up -d |
cd my-app git pull npm install # if package.json changed supatype push # schema migrations npm run build # static files into public/ or dist/ supatype self-host compose render supatype self-host compose up -d
DATABASE_URL in the server .env should point at the Compose Postgres on localhost:5432 so push and Studio use the same database as the stack.
Step-by-step example: scaffold locally, bootstrap a VM, add SSH deploy on push to main.
Comparison
Assembled alternatives cost 50–60% more and require you to integrate incompatible systems yourself.
| Feature | Supatype | Supabase | Payload CMS | Convex | Firebase |
|---|---|---|---|---|---|
| TypeScript schema as source of truth | ✓ | ✗ | ✓ | ✓ | ✗ |
| Content CMS for non-technical editors | ✓ | ✗ | ✓ | ✗ | ✗ |
| Real Postgres | ✓ | ✓ | ✓ | ✗ | ✗ |
| Built-in auth | ✓ | ✓ | Plugin | ✓ | ✓ |
| Built-in storage | ✓ | ✓ | Plugin | ✗ | ✓ |
| Realtime subscriptions | ✓ | ✓ | ✗ | ✓ | ✓ |
| Auto-generated RLS from access rules | ✓ | ✗ | ✗ | ✗ | ✗ |
| Migration risk analysis | ✓ | ✗ | ✗ | ✗ | ✗ |
| Self-hostable | ✓ | ✓ | ✓ | ✗ | ✗ |
| Multi-tenancy from schema config | ✓ | ✗ | ✗ | ✗ | ✗ |
| Schema-driven webhooks & scheduled jobs | ✓ | ✗ | ✗ | ✗ | ✗ |
Supatype is in active development. Star the repo, join the Discord, and help shape the platform.