Supabase is replacing Kong with Envoy as the default API gateway for self-hosted deployments — and the switch flips the week of August 9, 2026. If you run a custom kong.yml, terminate TLS directly on port 8443, or have scripts that reference the Kong container by name, you have less than two weeks to act. Supabase Cloud users are unaffected. For everyone else, here is exactly what breaks and what to do about it.
Why Kong Had to Go
The OSS Kong version Supabase ships — kong:3.9.1 — is frozen. Releases after 3.9.x have been security backports only, with no new features and no upstream activity. More critically, Kong removed free (unlicensed) mode in version 3.10, which means Supabase cannot upgrade beyond 3.9.x without commercial licensing it is not willing to take on. The result: every self-hosted Supabase stack is running a gateway more than a year behind with no viable path forward.
Envoy solves that cleanly. It is actively maintained (envoyproxy/envoy:v1.37.2 is the minimum image), fully open source with no licensing trap, and delivers lower latency and higher throughput than Kong in production benchmarks. Configuration lives in versioned YAML — no plugin runtime, no admin API to babysit. This migration is the right call. The timing could have come with louder warnings, but the direction is correct.
What Actually Breaks
Three specific scenarios break on upgrade. Check each one.
Port 8443 TLS Is Gone
Kong exposed an HTTPS listener on port 8443 built-in. Envoy does not. If you point traffic directly at :8443 — no Nginx, no Caddy, no Traefik in front — your stack loses its TLS endpoint on August 9. The fix is to add a reverse proxy for TLS termination before the cutover, or opt back into Kong temporarily while you migrate. This is the most operationally urgent issue for small self-hosted setups that skipped a reverse proxy layer.
Custom kong.yml Is Silently Ignored
If you have a customized kong.yml — custom routes, rate-limiting rules, ACL plugins, auth flows — those configurations do not carry over to Envoy. They will silently stop applying after the upgrade. No error. No log entry. Things just stop working.
Your options: opt back into Kong to keep your customizations running, or port them to Envoy’s configuration format under volumes/api/envoy/. The silent failure mode here is the part Supabase should have handled better — a compatibility check or explicit warning on startup would have been straightforward to add.
Container Name References Break
Scripts or automation that reference the gateway by service or container name — docker compose logs kong, run.sh restart kong, anything targeting supabase-kong directly — will fail after the switch. The new service is api-gw (container: supabase-envoy). Note that the kong network alias is preserved inside the Docker Compose stack, so internal traffic using kong:8000 continues to route correctly. Only external script references need updating.
How to Check If You Are Affected
Three diagnostic questions. Answer yes to any of them and you need to act before August 9:
- Is your TLS termination pointing directly at port
8443without a reverse proxy? → Port 8443 break. - Does your deployment include a modified
kong.ymlwith custom routes or plugins? → Silent config loss. - Do any scripts reference
kongorsupabase-kongby service name from outside the Docker stack? → Script failures.
If you want to migrate to Envoy now and verify your setup before the forced cutover, run your stack with the Envoy override:
docker compose -f docker-compose.yml -f docker-compose.envoy.yml up -dIf you need more time or have deep Kong customizations, you can opt back into Kong as an explicit override after August 9:
run.sh config add kongWhat Does Not Break
Before this turns into a panic thread: the scope is narrower than it sounds. Supabase Cloud is entirely unaffected. Your JavaScript and Python Supabase clients need no changes. Standard auth flows — email/password, OAuth, magic links — continue working unchanged. Internal Docker Compose traffic using kong:8000 still resolves correctly because the network alias is preserved. If you run a stock self-hosted setup behind a reverse proxy and have not customized kong.yml, the upgrade is likely transparent.
Also This Month: Passkeys Are Now in Beta
Separate from the gateway change, Supabase Auth shipped passkey support in beta this month. Passwordless sign-in via WebAuthn — biometrics, device PIN, or hardware security key — is now available through the Dashboard, CLI, and Management API. If you have been putting off phishing-resistant auth for your self-hosted app, the integration is now first-party rather than requiring a third-party service.
Act Before August 9
The Kong-to-Envoy switch is the right infrastructure move, even if the rollout communication left something to be desired. Run the diagnostic questions against your deployment today. If you are affected, the migration steps are straightforward — but you need to do them before the week of August 9, not after you discover a broken gateway in production.
