Kong Is Out, Envoy Is In: What the Gateway Switch Means for Self-Hosted Supabase

WZ-IT operates supacloud. Current hosting starts from €129.90 net/month; setup and service level follow the proposal. Former package prices, location lists and cost comparisons in this dated article describe the previous offer, not current WZ-IT terms. View current service scope.

Anyone running Supabase themselves received an update in August 2026 that was more than a version bump: the default API gateway switched from Kong to Envoy. For most installations it passes through unnoticed; for three configurations it does not. More interesting than the migration itself is the reason behind it, because it says something about what self-hosting an open source stack actually involves. This article explains what changed, who is affected and how to determine that for your installation in ten minutes.

Table of Contents

• What changed
• Who breaks, and who does not
  • The check, in three questions
• The way out, and why it is not one
• What is actually interesting about this
• The migration path in detail
• Why this matters for choosing a provider
• supacloud: managed Supabase from Germany
• Conclusion
• Sources

What changed

With release 0.8.0 of the self-hosted configuration, dated 11 August 2026, Envoy became the default API gateway [2]. Supabase had announced the switch for the week of 9 August 2026 [1].

Concretely [1][2]:

• The kong service in docker-compose.yml is now api-gw and runs in the container supabase-envoy.
• The name kong is kept as a network alias so existing connections inside the compose network keep working.
• Kong becomes an optional override in a new docker-compose.kong.yml.
• docker-compose.envoy.yml has become a no-op shim now that Envoy is the default anyway.
• A new variable API_GW_HTTP_PORT falls back to KONG_HTTP_PORT when unset.
• The Caddy and nginx overrides now forward to api-gw.

The network alias is the considerate part of this release. Without it, every service in the compose network addressing kong as a host would have pointed nowhere immediately.

Who breaks, and who does not

Supabase names the affected cases explicitly in the announcement [1]. There are three, and they can be checked in ten minutes.

First: the HTTPS listener on 8443. Kong shipped its own HTTPS listener on port 8443. Envoy listens on plain HTTP on port 8000 only [1]. Anyone exposing 8443 directly, or addressing it internally, loses that path.

Second: a customised kong.yml. Custom routes, plugins or ACLs in volumes/api/kong.yml have no automatic equivalent in Envoy. They have to be ported to Envoy's configuration [1].

Third: scripts using the service name. Anything addressing kong as a compose service, such as docker compose logs kong, points nowhere because the service is now api-gw [1]. The network alias does not help here: it applies to network resolution, not to the compose service name.

Not affected are users of the Supabase platform and users of the local CLI [1]. Anyone running an unmodified default installation without direct 8443 access gets an ordinary update.

The check, in three questions

Three times no means: ordinary update, refresh the configuration files, carry on.

The way out, and why it is not one

Kong can be re-enabled as an override with sh run.sh config add kong [1]. That is the right call when an update is due and there is no time to port anything today.

As a permanent answer it does not hold. Supabase justifies the switch by saying Kong's open source line has effectively stopped advancing and the shipped version is unmaintained [1]. An override sitting on a frozen component only pushes the work back, into a time when the gap has grown.

The second reason given is the friendlier one: Envoy brings config-as-code routing in YAML and first-class support for the new API keys [1].

What is actually interesting about this

Taken alone, the gateway switch is a manageable migration. It becomes notable in context.

Look at what happened to the same configuration between June and August 2026 [2]:

Four planned interventions in a little over two months, two of them with real breaking potential. This is not a complaint about the project. Supabase moves fast, documents the changes cleanly and has shipped an update.sh plus an upgrades.json since 0.7.1 that gates breaking changes by version [2]. That is more than many projects do.

But it is the honest answer to what self-hosting costs. Not the server. The attention.

The migration path in detail

For anyone running it themselves, in the order that works.

1. Back up. The data directory above all, and the configuration files. Without a backup there is no way back.
2. Check exposure using the three questions above. That decides whether this is an update or a project.
3. Update configuration files. Per the changelog that means docker-compose.yml and .env because of API_GW_HTTP_PORT, plus docker-compose.envoy.yml, the new docker-compose.kong.yml and, if in use, docker-compose.caddy.yml, docker-compose.nginx.yml, the Caddyfile and the nginx template [2].
4. Sort out TLS if you previously terminated on 8443. Caddy or nginx in front, Envoy behind it on plain HTTP.
5. Switch scripts and monitoring from kong to api-gw.
6. Rehearse on a copy, not on the production instance. A gateway that fails to start takes the entire API with it.
7. Only then go live, with a maintenance window and a rollback plan. Supabase describes the official procedure in its update guide [3], the full compose reference is in the self-hosting handbook [4], and the concrete change is traceable in pull request #48153 [5].

Supabase also added an improvement in 0.7.2 that helps here: update.sh no longer overwrites itself during an update but is staged as update.sh.new for review [2]. A small detail that counts precisely when an update goes wrong halfway through.

Why this matters for choosing a provider

The usual self-hosting calculation is: server plus time. The server part is easy to quantify; the time part is usually underestimated because it arrives irregularly.

A gateway switch does not cost eight hours a month. It costs half a day once, plus the vigilance to notice it at all before the next docker compose pull applies it unasked. The same vigilance was needed in June for the Postgres major upgrade and in July for the changed auth path.

This is exactly where self-hosting differs from operated hosting, regardless of who the provider is. The question is not whether somebody can start Docker. The question is who has it in their calendar that a breaking change is four weeks out.

supacloud: managed Supabase from Germany

We run the open source community edition of Supabase as a dedicated instance, in Germany by default, with a data processing agreement under Article 28 GDPR. The gateway switch is exactly the kind of work we take on: with notice, with a maintenance window, rehearsed on a copy beforehand. Nothing changes for you in terms of project URL or keys.

The price comes from instance size and support tier. In the Germany region S costs EUR 99.90 net per month, M EUR 149.90 and L EUR 249.90; the Business support tier adds EUR 100, Priority EUR 150 and Enterprise EUR 350. For production the Supabase documentation recommends 4 vCPU and 8 GB, meaning size M and up.

What we honestly cannot do either: branching, the platform management API and several projects in one instance exist only in Supabase's cloud platform, not in the open source stack. Separate environments are covered by a second instance.

The trial runs 7 days. A credit card is required to sign up, and after it expires the trial converts automatically into the chosen paid subscription.

See pricing · Get in touch

Conclusion

The move from Kong to Envoy is a well-documented migration with a fallback path and a network alias that cushions the most common breaking point. Anyone without direct 8443 access, without a customised kong.yml and without scripts using the old service name will barely notice it.

The real finding sits next to it: four changes requiring action between June and August, two of them with genuine breaking potential. Supabase does a lot right here, documenting cleanly and shipping tooling. But the work stays with whoever runs the instance. That is the calculation worth making about self-hosting, not the one about the server.

supacloud is an independent managed hosting provider and is not affiliated with Supabase Inc. or Kong Inc. Supabase is open source, its core components under Apache 2.0 and MIT. This article provides context on independently operated products for information purposes and does not constitute legal advice.

Sources

• [[1]] Supabase changelog: "Self-hosted Supabase: Envoy becomes the default API gateway (breaking change)" – switch week, api-gw and supabase-envoy, network alias, HTTP-only on 8000, affected cases, Kong override
• [[2]] supabase/supabase · docker/CHANGELOG.md – release 0.8.0 of 11 Aug 2026 plus 0.5.0, 0.6.0, 0.7.0, 0.7.1 and 0.7.2
• [[3]] Supabase Docs: Update Your Self-Hosted Deployment
• [[4]] Supabase Docs: Self-Hosting with Docker
• [[5]] supabase/supabase · pull request #48153 – switching the default gateway to Envoy
• [[6]] Supabase changelog: "Self-hosted Supabase: upgrading from PG 15 to 17 (breaking change)"
• supacloud.de – managed Supabase hosting