4 ms·
> one golang binary which embeds everything supabase offers I understand the sentiment here, but truthfully we chose an architecture that scales, then made it
by 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 agoLook 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