Hi HN, I'm one of the makers of instancez. I built it over the last year because I wanted Supabase's developer experience in a single file that is portable and can run anywhere. Self-hosting Supabase means a dozen containers, which feels heavy for small projects.
instancez is a single binary (or container) that sits in front of Postgres. Tables, buckets, functions and RLS policies live in one instancez.yaml. On start it diffs the file against your database and applies only the change, and drops need an explicit flag. It serves a PostgREST-compatible API, so supabase-js works if you change the URL. We test against the real supabase-js client in CI.
Working today: an admin dashboard; auth (passwords, magic links, OTP, OAuth including Apple, anonymous, TOTP MFA) tied to Postgres RLS; filtering, embeds (including many-to-many), aggregates and RPC; JS/Node functions; storage on local disk or S3-compatible systems with RLS-based bucket policies.
New since I last posted: `inz vet` lints your YAML for security problems (open or missing RLS, hardcoded secrets, unsafe CORS), and the dashboard shows the same findings with a one-click fix. Dashboard edits are written back to instancez.yaml as a diff you review before it applies. The same file moves from dev to staging to prod.
Not supported yet: realtime/channels (planned, in a way that still works serverless) and phone/SMS auth.
Try it: `curl -fsSL https://get.instancez.ai | sh`, then `inz init` and `inz dev --embedded-pg`.
I'd love feedback, especially on dealbreakers or what you'd want before moving a project over.
Hi HN, I'm one of the makers of instancez. I built it over the last year because I wanted Supabase's developer experience in a single file that is portable and can run anywhere. Self-hosting Supabase means a dozen containers, which feels heavy for small projects.
instancez is a single binary (or container) that sits in front of Postgres. Tables, buckets, functions and RLS policies live in one instancez.yaml. On start it diffs the file against your database and applies only the change, and drops need an explicit flag. It serves a PostgREST-compatible API, so supabase-js works if you change the URL. We test against the real supabase-js client in CI.
Working today: an admin dashboard; auth (passwords, magic links, OTP, OAuth including Apple, anonymous, TOTP MFA) tied to Postgres RLS; filtering, embeds (including many-to-many), aggregates and RPC; JS/Node functions; storage on local disk or S3-compatible systems with RLS-based bucket policies.
New since I last posted: `inz vet` lints your YAML for security problems (open or missing RLS, hardcoded secrets, unsafe CORS), and the dashboard shows the same findings with a one-click fix. Dashboard edits are written back to instancez.yaml as a diff you review before it applies. The same file moves from dev to staging to prod.
Not supported yet: realtime/channels (planned, in a way that still works serverless) and phone/SMS auth.
Try it: `curl -fsSL https://get.instancez.ai | sh`, then `inz init` and `inz dev --embedded-pg`.
I'd love feedback, especially on dealbreakers or what you'd want before moving a project over.