[mateomorris]

If you really care about open source software, as you seem to, you should know that attitudes and statements like this are just about the worst thing for it. Self-hosting isn’t the only benefit or purpose of OSS. It’s fair to point out that it isn’t easy to self-host, but consider doing it without being poisonous.

[arcturus17]

> Self-hosting isn’t the only benefit or purpose of OSS

I would say that making self-hosting difficult is completely against the spirit of OSS.

I certainly wouldn't expect an OSS technology to lock me in. At that point it just becomes a privative technology that builds upon open source and exposes its interfaces.

And I say this as someone who very regularly makes strong cases for the hosted solution in a make vs. buy scenarios, and would therefore probably argue to pay for Supabase hosting instead of complicating everyone's lives in my organization.

[kiwicopple]

That's a fair criticism. We've looked closely at everyone's comments and it's obvious that we need to make self-hosting Supabase much easier. This has always been the intention and has always been possible: everything except our dashboard has OSI-compatible licenses, so anyone can run the same back end that we do.

But "technically possible" isn't good enough. It needs to be straightforward, and we're going to invest some effort into making it so. The only thing I'll say in our defence is that this didn't happen for business reasons, i.e. there's no secret plan to hobble the self-hosted version. Quite the opposite, we want the open-source tech to be super easy for everyone to run. We only want people to pay us because our paid product is valuable, not because the free tech is somehow hard to use. We only introduced billing yesterday, and we aren't charging anyone yet. But from the feedback, I understand why this wasn't obvious. It needs to be much clearer how to put the pieces together and we're going to prioritise this now.

I have started updating [0] our docs in this PR [1]. We will merge this tomorrow morning as part of our CLI release [2]. The Docker setup in this PR is 100% compatible with every project on Supabase, and we also link to several of the one-click tools which we have deployed into the AWS and Digital Ocean marketplaces. All this still needs improvement, this is just a first step. If anyone still has trouble setting up a self-hosted version of Supabase, please contact me (my email is in my profile) and I'll personally do whatever it takes to get you up and running. Then I'll update the docs some more so those difficulties won't happen again. Hopefully with a few more iterations this will be as smooth as it should be. The tech is there and 100% ready to go.

[0] Preview: https://docs-git-docs-self-hosting-supabase.vercel.app/docs/...

[1] PR: https://github.com/supabase/supabase/pull/999

[2] CLI release: https://supabase.io/blog/2021/03/25/launch-week#wednesday-cl...

[nightowl_games]

I'm just an observer, but this response seems pretty top tier. I've seen your posts here for a while... I think the issue stems from a lack of clarity about what is free/open source, and what is proprietary. Ive read all your releases and am just now seeing that the dashboard is proprietary. Just to be clear, I'm not criticising the business model, but am just providing my 2 cents on a potential cause for "backlash" - namely, clarity in pricing.

Nakama is a similar open source + commercial hosting model. I think the model is strong and we will see it proliferate in the future. You simply can't beat the development power that a good open source ecosystem can bring.

[clairity]

this is what soured me on piwik (now matomo) as a self-hosted web analytics solution. they allow you to self-host, but make it difficult to automate updates, to steer you to their hosting service instead.

[nightowl_games]

What is the difference between "make it difficult" and "don't include"? They gotta keep some features in their hosting service, don't they?

[clairity]

it’s been a couple years now, so i don’t remember the details, but i tried to workaround the limitations and came away with the conclusion that automating upgrades was intentionally crippled rather than simply neglected. there was no documentation on it, and it was explicitly touted as a feature of the hosted product.

the problem is one of messaging and positioning in line with the parent comment’s criticisms. instead of calling the non-hosted version a limited demo, the implied claim is that the non-hosted version is ‘production-ready’. but ‘upgrades’ were fresh reinstalls, complete with database integrity issues at stake. it was clearly a gotcha situation to steer you quickly to the hosted version (rather than being upfront about this significant limitation).