An LLM-friendly, single-binary, drop-in replacement to Supabase.
Defined in one YAML file — self-hosted in seconds.
One YAML file is the schema. Editinstancez.yaml
and instancez diffs it against the live database, applying just the delta migration (including drops) — no migration files to write or run by hand.Compatible with Supabase clients(@supabase/supabase-js
, and others). Point your existing client at instancez and it works: auth, PostgREST-style REST, RPC, storage.Runs anywhere. One self-contained, portable binary — locally, in Docker, on a VM, or on AWS Lambda.LLM-friendly. A simple, easy-to-understand YAML schema — tables, RLS, storage, RPC, functions — one file an LLM (or teammate) can read end to end.
instancez.yaml
and inz dev
booting, then a live supabase-js app: anonymous sign-in, then insert / update / delete.
The built-in dashboard at /dashboard. Under inz dev, schema edits write back to instancez.yaml as a diff you review before it applies.
curl -fsSL https://get.instancez.ai | sh
irm https://get.instancez.ai/windows | iex
Or build from source. This needs Go 1.25+ and Node 22+. The dashboard is embedded into the binary, so build it before the Go install:
git clone https://github.com/instancez/instancez.git
cd instancez
(cd dashboard && npm ci && npm run build) && go install ./cmd/inz
mkdir my-app && cd my-app
inz init
inz dev --embedded-pg # no Postgres to install; or drop the flag and set INSTANCEZ_DATABASE_URL to use your own
cat .development.env # in a separate terminal — publishable + secret keys, generated on first run
inz dev
provisions the Postgres roles, applies the schema, and serves the API at http://localhost:8080
. Editing instancez.yaml
re-applies the schema automatically.
Here's the whole app inz init
scaffolds (instancez.yaml
, comments trimmed):
version: 1
project:
name: "my-app"
providers:
storage:
type: local
auth:
jwt_expiry: 15m
refresh_tokens: true
refresh_token_expiry: 7d
email:
verify_email: false
tables:
todos:
fields:
- name: id
type: bigserial
primary_key: true
- name: user_id
foreign_key:
references: auth.users.id
on_delete: cascade
- name: title
type: text
required: true
- name: status
type: text
required: true
enum: [pending, active, done]
default: pending
- name: created_at
type: timestamptz
required: true
default: now()
rls:
- operations: [select, insert, update, delete]
using: "user_id = auth.uid()"
with_check: "user_id = auth.uid()"
storage:
avatars:
public: true
max_size: 5MB
types: [image/*]
rls:
- operations: [insert]
with_check: "auth.is_authenticated()"
- operations: [update]
using: "auth.is_authenticated()"
with_check: "auth.is_authenticated()"
- operations: [delete]
using: "auth.is_authenticated()"
functions:
todos:
runtime: node
file: functions/todos.js
auth_required: true
Query it with supabase-js
:
import { createClient } from '@supabase/supabase-js'
const supabase = createClient('http://localhost:8080', process.env.INSTANCEZ_PUBLISHABLE_KEY)
const { data, error } = await supabase
.from('todos')
.select('*')
Or with curl
:
curl 'http://localhost:8080/rest/v1/todos?select=*' \
-H "apikey: $INSTANCEZ_PUBLISHABLE_KEY"
The scaffolded todos
table has a user_id = auth.uid()
RLS policy, so rows are scoped to the signed-in user. To read without signing in while you experiment, set using: "true"
on the policy in instancez.yaml
.
The repo ships an agent skill that teaches your coding agent the YAML syntax, RLS patterns, and the inz
CLI. Install it into your project with the skills CLI, which supports Claude Code, Codex, Cursor, OpenCode, Gemini CLI, Copilot, and more:
npx skills add instancez/instancez # auto-detects your agents
npx skills add instancez/instancez -a codex # or target one explicitly
Claude Code users can install it as a plugin instead:
/plugin marketplace add instancez/instancez
/plugin install instancez@instancez
For any other agent, the skill is a single Markdown file: drop SKILL.md into your project and reference it from
AGENTS.md
. Details in the Coding Agents docs.
Self-host it yourself:
inz serve
Secrets load automatically from .production.env
if present, alongside the regular process environment.
Or deploy to instancez Cloud:
inz cloud deploy # push instancez.yaml straight to a managed project
Self-hosting also runs on Docker, Kubernetes, AWS Lambda, or a bare VM. More on deployment →
| instancez | Supabase | |
|---|---|---|
| Auth (password, magic link, OTP, anonymous, OAuth, TOTP MFA) | Yes (no phone/SMS) | Yes |
| PostgREST-style REST API | Yes | Yes |
| SQL functions (RPC) | Yes | Yes |
| JavaScript functions | Yes (Node.js) | Yes (Deno) |
| Storage (local or S3, RLS, signed URLs, image resize) | Yes (JPEG/PNG only, no WebP/AVIF) | Yes |
| Row-Level Security (RLS) | Yes | Yes |
| Realtime / websockets | Not supported yet | Yes |
| Schema definition | One declarative YAML file | SQL migrations + dashboard |
| Self-host footprint | One binary + Postgres | Multi-container stack |
| OAuth providers built in | Google, GitHub | Many |
docs/examples/gearstore is a full, runnable project: a React storefront talking to instancez over
@supabase/supabase-js
, exercising auth, RLS, and querying end to end. docker compose up --build
gets you a working app with seeded data.The docs also walk through two smaller builds start to finish: an ecommerce store with Stripe Checkout, and a file gallery with direct-to-S3 uploads.
Full docs live at ** instancez.github.io**:
Contributions are welcome. Start with CONTRIBUTING.md for the dev setup, the test loop, and how the codebase is laid out. Bug reports and feature requests go through the issue templates.
Found a vulnerability? Please follow the private disclosure process in SECURITY.md rather than opening a public issue.
Apache License 2.0, see LICENSE. Contributions are covered by the Contributor License Agreement.