Supabase pasa de Kong a Envoy en self-hosted

En pocas palabras: La semana del 9 de agosto de 2026, Supabase self-hosted reemplaza a Kong por Envoy como proxy y API gateway por defecto. Es un breaking change anunciado el 17 de julio: Kong queda como override opcional. Supabase Cloud no requiere ninguna acción.

Supabase confirmó que la semana del 9 de agosto de 2026 el Supabase self-hosted proxy por defecto pasa de Kong a Envoy. El anuncio salió en la entrada del 17 de julio del changelog oficial y es un breaking change que afecta solo a instalaciones auto-administradas. Si estás en Supabase Cloud, no tenés que hacer absolutamente nada.

Envoy es un proxy y API gateway open source escrito en C++ que en Supabase self-hosted recibe las requests de los clientes, las enruta a los servicios internos (Auth, PostgREST, Realtime, Storage, Edge Functions, postgres-meta y Studio) y aplica autenticación por API key traduciendo las claves opacas apikey a las credenciales internas que cada servicio entiende. Kong hacía exactamente eso hasta ahora y va a seguir disponible, pero como override opcional.

¿A quién afecta el cambio de proxy en Supabase?

Solo a quienes corren Supabase self-hosted, o sea el stack de Docker Compose en tu propia infraestructura. Los proyectos gestionados en la plataforma de Supabase quedan intactos: sin cambio de configuración, sin downtime, sin acción de tu parte. Este es el primer punto que conviene internalizar porque el titular genera pánico innecesario.

Los de digitalapplied, que corren Supabase en producción para clientes, lo dejan clarísimo: están en la plataforma hosteada y justamente por eso no tienen nada que tocar. Vale la aclaración porque el titular del cambio se lee como si afectara a todo el mundo.

Fijate en qué categoría caés antes de seguir leyendo.

Tu setup	¿Te afecta?	Acción requerida
Supabase Cloud (hosted)	No	Ninguna
Self-hosted con Kong default sin customizar	Sí, leve	Probar Envoy en staging
Self-hosted con HTTPS listener en Kong	Sí, rompe	Poner reverse proxy adelante
Self-hosted con kong.yml custom (rutas/plugins/ACLs)	Sí, rompe	Portar config caso por caso
Self-hosted que ya usa el override de Envoy	No	Ninguna, ya estás del otro lado

¿Qué cambio anuncia Supabase para agosto 2026?

El gateway por defecto del stack self-hosted deja de ser Kong y pasa a ser Envoy, con la fecha estimada en la semana del 9 de agosto de 2026. Envoy no aparece de la nada: viene shippeando como override opcional vía docker-compose.envoy.yml desde hace varias releases. Lo que cambia el 9 de agosto es cuál de los dos es el default y cuál el opcional.

Esa distinción importa más de lo que parece. No es que Supabase esté estrenando un componente sin rodaje en la semana del deploy, es que le da vuelta el interruptor a algo que ya venía corriendo en producción en instalaciones que optaron por probarlo. Kong tampoco desaparece del repo, queda como el override que antes era Envoy, así que si necesitás quedarte con Kong un tiempo más podés hacerlo.

¿Eso quiere decir que podés ignorar el tema hasta septiembre? No. Si actualizás el stack sin mirar, te levantás con otro gateway. Lo explicamos a fondo en diferencias entre PostgreSQL y Supabase.

¿Por qué Supabase abandona Kong como proxy por defecto?

La causa es el licenciamiento de Kong, una decisión comercial de Kong Inc., no algo que Supabase haya roto ni una falla técnica del gateway. Cuando el proyecto que ponés como default en un stack open source cambia sus términos, el mantenedor tiene dos opciones: bancarse la incertidumbre o mover el default a algo con una licencia que no lo ate. Supabase eligió lo segundo.

Es un patrón que ya vimos en otros lados del ecosistema. Un proyecto arranca con licencia permisiva, gana adopción como componente por defecto de media docena de stacks, y después ajusta el licenciamiento cuando la base instalada ya es grande. Los que tienen el componente adentro de su distribución se comen el problema aunque nunca hayan tocado una línea del código.

Envoy, del lado de las ventajas, tiene defaults más endurecidos en materia de seguridad y una arquitectura pensada para enrutamiento a escala. Y es un proyecto de la CNCF con licencia Apache 2.0, sin edición enterprise que te tironee. Para un stack que la gente instala en su propio server, esa previsibilidad legal vale bastante más que un par de milisegundos de latencia (que igual no vienen mal).

¿Qué es Envoy y cómo funciona como API gateway en Supabase?

Envoy en Supabase self-hosted es la puerta de entrada de todo el tráfico: acepta las requests entrantes, las rutea al servicio interno que corresponde y aplica la autenticación por API key. Según la documentación oficial de self-hosting, los servicios detrás del gateway son Auth, PostgREST, Realtime, Storage, Edge Functions, postgres-meta y Studio.

La parte interesante es cómo maneja las credenciales. El gateway toma la clave opaca que mandás en el header apikey y la traduce a las credenciales internas que usan los servicios de atrás. O sea que la validación de API keys no vive en cada servicio por separado sino en el borde, y los servicios internos confían en lo que el gateway les pasa. Si alguna vez configuraste un stack con auth distribuida en cada microservicio, sabés lo que se agradece tener eso centralizado en un solo lugar.

• Puerto: Envoy levanta en el mismo puerto que usaba Kong (8000 por defecto), así que los clientes no ven diferencia.
• Alias de red: el servicio Envoy expone también el alias kong, y el servicio Kong expone el suyo. Cualquiera de los dos hostnames resuelve al gateway que esté activo.
• Retrocompatibilidad: gracias a ese alias, los configs internos que tienen hardcodeado el hostname del gateway viejo (por ejemplo en Edge Functions o Studio) siguen funcionando sin tocar nada.
• Dependencias: el override reconfigura el servicio Functions para que espere a Envoy en vez de al gateway anterior.

La docs aclara algo que conviene tener presente: esa guía explica la arquitectura y la postura de seguridad del gateway para operadores, no es un tutorial de Envoy. Para filtros, rutas y clusters hay que ir a la documentación de Envoy directamente.

¿Cómo configurar Supabase con Envoy en docker-compose?

Envoy se activa como un override de Docker Compose, no como una edición del docker-compose.yml principal. Si el stack ya está corriendo desde el setup inicial, primero lo bajás, después habilitás el override docker-compose.envoy.yml y volvés a levantar. El override deshabilita el gateway Kong por defecto y arranca Envoy en el mismo puerto. Más contexto en automatizar el despliegue de tu infraestructura.

Para verificar que quedó bien hay dos chequeos. Uno: una request con el header apikey y tu service role key tiene que devolver respuesta de PostgREST, lo que confirma que el gateway está ruteando. Dos: una request sin ese header tiene que devolver el rechazo correspondiente, lo que confirma que la aplicación de API keys está activa. Si el primero funciona y el segundo también pasa, tenés el gateway mal configurado y estás exponiendo la base.

Probá esto hoy, no el 9 de agosto.

¿Qué configuraciones de Kong rompen con Envoy?

Dos setups rompen en el cutover, según el análisis de digitalapplied sobre la migración: depender del listener HTTPS incorporado de Kong, y correr un kong.yml customizado con rutas, plugins o ACLs propios. Todo lo demás, en una instalación estándar, debería pasar sin drama.

Ponele que terminaste la TLS directamente en Kong porque era lo que estaba a mano y no querías montar otra pieza. Al cambiar el gateway esa terminación desaparece y te quedás sirviendo HTTP plano, o directamente sin servicio, según cómo tengas el firewall. La mitigación es poner un reverse proxy adelante que haga la terminación TLS, algo que en la mayoría de los deployments serios ya está de todos modos.

El segundo caso es más laborioso. Las rutas, plugins y ACLs de Kong no son portables a Envoy: son formatos de configuración distintos con modelos de extensión distintos. No hay conversor mágico. Hay que mirar qué hace cada pieza custom y decidir si se reimplementa como filtro de Envoy, se mueve al reverse proxy frontal, o se elimina porque en realidad no la usaba nadie desde hace un año y medio (pasa más seguido de lo que uno admite).

¿Cómo prepararse para el cambio antes de agosto?

El checklist es corto y se puede hacer en una tarde. Lo importante es hacerlo antes de la semana del 9 de agosto, porque descubrir que tu gateway custom no arranca mientras el equipo te pregunta por qué la app tira 502 no es la mejor forma de enterarte.

• Auditá tu config de Kong actual. Abrí el kong.yml y fijate si hay rutas, plugins o ACLs que vos o alguien del equipo hayan agregado. Si está tal cual vino, ya ganaste la mitad.
• Chequeá quién termina la TLS. Si el certificado está cargado en Kong, ese es tu punto de rotura número uno.
• Backupeá el docker-compose.yml y los configs del gateway. Copia fuera del directorio del stack, no un .bak al lado que se te va a pisar en el próximo pull.
• Levantá el override de Envoy en staging. Ya está disponible hoy, no hace falta esperar. Corré la batería completa: Auth, queries por PostgREST, Realtime, uploads a Storage, Edge Functions.
• Verificá la aplicación de API keys. Con y sin header apikey, y con anon key contra service role key.
• Documentá el rollback. Volver a Kong es cambiar qué override usás, pero escribí el comando exacto en algún lado antes de necesitarlo a las 3 de la mañana.

Si tu instalación es la estándar del repo, sin customizaciones, esto se resuelve en un par de horas de staging. Si tenés un kong.yml con historia, presupuestá un par de días y arrancá esta semana.

¿Qué ventajas técnicas tiene Envoy sobre Kong?

La ventaja concreta y verificable es la licencia: Envoy es Apache 2.0 bajo la CNCF, sin la incertidumbre de licenciamiento que motivó el cambio. Después vienen los defaults de seguridad más endurecidos que menciona la documentación de Supabase, y una arquitectura de enrutamiento pensada desde el día uno para operar como proxy de borde y sidecar en entornos grandes. Complementá con elegir tu herramienta de CI/CD.

Sobre performance, cuidado con los números que circulan. No vi benchmarks publicados por Supabase comparando Kong contra Envoy en este stack puntual, así que cualquier cifra de “X% más rápido” que encuentres en un thread tomala con pinzas hasta que alguien la reproduzca con tu carga real. Lo que sí podés medir vos mismo: levantá el override en staging, tirale carga con tu patrón de tráfico y compará latencias p95. Ese número te sirve más que cualquier benchmark de laboratorio.

La retrocompatibilidad del alias de red es la decisión de diseño que más me gusta de toda la migración. Es lo que separa un cambio de default bien hecho de uno que te obliga a hacer grep de un hostname en todo el repo.

Errores comunes al migrar el gateway de Supabase

• Asumir que Supabase Cloud también cambia. Es el error más difundido y el más fácil de descartar: si tu proyecto vive en la plataforma gestionada, no hay nada que preparar. Corrección: verificá dónde corre tu instancia antes de armar un plan de migración que no necesitás.
• Probar el override sin ejercitar todos los servicios. Mucha gente levanta Envoy, hace un SELECT por PostgREST, ve que responde y da por cerrado el testing. Realtime y Storage tienen patrones de conexión distintos (WebSockets, uploads multipart) y son los que se rompen callados. Corrección: probá los siete servicios, no uno.
• Dejar la terminación TLS sin resolver hasta el cutover. Si hoy Kong sirve tu HTTPS, montar un reverse proxy adelante implica tocar DNS, certificados y probablemente el firewall. Eso no se improvisa el día del cambio. Corrección: montá el reverse proxy ahora y dejá a Kong sirviendo HTTP plano detrás, así el cambio de gateway después es transparente.
• Intentar portar plugins de Kong uno a uno. Buscar el equivalente exacto de cada plugin en Envoy es la receta para pasar tres días peleando con filtros. Corrección: preguntate primero qué problema resolvía cada plugin y si ese problema sigue existiendo. Varios se resuelven mejor en el reverse proxy frontal.

Qué significa esto para equipos en Latinoamérica

Para los equipos de la región que eligieron self-hosting, y son bastantes, el driver casi siempre es el mismo: soberanía de datos, costos en dólares que pegan distinto, o requisitos de compliance que piden la base en infraestructura propia. Esos son los que tienen que hacer la tarea, y son también los que suelen tener el stack más customizado porque lo fueron adaptando a mano.

Si estás corriendo Supabase en un VPS local, el trabajo previo es el mismo que en cualquier lado: staging, batería de pruebas, rollback documentado. Para infraestructura y dominios en Argentina, donweb.com es una opción con soporte en español y facturación local, que a la hora de un cutover a las 2 de la mañana no es un detalle menor. El punto de fondo: un cambio de gateway se prueba con la misma seriedad tenga el server donde tenga.

Preguntas Frecuentes

¿Qué es Envoy en Supabase?

Envoy es el API gateway que en Supabase self-hosted recibe las requests de los clientes, las rutea a los servicios internos (Auth, PostgREST, Realtime, Storage, Edge Functions, postgres-meta y Studio) y valida las API keys traduciendo las claves opacas a credenciales internas. Es un proyecto open source de la CNCF con licencia Apache 2.0.

¿Cuándo cambia Supabase de Kong a Envoy?

La semana del 9 de agosto de 2026, según el anuncio del 17 de julio en el changelog de Supabase. Envoy ya está disponible como override opcional desde varias releases atrás, así que podés adelantarte y probarlo hoy mismo en staging.

¿Supabase Cloud necesita cambiar de proxy?

No. El cambio está acotado a deployments self-hosted. Los proyectos gestionados en la plataforma de Supabase no requieren ningún cambio de configuración, no tienen downtime asociado ni acción pendiente de tu parte. Tema relacionado: alternativas a Supabase que tienes disponibles.

¿Cómo migrar de Kong a Envoy en Supabase?

Bajás el stack, habilitás el override docker-compose.envoy.yml y volvés a levantar. El override deshabilita Kong y arranca Envoy en el mismo puerto (8000 por defecto), con un alias de red que mantiene funcionando los configs internos que apuntan al hostname del gateway anterior.

¿Puedo seguir usando Kong después de agosto de 2026?

Sí. Kong no desaparece del repositorio, se invierte a override opcional. Después del cambio, quedarte con Kong es cuestión de activar el override correspondiente, del mismo modo que hoy se activa el de Envoy.

¿Qué pasa si tengo un kong.yml customizado?

Las rutas, plugins y ACLs personalizados de Kong no son portables a Envoy y hay que analizarlos caso por caso. La recomendación es auditar qué problema resuelve cada pieza custom y decidir si se reimplementa como filtro de Envoy, se mueve a un reverse proxy frontal o se descarta.

Conclusión

El cambio es real pero manejable, y el scope es la mitad de la respuesta: si estás en Supabase Cloud, cerrá esta pestaña y seguí con lo tuyo. Si sos self-hoster, tenés hasta la semana del 9 de agosto de 2026 y el override de Envoy ya está disponible para probarlo hoy.

Los dos puntos de rotura están identificados, terminación TLS en Kong y kong.yml customizado, así que la auditoría es corta: abrís el archivo, mirás si alguien lo tocó, chequeás dónde vive el certificado. Con eso ya sabés si esto te lleva dos horas o dos días.

Lo que no haría es esperar al 9 de agosto para enterarte. Levantá el override en staging esta semana, pasá la batería completa por los siete servicios y anotá el rollback en algún lado que no sea tu memoria.

Fuentes

• Supabase Changelog – anuncios oficiales de cambios en la plataforma y el stack self-hosted
• Envoy API Gateway | Supabase Docs – arquitectura, configuración y postura de seguridad del gateway
• Supabase Self-Hosted Moves to Envoy: Breaking-Change Prep – análisis de scope y checklist de preparación