Hi HN. I built instancez over the last year because I wanted Supabase's developer experience (I love supabase!) defined in one-file, but also be portable and run in a serverless. Self-hosting it means a dozen containers, and for small projects that always felt like more infrastructure than the app itself.
Instancez is a single binary that sits in front of Postgres. You describe tables, buckets, code/edge functions in one instancez.yaml file. It runs the migrations (based on how the YAML changes - think Terraform/Pulumi for state management) and serves a PostgREST-compatible API. It speaks the same wire protocol as supabase-js (or any Supabase client), so existing client code works if you change the URL.
What works today: admin dashboard, auth (user management, password, magic link, OTP, OAuth, anonymous, TOTP MFA) tied into Postgres RLS. Filtering, embeds, aggregates, and RPC on the API. Custom JS/Node functions are supported. Storage on local disk or S3-compatible system, with bucket policies going through RLS like everything else.
What to expect going forward: Although I have tested things heavily on my own and with friends, I intend to make this more robust and stable. Then, the plan is to add more features to make it appeal for more use-cases. For example, built-in RBAC, simple OTel wiring, Team/Org structure, cron/scheduled jobs, and more.
What's not supported: this is obviously an open-ended list, but a main supabase feature that isn't supported is realtime/channels. We plan on doing that in a way that still allows for serverless operation (hopefully!).
Let me know what you think and I'll be happy with any kind of feedback! Also, please mention any features that would be a dealbreaker for you or you would just like to see!
Hi HN. I built instancez over the last year because I wanted Supabase's developer experience (I love supabase!) defined in one-file, but also be portable and run in a serverless. Self-hosting it means a dozen containers, and for small projects that always felt like more infrastructure than the app itself. Instancez is a single binary that sits in front of Postgres. You describe tables, buckets, code/edge functions in one instancez.yaml file. It runs the migrations (based on how the YAML changes - think Terraform/Pulumi for state management) and serves a PostgREST-compatible API. It speaks the same wire protocol as supabase-js (or any Supabase client), so existing client code works if you change the URL.
What works today: admin dashboard, auth (user management, password, magic link, OTP, OAuth, anonymous, TOTP MFA) tied into Postgres RLS. Filtering, embeds, aggregates, and RPC on the API. Custom JS/Node functions are supported. Storage on local disk or S3-compatible system, with bucket policies going through RLS like everything else.
What to expect going forward: Although I have tested things heavily on my own and with friends, I intend to make this more robust and stable. Then, the plan is to add more features to make it appeal for more use-cases. For example, built-in RBAC, simple OTel wiring, Team/Org structure, cron/scheduled jobs, and more.
What's not supported: this is obviously an open-ended list, but a main supabase feature that isn't supported is realtime/channels. We plan on doing that in a way that still allows for serverless operation (hopefully!).
Let me know what you think and I'll be happy with any kind of feedback! Also, please mention any features that would be a dealbreaker for you or you would just like to see!