> Is this practical? Depends on the definition of practical :) You can make it work this way for sure, but the drift related to various changes/updates on platform might add a noticeable overhead. You'll have to set up replication, match api/signing keys, etc. - it's a tangible amount of work, but doable.
The status page has been [updated](https://status.supabase.com/), it's affecting all regions atm.
Here's an update from the support team: The `supabase_admin` connection attempts were coming from an internal Supabase platform health check which resulted in `FATAL: database "supabase_admin" does not exist` in the Postgres logs even though the database was otherwise healthy. This was a log noise on our side. It shouldn't have affected queries or normal application traffic, and you do not need to make any changes. A follow-up fix is being rolled out on our side automatically to stop these noisy log entries.
The "supabase_admin" log entries issue is being addressed, it's an accidental "logs-only" issue - apologies.
If anything is unclear or not accurate, let me know :)
> The scripts themselves are nothing special: mostly pg_dump/psql for Postgres, This should work just fine :)
Tbh, not sure what was meant by the "lose nice dashboard" :) Studio/Dashboard has been part of the self-hosted configuration, and a lot of things in it generally match the platform experience. What's missing in the UI is related to the absent platform features (as briefly described on the overview page, and on the /features page).
If I'm reading the question correctly, it's via Project settings > API Keys > New publishable key
> We use Storage, Auth (with passkeys, asym keys, MFA, the Resend integration, …), a few functions, the Database with PostgreSQL v17 of course, RLS and a bit of Realtime. We also plan to use Queues for a future use-case. This should generally work, but will require quite a bit of manual setup - esp. with regard to Auth. See here: - https://supabase.com/docs/guides/self-hosting (plus the how-to guides on the left) - https://github.com/supabase/supabase/tree/master/docker - https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md - https://github.com/supabase/supabase/blob/master/docker/CONFIG.md Regarding "what is included and what is not": - https://supabase.com/docs/guides/self-hosting#how-self-hosted-supabase-differs - https://supabase.com/features This one might be worth checking as well: - https://github.com/orgs/supabase/discussions/39820 Hope this helps
There's now... (updated status...)
A note re "Run `supabase start` - this spins up all the Docker containers [...] you'll get your local URLs, API keys, and connection string." - this describes [CLI](https://supabase.com/docs/guides/local-development) - which is **not intented to ever be exposed to any external traffic**.
There's an example configuration for both [Caddy and nginx](https://supabase.com/docs/guides/self-hosting/self-hosted-proxy-https) for [self-hosted Supabase](https://supabase.com/docs/guides/self-hosting/docker) here: https://github.com/supabase/supabase/tree/master/docker/volumes/proxy It should give you a good reference, I'm thinking. You don't have to have a separate route for Studio - that's specifically for a self-hosted instance, where Studio is behind basic HTTP auth. Hope this helps
There's also this :) https://supabase.com/docs/guides/getting-started/architecture#everything-works-in-isolation
💪
Also, https://github.com/orgs/supabase/discussions/45329
No need to link/login for db dump.
Yes, `db dump` should work. Just tried it with the latest CLI (via `npx supabase [...]` [along the lines of](https://supabase.com/docs/guides/self-hosting/restore-from-platform#step-2-back-up-your-platform-database): ``` supabase db dump --db-url "postgresql://postgres.your-tenant-id:c29cb6cfa177d36c8@sh.example.com:5432/postgres" -f roles.sql --role-only supabase db dump --db-url "postgresql://postgres.your-tenant-id:c29cb6cfa177d36c8@sh.example.com:5432/postgres" -f schema.sql supabase db dump --db-url "postgresql://postgres.your-tenant-id:c29cb6cfa177d36c8@sh.example.com:5432/postgres" -f data.sql --use-copy --data-only ``` Check the contents of `.sql` files anyways, though. Now, this was a fresh self-hosted Supabase already [with Pg 17](https://supabase.com/docs/guides/self-hosting/postgres-upgrade-17).
I wonder if using Supabase CLI the same way as described in https://supabase.com/docs/guides/self-hosting/restore-from-platform might work better? (Note: "it excludes internal schemas, strips reserved roles, and adds idempotent IF NOT EXISTS clauses. Using raw pg_dump directly will include Supabase internals and cause permission errors during restore")
🖖🤝
I've also added a couple of guides speficially about [self-hosted Supabase](https://supabase.com/docs/guides/self-hosting) here: - https://supabase.com/docs/guides/self-hosting/restore-from-platform - https://supabase.com/docs/guides/self-hosting/self-hosted-s3 - https://supabase.com/docs/guides/self-hosting/copy-from-platform-s3
That's a good approach! :) Apologies, but I don't have cycles to fix/update the Coolify templates on my side. It's a 3rd party, Coolify-community supported option. I'm trying to add as much as possible to `apps/docs/content/guides/self-hosting`, though - basically, to the docs [here](https://supabase.com/docs/guides/self-hosting), and to the `docker/` directory in the [repo](https://github.com/supabase/supabase/tree/master/docker) - so that the agents have a good idea about how to manage/customize it. Btw, re docs - you can also try asking the agent to `ssh supabase.sh` and check `docs/guides/self-hosting` directly (vs fetching from web) :)
Also, - https://github.com/orgs/supabase/discussions/39820 - https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md
Make sure to check the how-to's 🖖 Join Discord if you haven't yet, for community support.
There's also https://supabase.com/docs/guides/deployment/terraform
For a full separation, especially if using more than just Postgres as the database, consider spinning off a new instance. Whether on the same VPS or a new one is debatable (I think you have enough visibility at the current resource utilization), but arguably cleaner with a new VPS.
Jftr, a handful of how-to guides are available here - https://supabase.com/docs/guides/self-hosting
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 :)