Backend for Developers
and Agents

Developer & LLM-Friendly Supabase drop-in replacement.

claude mcp add instancez --transport http https://my.instancez.ai/mcp
or install the CLI
curl -fsSL https://get.instancez.ai | sh

Templates

Start from a working backend or from scratch

Production-ready backends with tables, row-level security, auth and functions already wired up. Open one to see exactly what you get, then make it yours.

Live demo ↗
plansRLS
idPK
nametext
price_centsinteger
seat_limitinteger
organizationsRLS
idPK
created_byFK
nametext
slugtext
membershipsRLS
idPK
org_idFK
user_idFK
roletext
subscriptionsRLS
org_idPK
stripe_customer_idtext
stripe_subscription_idtext
plan_idtext
usage_eventsRLS
idPK
org_idFK
user_idFK
eventtext
Start with this
Live demo ↗
conversationsRLS
idPK
user_idFK
titletext
created_attimestamptz
messagesRLS
idPK
conversation_idFK
user_idFK
roletext
app_settingsRLS
keyPK
valuetext
usage_dailyRLS
idPK
user_idFK
daydate
message_countinteger
Start with this
Live demo ↗
profilesRLS
idPK
full_nametext
roletext
categoriesRLS
idPK
nametext
slugtext
productsRLS
idPK
category_idFK
nametext
descriptiontext
cart_itemsRLS
idPK
user_idFK
product_idFK
quantityinteger
ordersRLS
idPK
user_idFK
statustext
total_centsinteger
order_itemsRLS
idPK
order_idFK
product_idFK
nametext
Start with this
Live demo ↗
profilesRLS
idPK
display_nametext
created_attimestamptz
workspacesRLS
idPK
owner_idFK
nametext
created_attimestamptz
workspace_membersRLS
idPK
workspace_idFK
user_idFK
roletext
invitesRLS
idPK
workspace_idFK
created_byFK
tokentext
tasksRLS
idPK
workspace_idFK
assignee_idFK
created_byFK
task_commentsRLS
idPK
task_idFK
user_idFK
bodytext
Start with this
Live demo ↗
waitlist_adminsRLS
user_idPK
signupsRLS
idPK
referred_byFK
emailtext
referral_codetext
join_attemptsRLS
idPK
iptext
created_attimestamptz
Start with this
Live demo ↗
projectsRLS
idPK
owner_idFK
nametext
slugtext
environmentsRLS
idPK
project_idFK
keytext
client_keytext
flagsRLS
idPK
project_idFK
keytext
descriptiontext
flag_configsRLS
idPK
flag_idFK
environment_idFK
enabledboolean
audit_logRLS
idPK
project_idFK
actor_idFK
flag_keytext
Start with this
Live demo ↗
profilesRLS
idPK
usernametext
display_nametext
biotext
postsRLS
idPK
author_idFK
bodytext
image_pathtext
commentsRLS
idPK
post_idFK
author_idFK
bodytext
followsRLS
idPK
follower_idFK
followee_idFK
created_attimestamptz
likesRLS
idPK
user_idFK
post_idFK
created_attimestamptz
Start with this
Live demo ↗
agentsRLS
user_idPK
nametext
roletext
ticketsRLS
idPK
assigned_toFK
public_tokenuuid
customer_emailtext
ticket_messagesRLS
idPK
ticket_idFK
author_idFK
kindtext
canned_repliesRLS
idPK
titletext
bodytext
intake_attemptsRLS
idPK
buckettext
created_attimestamptz
Start with this
More in the app CRM, blog, invoicing, bookings, courses and more.
business

SaaS Starter

The multi-tenant core of a SaaS. Users create organizations and add existing users as owners, admins or members. Stripe Billing subscriptions are mirrored into the database by a webhook, and has_active_plan(org_id) tells your app (or your own RLS policies) who has paid.

5 tables · 7 SQL functions · 3 JS functions

Tables

plans RLS · 1 policy
  • id text PK
  • name text ●
  • price_cents integer ●
  • seat_limit integer
  • monthly_event_limit integer
organizations RLS · 3 policies
  • id uuid PK
  • name text ●
  • slug text ●
  • created_by uuid FK
  • created_at timestamptz ●
memberships RLS · 2 policies
  • id bigserial PK
  • org_id uuid FK ●
  • user_id uuid FK ●
  • role text ●
  • created_at timestamptz ●
subscriptions RLS · 1 policy
  • org_id uuid PK FK
  • stripe_customer_id text
  • stripe_subscription_id text
  • plan_id text
  • status text ●
  • current_period_end timestamptz
  • cancel_at_period_end boolean ●
  • updated_at timestamptz ●
usage_events RLS · 2 policies
  • id bigserial PK
  • org_id uuid FK ●
  • user_id uuid FK
  • event text ●
  • quantity integer ●
  • created_at timestamptz ●

SQL functions POST /rest/v1/rpc/<name>

  • create_organization(p_name text, p_slug text) → uuid security definer
  • add_org_member(p_org_id uuid, p_email text, p_role text) → void security definer
  • remove_org_member(p_org_id uuid, p_user_id uuid) → void security definer
  • set_member_role(p_org_id uuid, p_user_id uuid, p_role text) → void security definer
  • org_members(p_org_id uuid) → table(user_id uuid, email text, role text, joined_at timestamptz) security definer
  • has_active_plan(p_org_id uuid) → boolean
  • org_usage(p_org_id uuid, p_since timestamptz) → table(event text, total bigint)

JavaScript functions Node.js

  • create-subscription-checkout /functions/v1/create-subscription-checkout signed-in users · 30s
  • create-billing-portal /functions/v1/create-billing-portal signed-in users · 30s
  • stripe-webhook /functions/v1/stripe-webhook public · 30s
tools

AI Chat

A chat app backend. Users keep private conversations; a chat function loads the history, calls the Anthropic Messages API, stores the reply and enforces a daily message cap.

4 tables · 2 SQL functions · 1 JS function

Tables

conversations RLS · 4 policies
  • id bigserial PK
  • user_id uuid FK ●
  • title text ●
  • created_at timestamptz ●
  • updated_at timestamptz ●
messages RLS · 2 policies
  • id bigserial PK
  • conversation_id bigint FK ●
  • user_id uuid FK ●
  • role text ●
  • content text ●
  • created_at timestamptz ●
app_settings RLS · 1 policy
  • key text PK
  • value text ●
usage_daily RLS · 1 policy
  • id bigserial PK
  • user_id uuid FK ●
  • day date ●
  • message_count integer ●

SQL functions POST /rest/v1/rpc/<name>

  • consume_message_quota() → jsonb security definer
  • refund_message_quota() → void security definer

JavaScript functions Node.js

  • chat /functions/v1/chat signed-in users · 60s
commerce

Online Store

A full e-commerce backend. Browse products by category, keep a cart, and pay through Stripe Checkout. A webhook atomically marks orders paid, decrements stock and clears the cart. Product images live in a public bucket.

6 tables · 1 SQL function · 2 JS functions · 1 bucket

Tables

profiles RLS · 3 policies
  • id uuid PK FK
  • full_name text
  • role text ●
categories RLS · 4 policies
  • id bigserial PK
  • name text ●
  • slug text ●
products RLS · 4 policies
  • id bigserial PK
  • category_id bigint FK
  • name text ●
  • description text
  • price_cents integer ●
  • currency text ●
  • stock integer ●
  • image_path text
  • active boolean ●
  • created_at timestamptz ●
cart_items RLS · 4 policies
  • id bigserial PK
  • user_id uuid FK ●
  • product_id bigint FK ●
  • quantity integer ●
orders RLS · 2 policies
  • id bigserial PK
  • user_id uuid FK ●
  • status text ●
  • total_cents integer ●
  • currency text ●
  • stripe_session_id text
  • shipping jsonb
  • created_at timestamptz ●
  • paid_at timestamptz
order_items RLS · 1 policy
  • id bigserial PK
  • order_id bigint FK ●
  • product_id bigint FK
  • name text ●
  • unit_price_cents integer ●
  • quantity integer ●

SQL functions POST /rest/v1/rpc/<name>

  • is_admin() → boolean security definer

JavaScript functions Node.js

  • checkout /functions/v1/checkout signed-in users · 30s
  • stripe-webhook /functions/v1/stripe-webhook public · 30s

Storage

  • product_images image/png, image/jpeg, image/webp, image/gif, image/avif public · 5MB · 3 policies
productivity

Team Todo

Workspaces where owners, admins and members share tasks with assignees, due dates, statuses and comment threads. Teammates join through expiring invite links.

6 tables · 13 SQL functions

Tables

profiles RLS · 3 policies
  • id uuid PK FK
  • display_name text
  • created_at timestamptz ●
workspaces RLS · 3 policies
  • id bigserial PK
  • name text ●
  • owner_id uuid FK ●
  • created_at timestamptz ●
workspace_members RLS · 1 policy
  • id bigserial PK
  • workspace_id bigint FK ●
  • user_id uuid FK ●
  • role text ●
  • joined_at timestamptz ●
invites RLS · 2 policies
  • id bigserial PK
  • workspace_id bigint FK ●
  • token text ●
  • role text ●
  • created_by uuid FK
  • expires_at timestamptz ●
  • max_uses integer ●
  • uses integer ●
tasks RLS · 4 policies
  • id bigserial PK
  • workspace_id bigint FK ●
  • title text ●
  • description text
  • status text ●
  • priority smallint ●
  • assignee_id uuid FK
  • due_date date
  • created_by uuid FK
  • created_at timestamptz ●
task_comments RLS · 4 policies
  • id bigserial PK
  • task_id bigint FK ●
  • user_id uuid FK ●
  • body text ●
  • created_at timestamptz ●

SQL functions POST /rest/v1/rpc/<name>

  • is_member(p_workspace_id bigint) → boolean security definer
  • is_user_member(p_workspace_id bigint, p_user_id uuid) → boolean security definer
  • ws_role(p_workspace_id bigint) → text security definer
  • shares_workspace(p_user_id uuid) → boolean security definer
  • task_creator(p_task_id bigint) → uuid security definer
  • task_workspace(p_task_id bigint) → bigint security definer
  • create_workspace(p_name text) → bigint security definer
  • create_invite(p_workspace_id bigint, p_role text, p_days integer, p_max_uses integer) → text security definer
  • accept_invite(p_token text) → bigint security definer
  • set_member_role(p_workspace_id bigint, p_user_id uuid, p_role text) → boolean security definer
  • remove_member(p_workspace_id bigint, p_user_id uuid) → boolean security definer
  • transfer_ownership(p_workspace_id bigint, p_user_id uuid) → boolean security definer
  • workspace_summary(p_workspace_id bigint) → jsonb
business

Launch Waitlist

A pre-launch waitlist. A public join function validates the email, dedupes, and returns the signup's queue position and referral code. Each referral moves the referrer up the queue. Admins export signups as CSV and invite the next batch.

3 tables · 3 SQL functions · 2 JS functions

Tables

waitlist_admins RLS · 1 policy
  • user_id uuid PK FK
signups RLS · 3 policies
  • id bigserial PK
  • email text ●
  • referral_code text ●
  • referred_by bigint FK
  • referral_count integer ●
  • status text ●
  • source text
  • invited_at timestamptz
  • created_at timestamptz ●
join_attempts RLS · 1 policy
  • id bigserial PK
  • ip text ●
  • created_at timestamptz ●

SQL functions POST /rest/v1/rpc/<name>

  • join_waitlist(p_email text, p_ref text, p_source text, p_ip text) → table(referral_code text, queue_position bigint, queue_total bigint, is_new boolean) security definer
  • waitlist_status(p_code text) → table(queue_position bigint, queue_total bigint, referral_count integer, status text) security definer
  • invite_batch(p_count integer) → table(email text, referral_code text)

JavaScript functions Node.js

  • join /functions/v1/join public · 30s
  • export-signups /functions/v1/export-signups signed-in users · 60s
tools

Feature Flags

A feature-flag service. Projects hold environments and flags; each flag has an on/off switch, a rollout percentage and targeting rules per environment. SDKs call a public evaluate function with an environment key and a user key. Every change is recorded in an audit log.

5 tables · 3 SQL functions · 1 JS function

Tables

projects RLS · 3 policies
  • id bigserial PK
  • owner_id uuid FK ●
  • name text ●
  • slug text ●
  • created_at timestamptz ●
environments RLS · 4 policies
  • id bigserial PK
  • project_id bigint FK ●
  • key text ●
  • client_key text ●
flags RLS · 4 policies
  • id bigserial PK
  • project_id bigint FK ●
  • key text ●
  • description text
  • created_at timestamptz ●
flag_configs RLS · 1 policy
  • id bigserial PK
  • flag_id bigint FK ●
  • environment_id bigint FK ●
  • enabled boolean ●
  • rollout_percentage integer ●
  • rules jsonb ●
  • updated_at timestamptz ●
audit_log RLS · 1 policy
  • id bigserial PK
  • project_id bigint FK ●
  • actor_id uuid FK
  • flag_key text ●
  • environment_key text ●
  • before jsonb
  • after jsonb ●
  • created_at timestamptz ●

SQL functions POST /rest/v1/rpc/<name>

  • create_project(p_name text, p_slug text) → jsonb security definer
  • set_flag_config(p_flag_id bigint, p_environment_id bigint, p_enabled boolean, p_rollout integer, p_rules jsonb) → jsonb security definer
  • flag_snapshot(p_client_key text) → jsonb security definer

JavaScript functions Node.js

  • evaluate /functions/v1/evaluate public · 10s
community

Social Feed

A small social network backend. Users post text and images, follow, like and comment. A home_feed function returns posts from people you follow with like counts, paginated by cursor.

5 tables · 3 SQL functions · 1 bucket

Tables

profiles RLS · 3 policies
  • id uuid PK FK
  • username text ●
  • display_name text
  • bio text
  • avatar_path text
  • created_at timestamptz ●
posts RLS · 4 policies
  • id bigserial PK
  • author_id uuid FK ●
  • body text ●
  • image_path text
  • created_at timestamptz ●
comments RLS · 4 policies
  • id bigserial PK
  • post_id bigint FK ●
  • author_id uuid FK ●
  • body text ●
  • created_at timestamptz ●
follows RLS · 3 policies
  • id bigserial PK
  • follower_id uuid FK ●
  • followee_id uuid FK ●
  • created_at timestamptz ●
likes RLS · 3 policies
  • id bigserial PK
  • user_id uuid FK ●
  • post_id bigint FK ●
  • created_at timestamptz ●

SQL functions POST /rest/v1/rpc/<name>

  • home_feed(p_limit integer, p_before timestamptz, p_before_id bigint) → table(id bigint, author_id uuid, body text, image_path text, created_at timestamptz, like_count bigint, liked_by_me boolean, comment_count bigint)
  • follow_user(p_user_id uuid) → void
  • unfollow_user(p_user_id uuid) → void

Storage

  • post_images image/* public · 5MB · 3 policies
business

Helpdesk

Customers submit tickets without an account and follow them with a private link token. Agents reply, leave internal notes customers never see, and work to SLA due times. Intake is rate limited per email and globally.

5 tables · 4 SQL functions · 2 JS functions

Tables

agents RLS · 1 policy
  • user_id uuid PK FK
  • name text ●
  • role text ●
tickets RLS · 3 policies
  • id bigserial PK
  • public_token uuid ●
  • customer_email text ●
  • customer_name text
  • subject text ●
  • status text ●
  • priority text ●
  • assigned_to uuid FK
  • first_response_due_at timestamptz
  • resolution_due_at timestamptz
  • first_responded_at timestamptz
  • resolved_at timestamptz
  • created_at timestamptz ●
ticket_messages RLS · 3 policies
  • id bigserial PK
  • ticket_id bigint FK ●
  • kind text ●
  • author_id uuid FK
  • body text ●
  • created_at timestamptz ●
canned_replies RLS · 4 policies
  • id bigserial PK
  • title text ●
  • body text ●
intake_attempts RLS · 1 policy
  • id bigserial PK
  • bucket text ●
  • created_at timestamptz ●

SQL functions POST /rest/v1/rpc/<name>

  • is_admin() → boolean security definer
  • submit_ticket(p_email text, p_name text, p_subject text, p_body text) → table(ticket_id bigint, public_token uuid) security definer
  • ticket_thread(p_token uuid) → jsonb security definer
  • customer_reply(p_token uuid, p_body text) → bigint security definer

JavaScript functions Node.js

  • submit-ticket /functions/v1/submit-ticket public · 30s
  • reply-ticket /functions/v1/reply-ticket signed-in users · 30s

Works with the tools you already use

  • Cursor
  • Claude Code
  • supabase
  • PostgreSQL
  • docker
  • AWS Lambda
  • Amazon S3
  • MCP

001What you’re actually getting

The hard part isn’t building an app.
It’s everything behind it.

Auth, data, files and the rules about who can see what decide whether an app survives real users. With instancez that whole engine room is one readable file: quick to run on your laptop, and the same everywhere you deploy it.

Your whole backend is one file you can read

Tables, relationships and the access rule on every operation live in one instancez.yaml. This one says anyone can read posts but only the author can change theirs. Your agent writes it, you review it like any other code.

Running locally in seconds

inz dev --embedded-pg starts the full backend with its own Postgres: no Docker, no accounts, nothing else to install. Edits to the file reload as you save.

Local to staging to production, one file all the way

Build against inz dev, check with inz validate, deploy the same instancez.yaml to a staging project with --project, then ship production from CI with --yes. Every stage runs the same binary, so what passed in staging is what runs in production.

Auth, access policies, storage and functions, built in

Sign-in with password, magic link, OTP, Google or GitHub. Row-level security on every table. Buckets under the same rules. SQL and JavaScript functions when you need custom logic. All declared in the same file, all running in the same binary, which is open source.

002Infrastructure

You shouldn't need to hire an infrastructure team

Most tools leave you to run everything behind the app yourself, normally a hire, or three, the moment cost or a security review forces the issue.

How we solve it

instancez is one program. We host it and the database for you, or you run it yourself next to your own Postgres, one program instead of a stack of services, not a new hire.

Under the hood

A single Go binary, docker run it, drop it on Lambda, or run it on bare metal, pointed at a Postgres database you run.

003Portability

Your backend should move when you do

Backends get stuck where they were born: in one vendor's API, in settings that only exist in a dashboard, on a stack only one company knows how to run.

How we solve it

instancez is one config file and one binary. Move in from Supabase without touching your client, move from our cloud to your own servers and back with the same file, and take everything with you if you leave.

Under the hood

Your backend is instancez.yaml plus your Postgres data. The same Apache-2.0 binary runs hosted, in Docker, on Lambda or on bare metal, and speaks the supabase-js API everywhere, so clients never change.

Outcome

A local clinic's 8 GB Supabase instance was live again in under an hour, with no changes to their client code.

004Visibility

You should be able to see what the AI built

When AI builds your app by clicking around a control panel, nobody, not you, not a developer you hire later, can check its work.

How we solve it

Everything the AI builds is written down in plain, readable form, one file where every change is a diff you, or anyone you hire, can read and undo.

Under the hood

The whole backend is one declarative file, every table, relationship, and the exact access policy on each operation, tracked in git and reviewable in a pull request.

005Hosting

Want us to host the app too?

We run the backend your instancez.yaml describes, database included. Deploy it from your terminal, or let your agent do it from the session you’re already in.

Deploy from your terminal with inz

inz cloud deploy shows the diff against what’s live, asks before it changes anything, then uploads your YAML and function sources. Add --yes to run it from CI.

Or let your agent deploy over MCP

Connected over MCP, your agent reads the config docs, edits instancez.yaml, deploys it and waits for deploy_done, all inside the session you’re already in.

Why the AI gets it right

We built this to be the thing AI is already best at writing.

AI models learn from the code that already exists in the world. We deliberately built instancez to work the same way as the most widely used tool of its kind, so the AI is writing something it has seen millions of times rather than guessing at something new.

Concretely: we’re wire-compatible with @supabase/supabase-js, one of the most heavily represented client libraries in training data. A backend with a novel SDK fights the model’s priors on every call and pays for it in retries and invented methods.

From teams in production

Testimonial coming soon.

Al-Aqsa Community Clinic

Clinic records system, moved from Supabase

Testimonial coming soon.

ScheduleMatch

Multi-purpose scheduling system

Compared

instancez, Supabase and Neon

The short version. Developer experience, open source, platform and pricing are covered in full on the comparison page.

The differences that matter most
instancezSupabaseNeon
Client library@supabase/supabase-js, unchanged@supabase/supabase-jsNeon's own SDK (@neondatabase/neon-js)
SchemaOne declarative instancez.yaml, diffed and applied on deploySQL migrations from the CLI; declarative schemas availableSQL or ORM migrations (e.g. Drizzle); neon.ts declares services
Local developmentinz dev --embedded-pg: one binary, no Dockersupabase start: the full stack in DockerNeon Local proxies to a cloud branch; neon dev runs functions
Self-hostingThe same binary we host, plus your PostgresCommunity-supported Docker stack of 11 services, one projectManaged cloud only
RealtimeNot supported yetIncludedNot in the backend lineup
When idleNever pausedFree projects pause after a weekCompute scales to zero after 5 minutes
Paid entry$20/mo flat, extra projects $8/moFrom $25/mo, about $10/mo compute per extra projectUsage-based: $0.106 to $0.222 per compute-hour plus $0.35/GB-month
See the full comparison

Simple, transparent pricing

Free to start. $20/month once you're live. See full pricing →

Questions worth asking

Especially before you build something real on top of us.

What exactly does self-hosting give me?

The full backend: a single binary running Postgres-backed APIs, auth, storage, and functions on your own infrastructure, Docker, AWS Lambda, or bare metal. It is the same software that powers the hosted product, not a stripped-down community edition.

The one thing you bring is the database. When you self-host, you run Postgres yourself and point the binary at it with INSTANCEZ_DATABASE_URL. On our hosted plans, we run it for you.

Install the inz CLI with curl -fsSL https://get.instancez.ai | sh on macOS or Linux, or irm https://get.instancez.ai/windows | iex in PowerShell on Windows, then use it to run the backend.

I already use Supabase. Can I bring my code and my data?

Both, and two teams have already done it. instancez is wire-compatible with @supabase/supabase-js, so existing client calls, filters, embedded queries, aggregates, and RPCs work against a new URL and key, no application changes.

Data comes across with your schema, RLS policies, auth users, and storage objects intact. One of our two migrations so far was a local clinic’s 8 GB Supabase instance, live again in under an hour, with zero changes to their application code.

Do I own what gets built?

Yes. If you cancel, you walk away with a working backend and everything needed to keep running it, not a read-only copy or an export you can’t do anything with.

Nothing about your app is locked in a format only we can open. It’s all ordinary files you can hand to any developer.

Specifically: your schema, security policies and functions are plain YAML and JavaScript you can commit to your own repository, and the runtime they execute on is open source.

Can I see what the AI changed, and undo it?

Yes. Your whole backend is one configuration file, so every change the AI makes is a diff you can read line by line.

Keep that file under version control and the previous working state is always something you can read, diff and re-apply.

What happens if you raise your prices?

You can leave and take it with you. The software that runs your app is open source under Apache-2.0, with nothing held back for paying customers, so if our pricing ever stops making sense, running it yourself is a real option rather than a threat you can’t carry out. What you pay us for is not having to.

What happens to my app if instancez goes away?

It keeps running. Everything your app needs to work is open source and yours, so the worst case is that you or a developer you hire runs it on your own server instead of ours.

We’d rather answer that honestly now than have you find out the hard way. It’s also why we made leaving cheap on purpose, an insurance policy you can inspect before you trust us with anything.

Where does my data live, and do you train on it?

Hosted projects run on AWS in us-east-1. Each app gets its own Postgres database and roles, encrypted at rest, with TLS in transit. We don’t train models on your data or your prompts. If you need everything inside your own perimeter, self-host the runtime, or talk to us about Enterprise.

Still deciding? Talk to a cofounder, you will get an actual engineer, not a sales rep.

Ready to build?

Ship a production backend in minutes. No credit card required.