3 ms·

I'm not supabase client, so I guess my wishes do not matter much, but I'm self-hosting it and the experience was not pleasant. They just gave me some huge docke

I'm not supabase client, so I guess my wishes do not matter much, but I'm self-hosting it and the experience was not pleasant. They just gave me some huge docker-compose with barely any documentation about it and that's about it. My approach to self-hosting software is carefully learn about every service I'm going to run, disabling everything not needed for my use-case. That was not possible with supabase without significant time investments. So my wish would be for supabase to provide some kind of minimal bare-bones configuration and careful documentation for their monstrous docker-compose configuration with explanations why all parameters were set to non-default values. I don't think that I need all those services if I don't use any of them except database and sometimes admin UI. Also I think that I even had to edit some configs for api keys or something like that. It should not be like that, everything should be passed down via envs. Right now I've set up supabase for our developers but asked them to migrate to plain postgres as soon as possible, so I could move production workloads to our standard setup. My ideal setup would be one postgres instance which I can install myself from plain docker library image; one golang binary which embeds everything supabase offers turned off but with some envs to enable and that's about it.

kiwicopple 3y ago
> one golang binary which embeds everything supabase offers I understand the sentiment here, but truthfully we chose an architecture that scales, then made it as easy as possible to run. Each service has very different scaling requirements: connection poolers, auto-generated APIs, Auth servers, etc. Putting them in a single binary would trade one problem for another (IMO, bigger) problem > Also I think that I even had to edit some configs for api keys or something like that. It should not be like that, everything should be passed down via envs. I think you're referring to the "Securing your services"[0] section right? These are all stored as env vars - perhaps that's not clear from the docs? [0] https://supabase.com/docs/guides/self-hosting/docker#securing-your-services https://supabase.com/docs/guides/self-hosting/docker#securin...
- vbezhenar 3y ago
  Look at Grafana Loki. They have single binary which serves many different roles. You can launch it with different flags for scalable setup, so each instance would serve a different role. Yet you can just launch one instance and it'll do it all by default. I'm using it with this approach and it works just fine for my log volume. And I have the way to scale if I would hit limits. May be it's not elegant to have multiple services in the one binary, but disk space is cheap and code does not take much amount. > I think you're referring to the "Securing your services"[0] section right? These are all stored as env vars - perhaps that's not clear from the docs? I'm talking about docker/volumes/logs/vector.yml. There's "api_key=your-super-secret-and-long-logflare-key" which is supposedly should be replaced by the actual logflare api key value. The guide does not instruct to change LOGFLARE_API_KEY but I guessed this key is there for a reason and should be changed.
  - kiwicopple 3y ago
    > I'm talking about docker/volumes/logs/vector.yml I've flagged this to the Logs team to fix immediately > Look at Grafana Loki I'll check it out thanks. My gut is that running Postgres + 4/5 other services (many different languages) is a harder beast than Loki, but understand the sentiment and we'll see what we can do here edit: we've fixed the yml file: https://github.com/supabase/supabase/pull/22860#pullrequestreview-2008329563 https://github.com/supabase/supabase/pull/22860#pullrequestr... thanks for flagging this. If anyone else spots things like this please feel free to open a GH issue so we can amend it asap - given enough eyeballs, all bugs are shallow

kiwicopple 3y ago

> one golang binary which embeds everything supabase offers I understand the sentiment here, but truthfully we chose an architecture that scales, then made it as easy as possible to run. Each service has very different scaling requirements: connection poolers, auto-generated APIs, Auth servers, etc. Putting them in a single binary would trade one problem for another (IMO, bigger) problem > Also I think that I even had to edit some configs for api keys or something like that. It should not be like that, everything should be passed down via envs. I think you're referring to the "Securing your services"[0] section right? These are all stored as env vars - perhaps that's not clear from the docs? [0] https://supabase.com/docs/guides/self-hosting/docker#securing-your-services https://supabase.com/docs/guides/self-hosting/docker#securin...

vbezhenar 3y ago
Look at Grafana Loki. They have single binary which serves many different roles. You can launch it with different flags for scalable setup, so each instance would serve a different role. Yet you can just launch one instance and it'll do it all by default. I'm using it with this approach and it works just fine for my log volume. And I have the way to scale if I would hit limits. May be it's not elegant to have multiple services in the one binary, but disk space is cheap and code does not take much amount. > I think you're referring to the "Securing your services"[0] section right? These are all stored as env vars - perhaps that's not clear from the docs? I'm talking about docker/volumes/logs/vector.yml. There's "api_key=your-super-secret-and-long-logflare-key" which is supposedly should be replaced by the actual logflare api key value. The guide does not instruct to change LOGFLARE_API_KEY but I guessed this key is there for a reason and should be changed.
- kiwicopple 3y ago
  > I'm talking about docker/volumes/logs/vector.yml I've flagged this to the Logs team to fix immediately > Look at Grafana Loki I'll check it out thanks. My gut is that running Postgres + 4/5 other services (many different languages) is a harder beast than Loki, but understand the sentiment and we'll see what we can do here edit: we've fixed the yml file: https://github.com/supabase/supabase/pull/22860#pullrequestreview-2008329563 https://github.com/supabase/supabase/pull/22860#pullrequestr... thanks for flagging this. If anyone else spots things like this please feel free to open a GH issue so we can amend it asap - given enough eyeballs, all bugs are shallow