Running Supabase

[saashqdev]

We'd like to setup a dev environment that utilizes Supabase where we could run multiple Supabase instances. We're mainly looking to setup dev/staging/prod. My question is, do we need to modify the current Supabase Helm charts to run with Gefyra/GetDeck environment? Or would we need to convert the Helm charts to an operator type format. Cheers, Dave

[Schille]

Hi @saashqdev
You want to run these Supabase instances on K8s, right? Nice choice.

Given you are using the official Supabase Helm charts from here https://github.com/supabase-community/supabase-kubernetes/
you are free to deploy as many Supabase instances as you want (and your cluster can stand. :)
You can go with different release names, namespaces, etc.

As for Gefyra, you connect to the cluster (no special tweak here), and select the Supabase instance using the FQDN of your instance's API service when running your local container. At Blueshoe, we use environment variables at the app container for this. For example, with
gefyra run [...] -e SUPABASE_SVC=supabase.staging.svc.cluster.local
you can connect a local container to that instance (given you use the default cluster domain and your code reads that config from env).

Is that helpful?

[saashqdev]

Wow, that's super helpful. I'll give that a try. Thanks a lot. Cheers, Dave

btw: Could I run the multiple instances on GetDeck? Our ultimate goal is to spin up a new Supabase instance when somebody creates a new project in our web app.

[Schille]

Getdeck is primarily for (local) Dev environments. If you want something like a "click-to-install" experience, a custom K8s operator can be useful. At Blueshoe, we have written several custom operators and offer services to help you with that.
Depending on your specific use case, you can explore the possibilities of fluxcd, argocd, or other tools to dynamically provision workloads on a K8s cluster, too.

[saashqdev]

Great, thanks for the info.