Andrey A.

An update on the state of [self-hosted Supabase](https://supabase.com/docs/guides/self-hosting) - following up on the [June recap](https://github.com/orgs/supabase/discussions/39820#discussioncomment-17351802). ⚠️ **Breaking changes in the recent releases:** - **Envoy is the default API gateway** - it replaced Kong in `docker-compose.yml`. Read the [Envoy guide](https://supabase.com/docs/guides/self-hosting/self-hosted-envoy) and check the discussion [#48048](https://github.com/orgs/supabase/discussions/48048) - Access to the OpenAPI spec at `/rest/v1/` via the anon (publishable) key has been removed. See discussion [#42949](https://github.com/orgs/supabase/discussions/42949) - `API_EXTERNAL_URL` has been updated to include the `/auth/v1` path prefix (e.g. `http://localhost:8000/auth/v1`), aligning self-hosted with the platform and CLI. See discussion [#47093](https://github.com/orgs/supabase/discussions/47093) **Setup & management** - Added `self-hosted/v*` to [supabase/supabase/tags](https://github.com/supabase/supabase/tags) to track self-hosted releases (latest is [self-hosted/v0.8.0](https://github.com/supabase/supabase/releases/tag/self-hosted%2Fv0.8.0)) - Added `update.sh`. Refer to [Update Your Self-Hosted Deployment](https://supabase.com/docs/guides/self-hosting/updating) guide for more information - Added base version stamp to `setup.sh` (saved in `.supabase-version`) **Documentation** - Housekeeping and updating the guides to reflect recent changes **Gateway & proxies** - Changed the default API gateway from Kong to Envoy; the `kong` service in `docker-compose.yml` was renamed to `api-gw` - Legacy Kong configuration updated to 3.9.3 - Updated the nginx-certbot version in the override **Kubernetes** - The community [supabase-kubernetes](https://github.com/supabase-community/supabase-kubernetes) repo now offers a Kubernetes operator, thanks to @luizfelmach **What's next** - More how-to guides - A `pgbouncer` override - Improve the way Auth is configured (separate Auth config into its own configuration file) - Observability for self-hosted Supabase - a separate `supabase-observability` repo in [supabase-community](https://github.com/supabase-community) is on the way (via our new contributor [Jimin](https://github.com/JiminByun0101)) Refer to the [CHANGELOG.md](https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md) for a detailed list of changes and updates.

@kikru77, appreciate you asking, though it would've been more convenient to have this one as a separate discussion :) I can relate to the confusion experienced here, and it's a common gotcha with misinterpreting [CLI](https://supabase.com/docs/guides/local-development) as [self-hosted Supabase](https://supabase.com/docs/guides/self-hosting). As far as I could understand you first tried to use your app against a CLI and then also installed the self-hosted [configuration](https://supabase.com/docs/guides/self-hosting/docker). But then you got lost in the process of actually connecting your app project to your locally running self-hosted Supabase. I'll try to answer here, but consider maybe also joining our [Discord](https://discord.supabase.com/) for more help. 1. The self-hosted `.env` is its own thing, leave it in the `supabase-project` directory (btw, it can be renamed to anything, it's just a placeholder name matching the notion of a single-project Supabase instance). It contains only the details about the actual self-hosted instance that is accessible via port `8000` by default. Create a separate `.env` file for your Expo ReactNative app. Check the following [guide](https://supabase.com/docs/guides/getting-started/quickstarts/expo-react-native) and basically skip the first two steps, as you've already set up a local self-hosted Supabase. Use `http://localhost:8000` for the Supabase project URL, and the publishable key that you can find inside `supabase-project/.env` or via `sh run.sh secrets`. To reiterate, the two `.env`s are completely separate, independent configurations. Also, think of your self-hosted instance on port `8000` as a remote instance, that might simplify the mental model :) 2. I'm hoping [this part](https://supabase.com/docs/guides/getting-started/quickstarts/expo-react-native#6-declare-supabase-environment-variables) of the Expo ReactNative guide might be illustrative. Grab the values from the self-hosted config as described in 1) above. 3. For the purposes of local development I'd suggest you use *either the* [CLI/local development](https://supabase.com/docs/guides/local-development) *or the actual self-hosted configuration*, not both. Those are two very different things, although they do have certain similarities (e.g., Docker-run Supabase services, Studio, etc.) Use CLI/local-dev for the purposes of isolated, local development only. For a clearer setup, install CLI via `npm` and use it as part of your Expo ReactNative project. **Do not use** the CLI-configuration to actually **host** your database on a VPS and opening it to any external traffic. The main use case for using the CLI is to develop locally while having the remote project on Supabase platform and keeping both in sync (check the [CLI workflows](https://supabase.com/docs/guides/local-development/cli-workflows) guide). You can also use CLI against a self-hosted Supabase instance :) This is where "think of self-hosted as a remote project" mental model might help, even though you might be also running it locally. However, CLI-with-self-hosted has a very limited functionality currently. If you really want to use the actual self-hosted Supabase and later re-deploy it somewhere on an external server and expose it to the users of your app, skip the CLI path entirely and familiarize yourself with self-hosted (first, locally on your laptop, then on a remote server). Consider adding an [HTTPS proxy](https://supabase.com/docs/guides/self-hosting/self-hosted-proxy-https) configuration on top when deploying externally. I'm hoping this helps, and again - a Discord thread might probably be easier since there might be more people there who have used Expo ReactNative vs a CLI or a self-hosted Supabase instance.

See PR #48153, PR #48763

Thanks, noted :)

Added to `self-hosted/v0.7.1`, see the guide [here](https://supabase.com/docs/guides/self-hosting/updating). It might be a bit tedious to record the very first "base" stamp, but I'm hoping this is a reasonable trade off. Feedback appreciated!

Many thanks for confirming - and apologies.

Should be fixed. Apologies!

See #48272, #48288 - should be resolved by now.

Can you check again please?

@sprsquish

@jurinek666 I fw'd this to the team.

This doesn't affect CLI :) Re Kong URLs - the API gateway will continue to be reachable internally via `kong` ("It keeps kong as a network alias for backward compatibility.")

> 3. Because it's enabled for self host, I would expect that it would also work for local dev. It is enabled as in it's functional and you can use it. > The frontend code for the studio is contradictory as it locks the UI config for this behind the IsPatform check. No argument here :) It is confusing. There's a lot more work planned for both CLI and Studio going forward, including the improvements to how things are configured (for CLI at least), but at the moment it's along the lines of what I've described above.

Two things here :) For one, the `supabase start` is not "self-hosted" - it's [Local development & CLI](https://supabase.com/docs/guides/local-development). CLI has a different configuration - it's all via `config.toml`. Self-hosted Supabase [configuration](https://supabase.com/docs/guides/self-hosting) is Docker Compose only and everything is in `.env` and docker compose files. The `IS_PLATFORM` in the Studio codebase differentiates between Studio connecting to the platform APIs and a local deployment. When `!IS_PLATFORM` - local routes are used. There's an additional API now to further check what's the deployment type is (`isCLI`/`isSelfHosted`). Anyways, there's no any API for either CLI or self-hosted to manage `config.toml` or `.env` via Studio - both should be configured **manually**. For CLI config details refer to [Supabase CLI config](https://supabase.com/docs/guides/local-development/cli/config). For self-hosted Supabase see the how-to guides on the left [here](https://supabase.com/docs/guides/self-hosting). Last but not least - **do not** use CLI deployment mode as a publicly accessible Supabase instance. Local CLI-run services are supposed to be used in an isolated development-only environment - never to be exposed to any external traffic.

Good to hear, indeed - https://supabase.com/docs/guides/self-hosting/docker#changing-database-password

It's probably the logs data. See the following: - https://github.com/orgs/supabase/discussions/40546 - https://github.com/supabase/supabase/issues/43643 - https://github.com/orgs/supabase/discussions/42038 - https://github.com/orgs/supabase/discussions/46084 (logs & analytics are optional now)

Cc @luizfelmach, @singh-inder :)

See PR #47640

Closing this one in favor of the support ticket, and your post in Discord.

Re the above - I believe this kind of issue with migrations in Auth has been fixed in [auth#2047](https://github.com/supabase/auth/pull/2047) and [auth#2290](https://github.com/supabase/auth/pull/2290). The latest versions of Auth should apply migrations properly even on a custom-initialized Postgres. The standard Supabase Postgres image bootstraps the `auth` schema/role such that the enum types land in auth regardless, which is why default self-hosted setups don't seem to have hit this.

Thanks for these details, I'll check.

There seem to be capacity issues in eu-west as well it seems. The status page is going to be updated shortly.

Indeed, but currently I don't have a good way to offer that. There's an alternative upgrade path currently being developed for the platform instances, maybe I could borrow from it in the future.

The default configuration has been changed to Postgres 17 :) See the following: - #46080 - #46081 - #45329

Twimc - this change will also happen in [self-hosted Supabase](https://supabase.com/docs/guides/self-hosting) configuration the week of July 6, 2026.

A note about `pg_graphql`: - See discussion #45329 - Check the self-hosted Supabase [changelog](https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md#postgres) for more information

Another update on the state of [self-hosted Supabase](https://supabase.com/docs/guides/self-hosting) - following up on the [January recap](https://github.com/supabase/supabase/discussions/39820#discussioncomment-15619050). ⚠️ First, **breaking changes in the June 17 release:** - **Postgres 17 is now the default.** Don't start on top of an existing Postgres 15 data directory. Read the [upgrade guide](https://supabase.com/docs/guides/self-hosting/postgres-upgrade-17); see discussion [#46080](https://github.com/orgs/supabase/discussions/46080) - **`supabase_admin` → `postgres`** - Studio and Postgres Meta now connect as `postgres`; see discussion [#46081](https://github.com/orgs/supabase/discussions/46081) and the [article](https://supabase.com/docs/guides/self-hosting/remove-superuser-access) by @singh-inder on how to update the legacy databases Overall, the main focus has been on closing the gap between self-hosted and platform behavior, and also - an easier setup/management of the compose configuration. **Setup & management** - One-command setup: `curl -fsSL https://supabase.link/setup.sh | sh` - A `run.sh` wrapper as a substitute for clunky `docker compose`-with-overrides invocations (read more [here](https://supabase.com/docs/guides/self-hosting/docker#managing-the-stack)) - Logs & analytics are now optional - add logs via the `docker-compose.logs.yml` override - A generated per-service env var reference - [CONFIG.md](https://github.com/supabase/supabase/blob/master/docker/CONFIG.md) **Documentation** - Quite a bit of time spent on adding 10+ new [how-to guides](https://supabase.com/docs/guides/self-hosting), plus many edits across the existing ones **Gateway & auth** - Kong updated to 3.9.1 - Envoy as an optional API gateway, see the [guide](https://supabase.com/docs/guides/self-hosting/self-hosted-envoy); kudos @luizfelmach - [New API keys](https://supabase.com/docs/guides/self-hosting/self-hosted-auth-keys) plus asymmetric ES256 signing **Other highlights** - Many changes in the self-hosted Studio behavior (bug fixes, adjusted UI/UX, minimal project settings, viewing edge functions, etc.) - RustFS as an optional S3 [storage backend](https://supabase.com/docs/guides/self-hosting/self-hosted-s3). MinIO switched to [Chainguard images](https://images.chainguard.dev/directory/image/minio/overview) - Optional/example configs for Caddy and nginx [HTTPS proxies](https://supabase.com/docs/guides/self-hosting/self-hosted-proxy-https) - Tests added - suitable for either individual runs, or CI/CD **Kubernetes** - The community [supabase-kubernetes](https://github.com/supabase-community/supabase-kubernetes) repo has been quite active, thanks to @luizfelmach - Also in progress there: Supabase Kubernetes operator **What's next** - More work on Studio to align self-hosted UI/UX with the platform's - Switch from Kong to Envoy as the default API gateway - Continue configuration tweaks (routes, services configs) - Improve the way Auth is configured (separate Auth config into its own configuration file) - Add `update.sh` for easier upgrades between releases - Observability for self-hosted Supabase - add community-driven configurations and guides - The Caddy-instead-of-Kong/Envoy approach (thanks @pauserratgutierrez) is genuinely interesting and worth a closer look **What I keep in mind, but don't have a clear path for yet** - **Upgrades / migrations** - the Postgres 17 path covers the major-version jump, but it doesn't solve the schema migration issues - **External / managed Postgres** (RDS, Aurora, Cloud SQL) - still non-trivial today: doable, with notable constraints - **A lighter / headless package** - lots of interest in a smaller, dashboard-optional stack. The optional logs/analytics is a marginal step, there's more planned The [CHANGELOG.md](https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md) has the full detail. Thanks to everyone here - the specificity in this thread really helps, and to those who contributed via issues and PRs 🙏

Check [docker/CHANGELOG.md](https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md#2026-06-17) for more information.

Check [docker/CHANGELOG.md](https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md#2026-06-17) for more information.

See PR #46981.

See PR #47022.

There's also https://github.com/supabase-community/supabase-kubernetes/ that should work on Hetzner, I'm guessing.

Yes, I'm testing https://supabase.com/docs/guides/self-hosting/docker > How to seperate db from the rest of the backend etc.? If you meant "how to move Supabase Postgres to a separate instance" - you can carve out and move the db service from `docker-compose.yml`, then change the configuration in `.env` to point to a different host. If it was about "how to use any arbitrary Postgres" - that's a bit harder, and will not be 100% compatible (esp., regarding the extensions like pg_net). Not for Hetzner, but, as an example of a fully separate services configuration - https://github.com/BenIsenstein/pgonrails (via @BenIsenstein)

I don't think there are any plans for the platform to switch from AWS. I'm testing [self-hosted Supabase](https://supabase.com/docs/guides/self-hosting) on Hetzner regularly though.

Also, https://supabase.com/docs/guides/self-hosting/custom-email-templates by @singh-inder :)

But I'll work on it shortly :)

It is definitely a burden. Let's say this - I'm looking into how to improve the release process. There's quite a bit of suggestions regarding the update process in #39820, but I don't have a good solution yet.

@Ziinc Maybe you could add a note on that? 🤔

Updated. See [docker/CHANGELOG.md](https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md#2026-06-03) for more information.

See also https://github.com/orgs/supabase/discussions/46084

> Set LOGFLARE_LOGGER_BACKEND_API_KEY to any dummy value This isn't needed. Overall, yes, correct, analytics & vector can just be removed from `docker-compose.yml`.

> Don't want to bother and propably you already noticed but storage added a new env variable STORAGE_S3_UPLOAD_PART_SIZE in this pull request https://github.com/supabase/storage/pull/1116, I hope this helps keeping your new amazing environment variable list up to date :) No, I haven't noticed yet :) No bother at all, but also - PRs are always welcome!

Thanks! 🖖 Will try this :)

No problem, glad it helps :) Looking forward to seeing that Caddyfile!

Indeed! For all things reverse engineering and documentation - it's been extremely helpful, especially since Opus 4.5. While it still requires a lot of proof-reading, back-and-forth, and tedious copyediting - it still saves an enormous amount of time and mental space. Especially, given how heterogeneous the Supabase product stack is (TS, Go, Rust, Elixir, Haskell, C, etc.)

Thanks, @ready4sea & @BenIsenstein! @BenIsenstein - I remembered that, but decided to cross-reference later as this CONFIG.md is basically an outcome from a super lenghty session with Claude Code across all public repos and a couple of private ones for cross-check. If you spot anything that needs corrections/amendments - that'd be 🙏 I might run another session of cross-checking against your findings too.

Re: > Clearer documentation of environment variables — their conventions and expected types. This is the single biggest paper cut. Yeah, well, that's no easy feat... would something like this https://github.com/supabase/supabase/blob/self-hosted/docs-env-vars/docker/CONFIG.md help?

Thanks! This is great feedback, and I appreciate you taking the time to write it 🙏 All valid points :) The Caddyfile would definitely be interesting to see. I've added example proxy + HTTPS configs lately, but offering a lightweight api-gw is definitely worth exploring.

This one was resolved in Discord afair? :) (Post: "kong-entrypoint.sh created as directory?")

I'm planning to switch Postgres to version 17 as the default in a month or so from now. I will also be adding a simple helper script to manage compose configurations (see PR #45603). Regarding Supavisor - maybe @v0idpwn could clarify when we could expect a new version and an updated image in either the AWS registry (that [CLI/local development ](https://supabase.com/docs/guides/local-development)uses), or Docker Hub - or preferrably both :)