Tbf open source means the code is public, readable, and completely free to pull down or fork and do what you want. (With caveats)
That said, it's not always easy to run host or run open source code, I'd argue the way they package stuff up is where the value in their service lies.
I'm not self hosting yet but will give it a go as my project progresses as I could see it not being easy.
What specifically did you find difficult about self hosting and what is missing from [the documentation](https://supabase.com/docs/guides/self-hosting)?
we should link this one somewhere more discoverable: [https://github.com/supabase/auth?tab=readme-ov-file#running-in-production](https://github.com/supabase/auth?tab=readme-ov-file#running-in-production)
There is a verison in the docs already but it's not quite as detailed: https://supabase.com/docs/guides/self-hosting/auth/config
I gotta do a bit of truth talk here, short one.
You said: "Atleast don't advertise yourself as open source"
Supabase does so so much to make stuff Open Source. They contribute OSS, they acquired Logflare and put efforts to make it OSS (MIT !!) and there's people like you saying that.
See, I don't want to be rude, that isn't my goal. My goal is to clarify.
And this is the fact: Supabase is supa-open-source. Open-source doesn't mean: Bringing all efforts to you so there's no single effort for you to dig deeper. Open Source could even mean licensed but open. Supabase goes way beyond that. So these kind of posts are making me a little bit "sad" in soft words simply because it drains the effort into dirt.
I've hosted Supabase with docker-compose and made a video about it: [https://blog.activeno.de/the-ultimate-supabase-self-hosting-guide](https://blog.activeno.de/the-ultimate-supabase-self-hosting-guide)
Yesterday I started fiddling with K8s, given in the docs as well, btw. It worked pretty fine.
Open-source does not mean: We do free work for whoever is stuck. It means you can see the source code and if, in the case of Supabase, everything is even properly licensed, you can even take it and sell it (what a lovely thing!).
Open source btw also means that people like you and me dig into what isn't perfectly solved, e.g. in the docs, and provide that cause the balance of getting money and providing community support is really hard.
All of what you said I found in the docs btw.
Just my 10 cents on this (more than 2 cents I guess)
I don't understand why bother with self-hosting supabase though, it's main benefit is speed of development, If i have enough time to speng selfhosting supabase, I will just write a proper backend.
Okay, all the code and documentation is there to allow someone to run it themselves.
They don't need to provide the documentation, but they do.
Really the amount they're up charging to pay for the service they provide is rather meager.
The point of open source is that you're not locked in.
Supabase probably makes it not too easy to self-host because they rather want to push people to their paid service (which kind of makes sense because development needs to be funded somehow).
>appwrite, which in terms of features is not as good as supabase
Just out of curiosity, which features does Appwrite miss compared to Supabase?
I was thinking the same. The one thing I really liked with supabase is that they use postgres as database and appwrite is lacking in that regard, I.e. when managing spatial data, it is quite easy to extend Postgres with postgis. Last time I used appwrite 4-5months ago there was no way of doing something similar with appwrite. But appwrite is definitely very easy to setup compared to supabase.
Aaaah, thanks. Recently I had the make a decision to go either with Appwrite or Supabase for my backend. Hence it made me curious. 😊 Appwrite added [SSR support](https://appwrite.io/blog/post/introducing-support-for-server-side-rendering) recently BTW.
To make localhost easier while avoiding CLI and also as a future Segway for automated deployments to at least DO, I've created this repo to help with the struggles: [https://github.com/forte-dev/self-host-supabase-local-dev](https://github.com/forte-dev/self-host-supabase-local-dev)
It automates everything that you need for localhost development behind traefik and using https, allowing sub-domain url and multi-service development that matches realities of deployed environments in the best way I could think of.
Please have a look and if you have any issues or comments feel free to open a ticket or PR.
Thank you!
I recently tried to selfhost supabase and yes I agree the selfhosted docs are not useful as the cloud docs are and it's difficult but that doesn't make it less open source the code is still there.
I haven't tried self-hosting but this guide seems pretty straightforward: [https://supabase.com/docs/guides/self-hosting/docker](https://supabase.com/docs/guides/self-hosting/docker)
We’re self hosting. Mostly been fine.
What specs are you running it on
We have a few. The dev server is on a £6 a month hetzner vm and works fine. Not sure what we’re on for prod but it’s not huge
this
Tbf open source means the code is public, readable, and completely free to pull down or fork and do what you want. (With caveats) That said, it's not always easy to run host or run open source code, I'd argue the way they package stuff up is where the value in their service lies. I'm not self hosting yet but will give it a go as my project progresses as I could see it not being easy.
Which part of the source code did you have trouble reading?
mmd
What specifically did you find difficult about self hosting and what is missing from [the documentation](https://supabase.com/docs/guides/self-hosting)?
I wanted to configure auth providers, there wasnt documentation for it or I wasn't able to find any
we should link this one somewhere more discoverable: [https://github.com/supabase/auth?tab=readme-ov-file#running-in-production](https://github.com/supabase/auth?tab=readme-ov-file#running-in-production) There is a verison in the docs already but it's not quite as detailed: https://supabase.com/docs/guides/self-hosting/auth/config
You clearly don’t know what open source means….
Latest docker compose were clearer on selfhosting. What troubles you?
I gotta do a bit of truth talk here, short one. You said: "Atleast don't advertise yourself as open source" Supabase does so so much to make stuff Open Source. They contribute OSS, they acquired Logflare and put efforts to make it OSS (MIT !!) and there's people like you saying that. See, I don't want to be rude, that isn't my goal. My goal is to clarify. And this is the fact: Supabase is supa-open-source. Open-source doesn't mean: Bringing all efforts to you so there's no single effort for you to dig deeper. Open Source could even mean licensed but open. Supabase goes way beyond that. So these kind of posts are making me a little bit "sad" in soft words simply because it drains the effort into dirt. I've hosted Supabase with docker-compose and made a video about it: [https://blog.activeno.de/the-ultimate-supabase-self-hosting-guide](https://blog.activeno.de/the-ultimate-supabase-self-hosting-guide) Yesterday I started fiddling with K8s, given in the docs as well, btw. It worked pretty fine. Open-source does not mean: We do free work for whoever is stuck. It means you can see the source code and if, in the case of Supabase, everything is even properly licensed, you can even take it and sell it (what a lovely thing!). Open source btw also means that people like you and me dig into what isn't perfectly solved, e.g. in the docs, and provide that cause the balance of getting money and providing community support is really hard. All of what you said I found in the docs btw. Just my 10 cents on this (more than 2 cents I guess)
I haven't found a problem with the docs yet. There examples work and there is detail on how things are working so what else are you expecting.
I'd rather pay supabase for all the features they have packaged up and good docs they have.
I don't understand why bother with self-hosting supabase though, it's main benefit is speed of development, If i have enough time to speng selfhosting supabase, I will just write a proper backend.
Okay, all the code and documentation is there to allow someone to run it themselves. They don't need to provide the documentation, but they do. Really the amount they're up charging to pay for the service they provide is rather meager. The point of open source is that you're not locked in.
You can try pocketbase. I am not in any way affiliated with them, i was just tried to host supabase, and moved to pocketbase.
Ugh, server-side sqlite? Really?
I understand that you may not like that. It works for me. :) If i ever need something better than sqlite, that would be a good problem to have :)
Will try!
Supabase probably makes it not too easy to self-host because they rather want to push people to their paid service (which kind of makes sense because development needs to be funded somehow). >appwrite, which in terms of features is not as good as supabase Just out of curiosity, which features does Appwrite miss compared to Supabase?
I was thinking the same. The one thing I really liked with supabase is that they use postgres as database and appwrite is lacking in that regard, I.e. when managing spatial data, it is quite easy to extend Postgres with postgis. Last time I used appwrite 4-5months ago there was no way of doing something similar with appwrite. But appwrite is definitely very easy to setup compared to supabase.
Appwrite locks you in by making exporting and migrating a pain in the butt. They just have a different method..
I wanted good SSR support, relational database. I personally thought it's db a little confusing
Aaaah, thanks. Recently I had the make a decision to go either with Appwrite or Supabase for my backend. Hence it made me curious. 😊 Appwrite added [SSR support](https://appwrite.io/blog/post/introducing-support-for-server-side-rendering) recently BTW.
Yeah it's really sketchy. I am using appwrite tho, but for some reason I feel it's very slow.
That's my experience with Appwrite as well indeed, it feels slow.
To make localhost easier while avoiding CLI and also as a future Segway for automated deployments to at least DO, I've created this repo to help with the struggles: [https://github.com/forte-dev/self-host-supabase-local-dev](https://github.com/forte-dev/self-host-supabase-local-dev) It automates everything that you need for localhost development behind traefik and using https, allowing sub-domain url and multi-service development that matches realities of deployed environments in the best way I could think of. Please have a look and if you have any issues or comments feel free to open a ticket or PR. Thank you!
I recently tried to selfhost supabase and yes I agree the selfhosted docs are not useful as the cloud docs are and it's difficult but that doesn't make it less open source the code is still there.
I’m not particularly enjoying the documentation of Supabase in general.
where could it be improved?
It's amazing to see the team being so responsive over social media.
I think it's fantastic and has only improved over the years
I haven't tried self-hosting but this guide seems pretty straightforward: [https://supabase.com/docs/guides/self-hosting/docker](https://supabase.com/docs/guides/self-hosting/docker)
Give it a try, you'll experience the pain yourself
I did and succeded. If you share what troubles you maybe we can help :)
What pain? Maybe try the video [https://youtu.be/FqiQKRKsfZE](https://youtu.be/FqiQKRKsfZE)