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.
Developer & LLM-Friendly Supabase drop-in replacement.
claude mcp add instancez --transport http https://my.instancez.ai/mcp curl -fsSL https://get.instancez.ai | shTemplates
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.
Works with the tools you already use
001What you’re actually getting
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.
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.
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.
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.
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
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.
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.
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
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.
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.
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
When AI builds your app by clicking around a control panel, nobody, not you, not a developer you hire later, can check its work.
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.
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
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.
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.
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
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
The short version. Developer experience, open source, platform and pricing are covered in full on the comparison page.
| instancez | Supabase | Neon | |
|---|---|---|---|
| Client library | @supabase/supabase-js, unchanged | @supabase/supabase-js | Neon's own SDK (@neondatabase/neon-js) |
| Schema | One declarative instancez.yaml, diffed and applied on deploy | SQL migrations from the CLI; declarative schemas available | SQL or ORM migrations (e.g. Drizzle); neon.ts declares services |
| Local development | inz dev --embedded-pg: one binary, no Docker | supabase start: the full stack in Docker | Neon Local proxies to a cloud branch; neon dev runs functions |
| Self-hosting | The same binary we host, plus your Postgres | Community-supported Docker stack of 11 services, one project | Managed cloud only |
| Realtime | Not supported yet | Included | Not in the backend lineup |
| When idle | Never paused | Free projects pause after a week | Compute scales to zero after 5 minutes |
| Paid entry | $20/mo flat, extra projects $8/mo | From $25/mo, about $10/mo compute per extra project | Usage-based: $0.106 to $0.222 per compute-hour plus $0.35/GB-month |
Especially before you build something real on top of us.
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.
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.
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.
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.
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.
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.
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.
Ship a production backend in minutes. No credit card required.