Kong ist raus, Envoy ist drin: Was der Gateway-Wechsel für Self-Hosted Supabase bedeutet

WZ-IT führt supacloud weiter. Aktuelles Hosting ab 129,90 € netto/Monat; Einrichtung und Service Level gemäß Angebot. Frühere Paketpreise, Standortlisten und Kostenvergleiche in diesem datierten Artikel beschreiben das damalige Angebot, nicht die aktuellen WZ-IT-Konditionen. Aktuellen Leistungsumfang ansehen.

Wer Supabase selbst betreibt, hat im August 2026 ein Update bekommen, das mehr ist als ein Versionssprung: Das Standard-API-Gateway ist von Kong auf Envoy gewechselt. Für die meisten Installationen läuft das durch, für drei Konstellationen nicht. Interessanter als die Migration selbst ist aber der Grund dahinter, denn er sagt etwas darüber, was beim Selbstbetrieb von Open-Source-Stacks tatsächlich auf einen zukommt. Dieser Beitrag erklärt, was sich geändert hat, wer betroffen ist und wie Sie das in zehn Minuten für Ihre Installation feststellen.

Inhaltsverzeichnis

• Was sich geändert hat
• Wer bricht, und wer nicht
  • Die Prüfung in drei Fragen
• Der Ausweg, und warum er keiner ist
• Was daran wirklich interessant ist
• Der Migrationsweg im Detail
• Warum das für die Anbieterwahl relevant ist
• supacloud: Managed Supabase aus Deutschland
• Fazit
• Quellen

Was sich geändert hat

Mit Release 0.8.0 der Self-Hosted-Konfiguration vom 11. August 2026 ist Envoy das Standard-API-Gateway [2]. Angekündigt hatte Supabase den Wechsel für die Woche ab dem 9. August 2026 [1].

Konkret [1][2]:

• Der Dienst kong in der docker-compose.yml heißt jetzt api-gw und läuft im Container supabase-envoy.
• Der Name kong bleibt als Netzwerk-Alias erhalten, damit bestehende Verbindungen innerhalb des Compose-Netzes weiter funktionieren.
• Kong wird zu einem optionalen Override in einer neuen docker-compose.kong.yml.
• docker-compose.envoy.yml ist zu einem No-Op-Shim geworden, weil Envoy jetzt ohnehin Standard ist.
• Neu ist die Variable API_GW_HTTP_PORT, die auf KONG_HTTP_PORT zurückfällt, wenn sie nicht gesetzt ist.
• Die Overrides für Caddy und nginx leiten jetzt auf api-gw weiter.

Der Netzwerk-Alias ist die freundliche Geste in diesem Release. Ohne ihn hätte jeder Dienst im Compose-Netz, der kong als Host adressiert, sofort ins Leere gezeigt.

Wer bricht, und wer nicht

Supabase benennt die betroffenen Fälle in der Ankündigung ausdrücklich [1]. Es sind drei, und sie lassen sich in zehn Minuten prüfen.

Erstens: der HTTPS-Listener auf 8443. Kong brachte einen eigenen HTTPS-Listener auf Port 8443 mit. Envoy lauscht nur auf einfachem HTTP auf Port 8000 [1]. Wer 8443 direkt exponiert oder intern angesprochen hat, verliert diesen Weg.

Zweitens: eine angepasste kong.yml. Eigene Routen, Plugins oder ACLs in volumes/api/kong.yml haben in Envoy keine automatische Entsprechung. Sie müssen auf Envoys Konfiguration portiert werden [1].

Drittens: Skripte, die den Dienstnamen benutzen. Alles, was kong als Compose-Dienst adressiert, etwa docker compose logs kong, greift ins Leere, weil der Dienst jetzt api-gw heißt [1]. Der Netzwerk-Alias hilft hier nicht: Er gilt für die Netzwerkauflösung, nicht für den Compose-Dienstnamen.

Nicht betroffen sind Nutzer der Supabase-Plattform und Nutzer des lokalen CLI [1]. Wer eine unveränderte Standardinstallation ohne direkten 8443-Zugriff betreibt, bekommt ein normales Update.

Die Prüfung in drei Fragen

Dreimal nein bedeutet: normales Update, Konfigurationsdateien aktualisieren, weitermachen.

Der Ausweg, und warum er keiner ist

Kong lässt sich mit sh run.sh config add kong als Override wieder einschalten [1]. Das ist die richtige Entscheidung, wenn ein Update ansteht und gerade keine Zeit für die Portierung ist.

Als Dauerlösung trägt es nicht. Supabase begründet den Wechsel damit, dass die Open-Source-Linie von Kong praktisch stehen geblieben sei und die ausgelieferte Version nicht mehr gepflegt werde [1]. Ein Override, der auf einer eingefrorenen Komponente sitzt, verschiebt die Arbeit nur nach hinten, und zwar in eine Zeit, in der der Abstand größer geworden ist.

Der zweite genannte Grund ist der freundlichere: Envoy bringt Routing als Konfiguration in YAML und erstklassige Unterstützung für die neuen API-Keys [1].

Was daran wirklich interessant ist

Der Gateway-Wechsel ist für sich genommen eine überschaubare Migration. Bemerkenswert ist er im Zusammenhang.

Sehen Sie sich an, was zwischen Juni und August 2026 in derselben Konfiguration passiert ist [2]:

Vier geplante Eingriffe in gut zwei Monaten, davon zwei mit echtem Bruchpotenzial. Das ist kein Vorwurf an das Projekt. Supabase entwickelt schnell, dokumentiert die Änderungen sauber und liefert seit 0.7.1 sogar ein update.sh samt einer upgrades.json, die Breaking Changes versioniert absichert [2]. Das ist mehr, als viele Projekte tun.

Es ist aber die ehrliche Antwort auf die Frage, was Selbstbetrieb kostet. Nicht der Server. Die Aufmerksamkeit.

Der Migrationsweg im Detail

Für alle, die es selbst fahren, in der Reihenfolge, die sich bewährt hat.

1. Sichern. Vor allem das Datenverzeichnis und die Konfigurationsdateien. Ohne Sicherung gibt es keinen Rückweg.
2. Betroffenheit prüfen anhand der drei Fragen oben. Das entscheidet, ob es ein Update oder ein Projekt wird.
3. Konfigurationsdateien aktualisieren. Laut Changelog betrifft das docker-compose.yml und .env wegen API_GW_HTTP_PORT, dazu docker-compose.envoy.yml, die neue docker-compose.kong.yml und, falls im Einsatz, docker-compose.caddy.yml, docker-compose.nginx.yml, den Caddyfile und die nginx-Vorlage [2].
4. TLS regeln, falls bisher über 8443 terminiert wurde. Caddy oder nginx davor, Envoy dahinter auf einfachem HTTP.
5. Skripte und Monitoring umstellen von kong auf api-gw.
6. Auf einer Kopie durchspielen, nicht auf der Produktivinstanz. Ein Gateway, der nicht startet, nimmt die gesamte API mit.
7. Erst dann produktiv fahren, mit Wartungsfenster und Rückfallplan. Den offiziellen Ablauf beschreibt Supabase im Update-Leitfaden [3], die vollständige Compose-Referenz steht im Self-Hosting-Handbuch [4]; die konkrete Umstellung ist in Pull Request #48153 nachvollziehbar [5].

Supabase hat mit 0.7.2 außerdem eine Verbesserung eingebaut, die hier hilft: update.sh überschreibt sich nicht mehr selbst während eines Updates, sondern wird als update.sh.new zur Prüfung abgelegt [2]. Ein kleines Detail, das genau dann zählt, wenn ein Update mittendrin schiefgeht.

Warum das für die Anbieterwahl relevant ist

Die übliche Rechnung beim Selbstbetrieb lautet: Server plus Zeit. Der Serverteil ist leicht zu beziffern, der Zeitteil wird meistens zu niedrig angesetzt, weil er unregelmäßig anfällt.

Ein Gateway-Wechsel kostet keine acht Stunden pro Monat. Er kostet einmal einen halben Tag, plus die Wachsamkeit, ihn überhaupt mitzubekommen, bevor das nächste docker compose pull ihn ungefragt einspielt. Dieselbe Wachsamkeit brauchte es im Juni beim Postgres-Major-Upgrade und im Juli beim geänderten Auth-Pfad.

Genau an dieser Stelle unterscheidet sich Selbstbetrieb von betriebenem Hosting, und zwar unabhängig davon, wer der Anbieter ist. Die Frage ist nicht, ob jemand Docker starten kann. Die Frage ist, wer im Kalender stehen hat, dass in vier Wochen ein Bruch ansteht.

supacloud: Managed Supabase aus Deutschland

Wir betreiben die quelloffene Community-Version von Supabase als eigene, dedizierte Instanz, standardmäßig in Deutschland, mit AV-Vertrag nach Artikel 28 DSGVO. Der Gateway-Wechsel ist genau die Art Arbeit, die wir übernehmen: mit Ankündigung, mit Wartungsfenster, vorher auf einer Kopie durchgespielt. An Ihrer Projekt-URL und Ihren Keys ändert sich dabei nichts.

Der Preis ergibt sich aus Instanzgröße und Support-Stufe. In der Region Deutschland kostet S 99,90 € im Monat netto, M 149,90 € und L 249,90 €; die Support-Stufe Business kostet 100 € Aufschlag, Priority 150 € und Enterprise 350 €. Für den Produktivbetrieb nennt die Supabase-Dokumentation 4 vCPU und 8 GB als Empfehlung, also Größe M aufwärts.

Was wir ehrlicherweise auch nicht können: Branching, die Platform Management API und mehrere Projekte in einer Instanz gibt es nur in der Cloud-Plattform von Supabase, nicht im Open-Source-Stack. Getrennte Umgebungen bilden wir über eine zweite Instanz ab.

Leistungsumfang und Bereitstellung mit WZ-IT abstimmen. Bereitstellung und Vertragsbedingungen werden mit WZ-IT im Angebot vereinbart. Es gibt kein Self-Service-Portal und kein automatisches Testabonnement.

Preise ansehen · Kontakt aufnehmen

Fazit

Der Wechsel von Kong zu Envoy ist eine gut dokumentierte Migration mit einem Rückfallweg und einem Netzwerk-Alias, der die häufigste Bruchstelle abfedert. Wer keinen direkten 8443-Zugriff, keine angepasste kong.yml und keine Skripte mit dem alten Dienstnamen hat, merkt davon wenig.

Der eigentliche Befund liegt daneben: Vier Änderungen mit Handlungsbedarf zwischen Juni und August, davon zwei mit echtem Bruchpotenzial. Supabase macht dabei vieles richtig, es dokumentiert sauber und liefert Werkzeuge mit. Aber die Arbeit bleibt bei dem, der die Instanz betreibt. Das ist die Rechnung, die beim Selbstbetrieb aufgemacht werden sollte, und nicht die für den Server.

supacloud ist ein unabhängiger Managed-Hosting-Anbieter und steht in keiner Verbindung zu Supabase Inc. oder Kong Inc. Supabase ist quelloffen, die Kernkomponenten stehen unter Apache 2.0 und MIT. Dieser Beitrag ordnet unabhängig betriebene Produkte zu Informationszwecken ein und ersetzt keine Rechtsberatung.

Quellen

• [[1]] Supabase Changelog: „Self-hosted Supabase: Envoy becomes the default API gateway (breaking change)" – Umstellungswoche, api-gw und supabase-envoy, Netzwerk-Alias, HTTP-only auf 8000, betroffene Fälle, Kong-Override
• [[2]] supabase/supabase · docker/CHANGELOG.md – Release 0.8.0 vom 11.08.2026 sowie 0.5.0, 0.6.0, 0.7.0, 0.7.1 und 0.7.2
• [[3]] Supabase Docs: Update Your Self-Hosted Deployment
• [[4]] Supabase Docs: Self-Hosting with Docker
• [[5]] supabase/supabase · Pull Request #48153 – Umstellung des Standard-Gateways auf Envoy
• [[6]] Supabase Changelog: „Self-hosted Supabase: upgrading from PG 15 to 17 (breaking change)"
• supacloud.de – Managed Supabase Hosting