_aantti

It's more like $25 for the org + one project, then you can add more projects and the costs are based on the [compute pricing](https://supabase.com/docs/guides/platform/manage-your-usage/compute). E.g., adding a second project to the org is +$10/month I believe :)

It's definitely not 1:1 platform, but it's very close to having the same kind of a single project per a single self-hosted instance. There's a note on the differences [here](https://supabase.com/docs/guides/self-hosting), and there's a new [features](https://supabase.com/features) page that has a filter for "self-hosted."

You can check https://supabase.com/docs/guides/self-hosting - the main guide and the how-tos :) Also the [readme](https://github.com/supabase/supabase/blob/master/docker/README.md) and the [changelog](https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md). Several third-party deployment options might also help (Coolify, etc.), though maintained by separate communities.

Thanks for the kind feedback re self-hosted here :)

Check https://supabase.com/docs/guides/self-hosting (the main guide and how-to's). There's a lot of 3rd party blogs describing other solutions based on this upstream configuration.

Thanks for sharing!

I've recently added a how-to here - https://supabase.com/docs/guides/self-hosting/self-hosted-functions :) (and [this](https://supabase.com/docs/guides/self-hosting/restore-from-platform) too). There could be gotchas, it's hard to predict everything, but I've been adding the most common ones to the troubleshooting sections across the how-to's. If you are on Pg 17, make sure to read [this one](https://supabase.com/docs/guides/self-hosting/postgres-upgrade-17) - the default in [self-hosted Supabase](https://supabase.com/docs/guides/self-hosting) is still Pg 15. You can also join the Supabase's [Discord server](https://discord.supabase.com/) and ask for help if needed. I don't think "self-hosted edge runtime is still in beta," though. Hope this helps.

Hopefully, I've made a note in my todo :)

There's this timeless classics here - https://www.youtube.com/watch?v=nyX_EygplXQ (via u/activenode). I've also recently worked on a draft of a "workflows"-centric [how-to](https://github.com/supabase/supabase/blob/cli/docs-example-how-to/apps/docs/content/guides/local-development/cli-workflows.mdx), just to see if it might be useful.

🖖

Thanks for sharing! Glad it worked for you. Re Kong - there's a WIP to have Envoy instead (and I also finally updated Kong to 3.9.1 recently). I'd be also curious to hear about the migration to the [new API keys](https://supabase.com/docs/guides/self-hosting/self-hosted-auth-keys) and asymmetric auth if you decide to do it at some point. Re "the self-hosted repo moves fast" - make sure to check the [changelog](https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md), but yes - I have to add frequent changes these days to catch up on the accumulated backlog, while also trying to make sure everything still works :)

Re: > without losing my mind over changing .env variables and docker-compose structures I'm trying to leave the hints in the [changelog](https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md), but some inconvenience is unavoidable as I'm currently working on some serious backlog for self-hosted (new auth, upgrade to Pg 17, replacing Kong, etc.)

A good question. So far there's no a "release tag" for self-hosted because it's all inside the `docker/` in the main repo. The tag you've mentioned is basically for Studio. For now, I'd suggest checking the [changelog](https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md) and pulling the latest changes for self-hosted.

It looks like you've also changed the `- db-config:/etc/postgresql-custom` to a bind mount.

Also - more how-to's here, on the left :) https://supabase.com/docs/guides/self-hosting

https://supabase.com/docs/guides/self-hosting/self-hosted-functions :)

Can you describe what kind of a flow you have on platform? Do you actively use CLI for isolated local development, a staging project, and a production project? What would "environments" mean for you in self-hosted?

Appreciate the kind words!

Yeah, sure, always helpful to study other examples! For self-hosted I'll probably need a simplified one, though - and would mimic the one we have on platform. For the community Helm chart seeing a more elaborate Envoy config might be very useful! Re Helm chart - correct, it had been on pause for over a year, but maintenance restarted with a new mantainer in Dec - should all be functional and improving now.

😅

Can be an interesting complement to https://github.com/supabase-community/supabase-kubernetes/ :) Re Envoy - this is also planned for [self-hosted Supabase](https://supabase.com/docs/guides/self-hosting), need to switch.

- https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md - https://github.com/supabase/supabase/blob/master/docker/README.md :)

Ah, ok, argh :) > i personally would have written like 10 ... lines of documentation That'd be me as well. > How does that work, are you external and part-time to update docs? No, I'm fulltime and the "self-hosting lead." What I meant was - documentation is just part of the job, and arguably the hardest one :) So I do ofc appreciate tools like Claude Code. Researching across 10 different Supabase repos and 6 programming languages (TS, Go, Elixir, Haskell, C, and Rust!) is otherwise a superhuman job, I guess.

Good news, thanks for sharing :)

I am motivated :) Btw, yes, maintaining a solid upstream configuration for any other 3rd party deployment options is also one of my goals.

👀

> not all features are available in self-hosted What are you missing, btw? (Also - thanks for being a customer!)

🖖🙏🤝

Well... It definitely helps, but I have to spend quite a bit of time on researching the topic, aligning on structure, copyediting, removing fluff, and testing various configurations. I'm not a technical writer and writing documentation is also not my fulltime job, so adopting tools like Claude Code definitely helped. Do you see any "slop"? Happy to see PRs with improvements :)

Netbird is great, very cool team out of Berlin! I have to add a how-to along these lines - or feel free to submit a draft writing.

Working on it :)

I keep adding, bear with me :) (Added 3 new docs PRs just today, lol)

Coolify template for self-hosted Supabase while based on our official upstream configuration https://github.com/supabase/supabase/tree/master/docker is quite different and maintained by the Coolify community. Checking Discord might be more efficient for this kind of questions - Coolify's server is very active, and you can also try asking in Supabase's.

Appreciate the feeback! I've recently added a few how-to's guides for self-hosted Supabase and working on more - see here https://supabase.com/docs/guides/self-hosting Accurate and thoughtful PRs to the docs and how'to are always welcome. Btw, I've created a [changelog](https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md) for self-hosted - might be useful to check. Also - a good and fair discussion in [#39820](https://github.com/orgs/supabase/discussions/39820). Last but not least - I've been seeing people using [local development & CLI](https://supabase.com/docs/guides/cli) as "self-hosted" - this is something never to be done. CLI was never intended to be used in an external environment.

Do you mean [local development & CLI](https://supabase.com/docs/guides/cli), or [self-hosted Supabase](https://supabase.com/docs/guides/self-hosting)? The limits are configured in the `main` worker code - see, e.g., [here](https://github.com/supabase/supabase/blob/master/docker/volumes/functions/main/index.ts) for self-hosted, and [here](https://github.com/supabase/cli/blob/main/internal/functions/serve/templates/main.ts) (I believe!) for CLI.

A good question :) It's more along the lines of why add the publishable key to each "unauthenticated user" request in the `apikey` header when it still translates into the `anon` role - correct? If that's what you are asking, then technically yes, at the component level it might not be needed or make sense, but at the API gateway level it still makes sense to filter out random requests without the public API key. u/Tinpotray [mentioned](https://www.reddit.com/r/Supabase/comments/1rfpwcw/comment/o7m2380/) it fairly accurately :) Even though the key is basically as public as it is - it still requires someone to go, find it in your code, add it to their code, and start using it in the wrong way. However, at the API gateway level it's then still a distinct flow of requests vs. completely anonymous traffic. Ask yourself this - if there's a wrong traffic hitting your application, how would the provider know which are still valid requests and which aren't. Basically, if there's a malicious use, it's easier then to filter it out, and change (rotate) them keys. In fact, that has been one of the main considerations about the migration from the legacy JWT-token format API keys to the new opaque keys. Functions have historically had a little bit of a loose approach to enforcing authentication, but there's currently an ongoing project to make it more straightforward and easier to understand. You can totally have your own verification logic in any function based on either the Supabase API keys or your own API tokens. Does it make sense? :)

No, the new opaque API keys are just strings, not signed :) Internally they translate into signed keys.

Check the following how-to guides :) - https://supabase.com/docs/guides/self-hosting/self-hosted-s3 - https://supabase.com/docs/guides/self-hosting/copy-from-platform-s3 Make sure to check the [CHANGELOG](https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md) and update your self-hosted Supabase [configuration](https://github.com/supabase/supabase/tree/master/docker) accordingly.

Added a couple of how-to's here: - https://supabase.com/docs/guides/self-hosting/self-hosted-s3 - https://supabase.com/docs/guides/self-hosting/copy-from-platform-s3

I think some of it may come quite soon with the new Multigres option.

To the best of my knowledge everyone takes is very seriously and there will be a detailed, honest postmortem shortly.

Wasn't intentional, to the best of my knowledge. Also being backtracked atm. There will be a detailed postmortem.

Current [self-hosted](https://supabase.com/docs/guides/self-hosting) Supabase [configuration](https://github.com/supabase/supabase/tree/master/docker) seems to work just fine with the pre-built arm64 [images](https://hub.docker.com/search?q=supabase) (e.g., on M-series Macbooks, etc.) If you encounter any difficulties, please open an [issue](https://github.com/supabase/supabase/issues) 🖖

There's a discussion [#39820](https://github.com/orgs/supabase/discussions/39820) related to this kind of feedback - feel free to check. On [Discord](discord.supabase.com) there was also a long thread that might be useful - look for "Self-hosted Supabase vs Cloud: Migration/Backups, Limits, Feature-Parity and Upgrade-Process" from Feb 1, 2026.

Bizarre :) But glad it's gone.

Also, out of curiosity - what environment is this and is it with Docker or Podman or else?

There's quite a bit of change with how CLI now defaults to using asymmetric keys. I've left a bit more detailed explanations in [cli#4524](https://github.com/supabase/cli/issues/4524). If you prefer to not change anything in your application and still use the legacy api keys for a while, you'll have to downgrade CLI. A recommendation would be to start planning to migrate to the new asymmetric JWT tokens and the new opaque api keys (`sb_publishable_` and `sb_secret_`). You can read more here: https://supabase.com/docs/guides/auth/signing-keys https://supabase.com/docs/guides/api/api-keys

Unfortunately Coolify makes it both easier (to install) and harder (to properly configure and run) atm - which leads to a suboptimal experience. It's an external integration / deployment option that the team here at Supabase doesn't have much influence on. Sadly, current Coolify template for self-hosting Supabase is lagging behind. I'm hoping it becomes a properly and regularly maintained part of Coolify at some point.

That would be indeed a workaround.

This is currently being reviewed. My understanding about backward compatibility was along the same lines as yours.