Yes! `supabase init` and `supabase start` gets most of the way there! Customizing the ports in `supabase/config.toml` makes having multiple supabase instances running easy. This works great for all the Postgres, auth, and storage things, as well as real-time functionality. My engineers have a single package.json script to get everything up and running.

I work at an agency, and the dev teams run supabase locally. We use Prisma for migrations and maintaining our SQL functions and storage configurations. `supabase stop --backup` is our friend.

Not being able to run multiple edge functions at a time kept us leaning into Cloud Run and Cloudflare. I'm excited about today's announcement.

Hey there - Tim here from Supabase! We have some options to explore here so probably best to connect on a call to get a better understanding of your project and how we can best align to help! Can you send me an email on [email protected] and we can tee up a time? Cheers, Tim

I have run self hosted Supabase for awhile in Kubernetes. One of the main gotchas I will warn against is becoming too attached to the CLI, as it’s currently quite tied to assumptions that you’re using hosted Supabase.

Also be prepared to do your own infra work if you want something scalable and production ready. The HA guarantees are kind of “bring your own” eg not really there out of the box and IMO the default docker compose setup provided, while thorough and working, serves as more of a proof of concept of the system than something you should actually be running in production.

On the Supabase team here as well.

Self-hosting is easier said than done. You can do it, but maintaining the infra, scaling, performance, security, updates, downtime, all of that is a _giant_ overhead. It's not against our business model for self-hosting to not work well. Everything we do is open-source and we don't "supplement" it with features from closed source code.