Supabase's Self-Hosted Stack Swaps Kong for Envoy Next Week

Supabase is switching the default API gateway in its self-hosted Docker stack from Kong to Envoy the week of Aug 9, 2026, according to a Supabase changelog entry published July 17 and titled “Envoy becomes the default API gateway (breaking change).” Supabase Cloud customers are unaffected. Only teams running the open-source stack need to do anything about it.

---

What’s changing

Envoy has shipped as an opt-in override (docker-compose.envoy.yml) for several self-hosted releases already, per Supabase’s Envoy gateway docs. The changelog entry flips that: Envoy moves into the base docker-compose.yml and becomes what a fresh docker compose up gives you, while Kong becomes the opt-in override instead, pulled in with sh run.sh config add kong. The gateway service is renamed api-gw, running a container called supabase-envoy, though Supabase keeps kong as a network alias so some existing tooling that references the old service name still resolves.

Supabase’s stated reason is that the OSS build of Kong it has shipped, kong:3.9.1, is about a year old. Later 3.9.x point releases have been security and nginx backports only, with no new features, and Kong removed free unlicensed mode starting in 3.10, which Supabase’s docs frame as a growing security and compliance liability for staying on the frozen OSS line. Envoy’s routing, filters and access control live in versioned YAML under volumes/api/envoy/ instead of a plugin runtime, and Supabase says its default config adds path normalization, header-smuggling rejection, correct client-IP handling behind an edge proxy, and a locked-down admin interface.

Who actually breaks

Most self-hosted installs should pick up the new default on their next docker compose pull without doing anything. The breaking part, per Supabase’s own docs, lands on a narrower group: anyone terminating HTTPS directly on Kong’s built-in listener, anyone running a customized kong.yml that Envoy’s config doesn’t replicate automatically, and any deployment tooling or scripts that hard-reference the kong container or service name in ways the new network alias doesn’t cover. If your reverse proxy, cert management or CI scripts assume Kong is there, read the self-hosting docs before the update lands rather than after something 502s.

The take

Deprecating a frozen, unlicensed-mode-stripped Kong build in favor of a gateway Supabase already controls end to end is the right call on security grounds, and giving self-hosters three weeks of changelog notice before the flip is more runway than plenty of infra vendors bother with for a default-behavior change. The rough edge is that “breaking change” and “should just work for most people” are both true at once here, and the group in between (custom kong.yml, hardcoded HTTPS termination, a deploy script nobody’s touched since it was written) is exactly the kind of setup that doesn’t show up until the Tuesday after the gateway swaps under it. If you self-host, this is a five-minute docs read that’s cheaper now than during an incident next week.

---

Key Takeaways

• Self-hosted Supabase’s default API gateway changes from Kong to Envoy the week of Aug 9, 2026, per the July 17 changelog entry.
• Supabase Cloud is unaffected. The change is scoped to the open-source Docker stack.
• Envoy was already available as an opt-in override; Kong now becomes the opt-in override via sh run.sh config add kong.
• Supabase cites an aging, unlicensed-mode-stripped OSS Kong build (3.9.1, no feature updates since) as the reason for the switch.
• Setups relying on Kong’s built-in HTTPS listener, a custom kong.yml, or hardcoded references to the kong service name should check Supabase’s Envoy docs before updating.