Self-hosted Supabase now defaults to Envoy instead of Kong

Supabase has made Envoy the default API gateway in its self-hosted Docker stack, replacing Kong in the base `docker-compose.yml`. The gateway service is now `api-gw` using the `supabase-envoy` container, while `kong` remains as a network alias for compatibility. Kong is still available as an explicit override. The new default listens on plain HTTP only, so users relying on Kong’s built-in HTTPS listener on port 8443 need a reverse proxy or must opt back into Kong.

This is a breaking infrastructure-default change for operators who customize the self-hosted stack. A stock checkout can move with little work, but Kong-specific routes, plugins, ACLs and service-name automation do not automatically translate to Envoy. Supabase’s rationale also signals a longer-term maintenance boundary: it says the free Kong OSS line it shipped is effectively frozen, while Envoy becomes the path for current key handling and hardened gateway defaults.

The base self-hosted Compose stack now runs Envoy as the `api-gw` service in the `supabase-envoy` container. Supabase preserves `kong` as a network alias to reduce breakage inside the Docker network, but commands and scripts that refer to the old service or container name directly can fail.

The default Envoy gateway listens on HTTP port 8000 and does not reproduce Kong’s direct HTTPS listener on 8443. Operators who terminated TLS at Kong need to add the supplied Caddy or Nginx overrides, place another reverse proxy in front, or keep Kong during migration.

A customized `kong.yml` is not translated into Envoy configuration. Custom routes, plugins and access rules can therefore silently stop applying after pulling the new base stack. Supabase recommends either opting back into Kong temporarily or porting configuration into the versioned Envoy YAML under `volumes/api/envoy/`.

Supabase says the Envoy configuration natively translates the newer opaque publishable and secret API keys into internal credentials and ships with stricter path normalization, header-smuggling rejection, proxy-aware client-IP handling and a locked-down admin interface. The migration is therefore both a compatibility event and a security/maintenance direction change.