API Gateway auto-hospedado: cuándo vale la pena instalar Kong, Traefik o similar

"API gateway" es una de las categorías más sobrecargadas de jerga en la arquitectura de back-end. El término se volvió paraguas para cosas que un reverse proxy simple ya hace hace veinte años — enrutar, terminar TLS, balancear entre instancias — mezcladas con cosas que de hecho exigen un componente dedicado: validación de clave de API por cliente, límite de peticiones por usuario, transformación del cuerpo de la petición, agregación de múltiples back-ends en una sola respuesta. La confusión vende mucho producto. Y hace que muchas startups instalen un componente crítico que no necesitaban — pagando después en latencia, RAM, complejidad operacional y superficie de fallo.

Este post separa lo que cada cosa cubre, lista los cinco jugadores principales con números honestos de consumo de recursos, y dibuja una regla práctica: cuándo el reverse proxy embebido en el orquestador resuelve, cuándo vale levantar un Traefik standalone, y cuándo de hecho necesitas un Kong con plug-ins de autenticación. La audiencia es el tech lead que está mirando el stack actual y tratando de decidir si el siguiente dolor merece un componente más en el camino crítico — o si el dolor es falso.

TL;DR — instalar gateway dedicado es decisión cara, mantén la regla corta

Reverse proxy simple cubre el tronco del problema: HTTPS terminado, certificados Let's Encrypt automáticos, enrutamiento por host y ruta, balanceo entre back-ends, health check, compresión. Para un SaaS B2B típico con web app + algunos micro-servicios HTTP, eso basta. No hace falta instalar Kong, no hace falta Tyk, no hace falta KrakenD.

API gateway dedicado se vuelve inversión defendible cuando aparecen tres señales simultáneas: publicas una API para que terceros la consuman (no solo tu propia web/mobile), necesitas límite de peticiones por clave de cliente (no por IP), y quieres documentación interactiva con tentar-aquí para los consumidores. En ese escenario, Kong, Tyk o Traefik con middlewares ricos pagan su propio coste. Fuera de ese escenario, estás añadiendo 100–300 MB de RAM en el camino crítico, de 1 a 3 milisegundos de latencia por petición, y un componente más que puede caer en producción — a cambio de funcionalidades que nadie va a usar.

La regla más simple que conocemos: si tu cliente final es una persona abriendo un navegador, basta con reverse proxy. Si tu cliente final es un desarrollador con clave de API, considera el gateway. Todo lo demás es variación sobre esas dos líneas.

Lo que un reverse proxy simple ya cubre, y lo que aún falta

Antes de comparar gateways, vale fijar el suelo. Un reverse proxy decente — Caddy, nginx, o el router integrado de un orquestador moderno — entrega bastante cosa gratis. Esta lista representa el estado del arte en 2026, no el mínimo histórico:

• Terminación HTTP/HTTPS con HTTP/2 y HTTP/3. El proxy habla con el cliente en cualquier protocolo moderno y habla con el back-end en HTTP/1.1 limpio si es el caso.
• Certificados Let's Encrypt automáticos. Emisión, renovación a los 60 días, recuperación de error. Hoy eso es commodity — cualquier router serio lo hace.
• Enrutamiento por host y ruta. api.ejemplo.com va a un back-end, app.ejemplo.com va a otro, /v1/usuarios va a un tercero. Reglas con prefijo, regex y prioridad.
• Balanceo entre instancias. Round-robin, menos conexiones, hash por IP. Suficiente para distribuir carga entre las réplicas de un mismo servicio.
• Health check activo y pasivo. Saca instancia enferma del pool. La re-incluye cuando vuelve.
• Compresión gzip y brotli. Negocia con el cliente, comprime lo que vale la pena.
• Caché de contenido estático. Para archivos inmutables, evita la ida al back-end.
• Límite básico por IP. Treinta peticiones por segundo por dirección, por ejemplo. Cubre buena parte del abuso tonto.
• Timeouts y reintentos. Falla rápido, intenta de nuevo en un back-end alternativo si es el caso.
• Cabeceras de proxy. X-Forwarded-For, X-Real-IP, X-Forwarded-Proto. El back-end ve al cliente real.

Eso es mucha cosa. Para 80% de las aplicaciones web de SaaS B2B, es todo lo que se necesita en el camino de entrada. Lo que el reverse proxy simple no cubre es lo que diferencia al gateway:

• Validación de clave de API por cliente. Cada consumidor recibe una clave, el gateway valida, identifica al cliente, y usa esa identidad para límites y auditoría.
• Validación de token JWT con claves rotables. El gateway baja las claves públicas del emisor, valida firma y tiempo, expone claims al back-end.
• Límite de peticiones por clave/usuario/ruta. Cliente A puede hacer 1.000 llamadas/hora; cliente B, 100. Por ruta, por día, con ventana deslizante. Difícil de hacer en proxy simple.
• Transformación de petición y respuesta. Añadir/quitar cabeceras, reescribir cuerpo JSON, traducir entre versiones de la API.
• Versionado por cabecera o ruta. Convivir con clientes en v1 mientras v2 gana tracción. Política de descontinuación.
• Agregación de back-ends. Endpoint compuesto que llama a tres micro-servicios y devuelve una respuesta unificada (patrón back-end-for-frontend).
• Validación de esquema de la petición. Rechazar en el gateway lo que no encaja con el contrato OpenAPI antes de tocar al back-end.
• Portal de documentación con tentar-aquí. Página interactiva para que los desarrolladores exploren la API.
• Métricas granulares por clave de API. Quién llamó, cuánto, cuándo, con qué latencia. Vital si la API es el producto.

Cada item de esa segunda lista es una feature que cuesta caro hacer en código de aplicación esparcido. Si necesitas la mayoría, el gateway paga. Si no necesitas casi nada — que es el caso común en SaaS de producto — el gateway es peso muerto.

Los cinco jugadores que importan en 2026

El mercado se asentó. Hay cinco elecciones defendibles para gateway auto-hospedado, con perfiles razonablemente distintos. Los números de RAM y latencia abajo se miden con configuración por defecto y workload modesto (algunas decenas de llamadas por segundo); plug-ins pesados o volumen alto cambian todo.

Kong (basado en Lua, sobre OpenResty)

El nombre más conocido de la categoría. Kong empezó en 2015 y tiene el catálogo más grande de plug-ins del espacio — autenticación OAuth, validación JWT, transformación, log a Elasticsearch, integración con cofres externos, todo pre-listo. La versión de código abierto cubre la mayoría de los casos; la pagada añade portal de desarrollador más pulido, RBAC fino, y soporte con SLA.

Recursos: mínimo realista de 200 MB de RAM por instancia, más la base de datos si no usas modo sin-base. Latencia añadida de 1 a 2 milisegundos por petición en llamada simple. Plug-ins pesados (validación de esquema con OpenAPI grande, transformación JSON compleja) pueden duplicar eso.

Cuándo tiene sentido: API pública seria con varios consumidores externos, necesidad de plug-ins del catálogo, equipo dispuesto a aprender Lua si necesita customizar. Empresa de medio de pagos, plataforma de comunicación, cualquier negocio donde la API es el producto vendido.

Trampa: el modo con PostgreSQL coloca la base en el camino crítico. La base se cae, el gateway no actualiza configuración. Usa el modo sin-base (configuración declarativa vía archivo) siempre que sea posible — elimina esa dependencia.

Traefik (escrito en Go, hablando varios proxies de orquestador)

Conocido como controlador de entrada de Kubernetes, pero tiene middlewares ricos lo suficiente para cubrir muchos casos de gateway. Límite de peticiones por cliente, validación básica de JWT, transformación de cabecera, redirecciones complejas, autenticación reenviada (delegando a servicio externo). Versión pagada añade plug-ins comerciales y dashboard más robusto.

Recursos: 50 a 100 MB de RAM, latencia añadida de 0,5 a 1 milisegundo. Discovery automático de back-ends vía etiquetas de contenedor es el punto fuerte — no escribes configuración de ruta, ella aparece cuando el servicio sube.

Cuándo tiene sentido: ya estás usando Traefik como router de entrada y quieres evitar añadir un componente más; necesitas middlewares razonables pero no del catálogo gigante de Kong; valoras configuración declarativa por etiqueta en lugar de base de datos.

Trampa: algunos patrones avanzados (agregación de llamadas, validación OpenAPI completa, portal de documentación interactivo) no caben en Traefik. Si necesitas eso, la tentación de "estirar" Traefik vía plug-ins customizados lleva a complejidad que Kong resolvería de forma más limpia.

Tyk (escrito en Go, foco en portal de desarrollador)

La versión de código abierto entrega mucho más que la mayoría — límite de peticiones por clave, gestión de claves, portal de desarrollador, todos en el plan gratis. La versión pagada añade panel multi-tenant, replicación multi-región, y soporte.

Recursos: 100 MB de RAM, latencia añadida de 1 a 2 milisegundos. Base de datos (Redis) es parte central de la arquitectura — límite de peticiones y contadores viven ahí.

Cuándo tiene sentido: API con muchos consumidores externos, portal de desarrollador es parte del producto, quieres pagar menos de lo que Kong cobra por el equivalente en recursos. Equipos pequeños publicando API para socios han encontrado buen encaje aquí.

Trampa: menos plug-ins listos que Kong. Si tu integración esperada existe en la lista de Kong pero no en la de Tyk, el trade-off cambia.

KrakenD (escrito en Go, sin base de datos, foco en agregación)

KrakenD es el gateway pequeño que se especializa en agregación. Configuración 100% en archivo, sin estado externo, diseñado para componer endpoints — el cliente hace una llamada, KrakenD llama a tres back-ends en paralelo y devuelve una respuesta combinada. Excelente para patrón back-end-for-frontend.

Recursos: 50 MB de RAM, latencia añadida de 0,5 milisegundo. El más liviano de la categoría. Sin base, sin panel — todo es archivo de configuración estático.

Cuándo tiene sentido: tienes múltiples micro-servicios y quieres exponer una API más limpia al front-end mobile/web. No necesitas gestión dinámica de claves ni portal de desarrollador. Te gusta la configuración inmutable: cambias archivo, haces deploy nuevo, listo.

Trampa: todo es estático. Añadir una clave nueva es deploy. Para equipo pequeño eso es simplificación; para plataforma de API con terceros registrándose, se vuelve cuello de botella.

Envoy Gateway (CNCF, sobre proxy Envoy)

El benjamín serio de la lista. Envoy es el proxy de altísimo rendimiento usado en mallas de servicio grandes. Envoy Gateway es el proyecto que empaqueta Envoy como gateway de API con configuración declarativa. Foco en Kubernetes, alta tasa de transferencia, integración con malla.

Recursos: Envoy puro consume 50 a 100 MB en el proxy de datos; el plano de control pesa más. Latencia añadida baja (< 1 milisegundo) en llamada simple. Pero la complejidad operacional es la más alta de la lista.

Cuándo tiene sentido: ya corres malla de servicio con Envoy (Istio, Consul, Linkerd con proxy compatible) y quieres consistencia de configuración entre malla y gateway. Operas en escala lo suficientemente alta para que la tasa de Envoy importe (decenas de miles de peticiones por segundo).

Trampa: para startup con 4 servidores y algunas decenas de peticiones por segundo, Envoy Gateway es overkill por dos o tres tamaños. La complejidad de configuración no se paga.

¿Cuándo basta un reverse proxy simple?

Esta es la pregunta que ahorra dinero. La respuesta honesta es: en la gran mayoría de los SaaS B2B que vemos corriendo, basta. Los criterios para "basta":

• Público de tu API es tu propia aplicación. Web, mobile, integraciones internas. No hay terceros desconocidos llamando endpoints con claves emitidas por ti.
• Autenticación ocurre en la aplicación, no en el camino. Sesión por cookie, token JWT emitido por el propio back-end y validado por middleware de la aplicación, OAuth vía biblioteca dentro del código. El proxy no necesita ver al usuario.
• Límite de peticiones es "evita abuso tonto". Treinta por segundo por IP, quizás. No hay plan comercial que limite Cliente A a 1.000 llamadas/día y Cliente B a 10.000.
• No necesitas combinar back-ends. Cada llamada del front-end va a un endpoint, ese endpoint llama a lo que necesita internamente. Sin agregación en el camino.
• Documentación de la API es interna o inexistente. No hay portal de desarrollador con tentar-aquí para terceros.
• Versionado, si existe, se gestiona en código. El back-end enruta internamente entre v1 y v2 cuando es necesario. No hay política formal en el gateway.

Si cinco de los seis items de arriba son verdad, instalar gateway dedicado es caro por el beneficio real. Reverse proxy embebido en el orquestador, o Caddy/nginx standalone, cubre todo.

¿Cuándo vale la pena un gateway dedicado?

La inversión de la lista anterior. Gateway compensa cuando aparecen algunos de estos:

• API pública es parte del producto. Cobras (o planeas cobrar) por uso de API. Terceros se registran, reciben clave, consumen.
• Límite por clave/usuario/ruta es regla de negocio. Plan gratis tiene techo, plan pagado tiene techo mayor, plan enterprise se negocia. Ese límite necesita vivir en algún lugar — gateway es el lugar correcto.
• Múltiples back-ends necesitan combinarse en una respuesta. Patrón back-end-for-frontend, agregación de micro-servicios, fan-out y fan-in. Costes altos en la aplicación, costes modestos en el gateway.
• Versionado formal de API. Soportas v1 y v2 simultáneamente, con fecha de descontinuación anunciada. Cabecera Accept-Version o ruta /v2/. Cliente legacy no puede romperse.
• Autenticación compleja. Validación de JWT emitido por tercero, con claves públicas bajadas y cacheadas, con rotación automática. OAuth con varios proveedores. Autenticación por certificado de cliente (mTLS) para integraciones entre empresas.
• Portal de desarrollador con tentar-aquí. Documentación interactiva, gestión de clave self-service, panel de uso para el consumidor.
• Métricas por clave de API. Quién llama qué, cuándo, latencia por consumidor. Dashboards comerciales, informes de uso, SLA por cliente.

Tres o más de esos criterios verdaderos, gateway es defendible. Uno o dos, aún se puede resolver de otras formas (autenticación en la aplicación, límite por aplicación, métricas estructuradas en el log).

Router integrado de HeroCtl — dónde queda en esa regla

El router embebido en HeroCtl no intenta ser gateway. Cubre el lado de reverse proxy bien hecho: HTTPS terminado, Let's Encrypt automático con renovación, enrutamiento por host y ruta, balanceo entre las réplicas que el orquestador subió, health check coordinado con el agente en cada nodo, compresión, cabeceras de proxy, límite básico por IP, política de reintento en caso de fallo de back-end.

Lo que el router integrado no hace: validación de clave de API por consumidor, límite por clave/usuario, transformación de cuerpo, agregación de back-ends, validación de esquema OpenAPI, portal de desarrollador. Para los 80% de los casos donde el cliente final es navegador o app mobile de la propia empresa, el router embebido cubre el camino de entrada entero — no instalas nada más al frente.

Para los 20% que necesitan gateway dedicado, el camino es directo: instala Kong, Traefik standalone, Tyk o KrakenD como un job más en el cluster, detrás del router embebido. El router termina TLS en la borda, el gateway hace el trabajo de gateway, los back-ends quedan detrás. Sin ceremonia, sin dependencia circular.

El plano de control de HeroCtl ocupa entre 200 y 400 MB por servidor — o sea, un Kong instalado añade prácticamente el mismo peso del plano de control entero. Vale recordar el orden de magnitud antes de "solo instalar".

Tabla comparativa — 12 criterios

La tabla tiene zonas claras. Las tres primeras columnas resuelven el camino de entrada con peso bajo. Las cuatro últimas resuelven camino de entrada más trabajo de gateway, con peso y complejidad crecientes.

Stack típica por etapa de la empresa

Esta es la regla que recomendamos. No es prescripción rígida — es lo que vemos funcionar en equipos de SaaS.

MVP (1 back-end, 1 desarrollador). Caddy standalone en un servidor, o router embebido si ya estás en orquestador. No instalas nada. No piensas en gateway. Foco en el producto.

Indie hacker (3 a 5 back-ends, equipo de 1 a 3). Router embebido en el orquestador, punto. El camino de entrada ya cubre lo que importa. Autenticación en la aplicación, límite básico por IP en el proxy. Tiempo gastado con gateway es tiempo no gastado en feature del producto.

Startup early (10 a 20 back-ends, primeros consumidores externos de la API). Hora de evaluar. Si la API externa es experimento que aún puede morir, deja la autenticación en la aplicación y límite por clave en una biblioteca compartida. Si la API es parte central de la promesa del producto, instala Traefik standalone con middlewares de autenticación y límite, o Tyk OSS por el portal incluido. Kong en esta fase suele ser pesado de más.

Startup mid (50+ back-ends, plataforma de API pública se vuelve producto). Kong OSS o Tyk pagado. Necesitas plug-ins, portal robusto, gestión de clave self-service, métricas comerciales. El peso de Kong ahora se justifica — estás cobrando por uso de API y el gateway es ingreso, no coste.

Empresa grande (cientos de servicios, integraciones con socios serios). Kong Enterprise o Envoy Gateway, dependiendo del contexto. Equipo dedicado cuidando del gateway. Política formal de versionado, descontinuación, SLA por cliente.

La migración natural — reverse proxy → Traefik/Tyk → Kong — funciona porque cada peldaño resuelve dolor real del peldaño anterior. Saltar peldaños es caro: instalar Kong en la fase de MVP es poner un camión para entregar una pizza.

Los 4 errores caros más comunes con gateway

Los tropiezos que vemos en producción:

Instalar Kong con PostgreSQL en el camino crítico sin necesidad. El modo sin-base existe y es perfecto para la mayoría de los casos. Configuración declarativa vía archivo, sin dependencia externa, sin punto extra de fallo. Muchos equipos caen en la configuración por defecto con base y descubren eso solo cuando la base queda indisponible y el gateway no consigue más propagar cambios. Si necesitas gestión dinámica de claves (consumidores registrándose self-service), base compensa. Si no, modo sin-base.

No monitorizar el gateway con la misma severidad que los back-ends. Gateway al frente se vuelve caja-negra de fácil olvido. Latencia crece 5 ms, tasa de error va de 0,01% a 0,5%, nadie lo nota hasta que el cliente reclama. Métricas de gateway (latencia por ruta, tasa de error 4xx/5xx, uso de memoria, lag de propagación de configuración) merecen dashboard propio y alertas, no solo inclusión tímida en el panel general.

Plug-in customizado en Lua/JS corriendo en producción. Kong permite plug-in customizado en Lua. Tyk en JavaScript. Tentación enorme para resolver "solo esa transformación" en el gateway. Bug en ese plug-in derriba el gateway entero — bug que tú creaste, sin test de carga, en el camino crítico de todo. Si necesitas transformación custom, hazla en micro-servicio detrás del gateway. Plug-in customizado solo con revisión seria, test de carga, y plan de rollback automático.

Versión del gateway desactualizada. Kong, Envoy y Tyk reciben CVEs (vulnerabilidades de seguridad) con regularidad. Gateway está expuesto a internet — superficie de ataque relevante. Versión de hace 18 meses es vulnerabilidad conocida acumulando. Hazlo parte del ciclo de mantenimiento: actualizar el gateway es tan importante como actualizar el sistema operativo.

Escenarios reales en los que NO instalar gateway

Lista fuerte. Si estás en alguno de estos, evita el gateway dedicado aunque el tema aparezca en el consejo:

• SaaS web con 5 endpoints, sin API externa pública. Cliente final es el navegador. Autenticación por sesión. Reverse proxy resuelve el camino de entrada entero. Añadir gateway aquí es vanidad arquitectónica.
• Equipo pequeño (1 a 3 desarrolladores). Curva de aprendizaje de Kong cuesta de dos a cuatro semanas de productividad total del equipo. En equipo de 3 personas, eso es trimestre de feature parado. A no ser que el gateway resuelva dolor concreto hoy, posponlo.
• Workload donde latencia sub-10ms es requisito duro. Trading de baja latencia, subasta en tiempo real, juego multijugador. Cada milisegundo cuenta. Gateway añade 1 a 3 ms — en workload sensible, es caro. Coloca la inteligencia en la aplicación.
• Aplicación monolítica sin agregación. El monolito atiende al front-end directo, sin composición entre servicios. No hay qué agregar. Gateway es solución buscando problema.
• Cumplimiento que prefiere superficie de ataque mínima. Cada componente expuesto a internet es un item más para auditoría, un parche más a aplicar, un log más a guardar. Si la auditoría valora minimalismo, justifica cada componente — gateway que no cubre dolor concreto es minus.

Preguntas frecuentes

¿Kong sin base es estable en 2026? Sí. El modo declarativo (db_less = on) es maduro, recomendado por el propio Kong para gran parte de los casos, y elimina PostgreSQL como dependencia. Pierdes gestión dinámica de clave vía API admin (necesitas hacer deploy de configuración nueva), pero ganas simplicidad operacional enorme. Para equipo pequeño, el cambio casi siempre vale.

¿Traefik hace todo lo que Kong hace? No. Traefik con middlewares cubre la mayoría de los casos comunes — autenticación básica, límite por clave simple, transformación de cabecera, reenvío de autenticación. No cubre catálogo de plug-ins de Kong, validación OpenAPI nativa, portal de desarrollador robusto, integraciones comerciales listas. Si tu dolor cabe en middleware de Traefik, queda en Traefik (más liviano, más simple). Si necesitas cosa del catálogo de Kong, Kong.

¿Puedo tener dos gateways en serie? Técnicamente sí, en la práctica casi siempre es síntoma de organización confusa. Dos gateways = dos configuraciones para mantener, dos latencias sumadas, dos puntos de fallo. El caso defendible es: router de borda haciendo TLS y enrutamiento básico, gateway dedicado detrás haciendo trabajo específico (validación de clave, agregación). Eso es diferente de "dos gateways completos en serie" — es división de responsabilidad.

¿API gateway sustituye malla de servicio? No. Gateway cuida del tráfico norte-sur (cliente externo → tu sistema). Malla cuida del tráfico este-oeste (servicio interno → servicio interno). Funciones parecidas (autenticación, límite, observabilidad) pero alcance diferente. Para startup media, gateway resuelve la parte que importa; malla de servicio completa solo se vuelve inversión defendible en escala mayor. Tratamos ese límite en service mesh: cuándo vale la pena en SaaS pequeño y mediano.

¿Cuánta latencia añade Kong en llamada típica? En hardware moderno, con configuración por defecto y plug-ins livianos (validación de clave + límite por clave): 1 a 2 milisegundos por petición. Plug-ins pesados (validación OpenAPI completa en payload grande, transformación JSON compleja, log síncrono a servicio externo) pueden sumar 3 a 10 ms. Mide antes y después — no confíes en número de blog post genérico.

Proveedor de OAuth auto-hospedado — ¿Keycloak o Hydra? Keycloak es el estándar para quien quiere panel de administración robusto, federación con LDAP/SAML, gestión de usuario completa. Pesa más (1 GB de RAM mínimo, JVM). Hydra es minimalista, se enfoca solo en OAuth/OIDC, sin gestión de usuario (integras con tu sistema de usuarios existente). Para equipo pequeño que ya tiene sistema de usuario propio, Hydra es más adecuado. Para empresa que quiere un único lugar para identidad, Keycloak. Los dos hablan protocolos estándar, así que el gateway no diferencia entre ellos.

Validación de esquema — ¿OpenAPI o JSON Schema? OpenAPI (anteriormente Swagger) es el estándar para describir API HTTP — engloba rutas, métodos, petición y respuesta. Incluye JSON Schema para describir payloads. Kong, Tyk y validadores standalone hablan OpenAPI directo. JSON Schema puro es más portable (no atado a HTTP) pero exige más pegamento. Usa OpenAPI cuando el gateway lo soporte; vale tener el esquema del contrato vivo, no desactualizado.

¿Puedo hacer límite en la aplicación en lugar del gateway? Puedes. Bibliotecas como golang.org/x/time/rate o Redis con INCR resuelven límite por usuario a nivel de la aplicación. La cuestión es dónde el límite es más barato: en el gateway, antes de que el back-end sea tocado (ahorra recursos del back-end, aplica antes del trabajo empezar) o en la aplicación, con regla de negocio más cerca del código (más fácil de razonar, más fácil de testear). Para límite simple, aplicación basta. Para límite por plan comercial con múltiples niveles y auditoría, gateway es el lugar correcto.

¿Puedo usar dos gateways diferentes en rutas distintas? Puedes. Algunas empresas corren Kong para rutas "producto" (API pública vendida) y Traefik para rutas "interno" (admin, ops, cron). La justificación es que cada gateway resuelve un dolor diferente, y tener uno solo forzaría compromiso. Vale cuando los perfiles de uso de hecho divergen. No vale solo por el placer de tener variedad — dos piezas para mantener.

Cierre — empieza por el mínimo, sube cuando el dolor sea real

La trampa de la categoría "API gateway" es tratar la decisión como binaria — instalar o no — cuando es gradual. Reverse proxy bien hecho cubre 80% de las aplicaciones. Router integrado en el orquestador cubre las mismas 80% sin componente separado. Gateway dedicado es inversión defendible cuando aparecen tres o cuatro señales simultáneas: API externa pública, límite por clave, agregación, portal de desarrollador.

La regla honesta: instala el mínimo hasta que el dolor concreto fuerce el siguiente peldaño. Saltar peldaños cuesta caro en latencia, RAM, complejidad, área de fallo. Equipo pequeño que instala Kong "porque va a necesitar" pasa tres semanas configurando algo que no usa, y aún así tiene un componente más para monitorizar.

HeroCtl entrega el peldaño más bajo embebido — router integrado con TLS automático, balanceo, health check, límite por IP. Cuando el dolor de gateway aparezca de verdad, subes Kong, Traefik standalone, Tyk o KrakenD como un job más en el cluster. Sin migración dolorosa, sin ceremonia.

Para subir un cluster y probar:

curl -sSL https://get.heroctl.com/install.sh | sh

Community es gratuito para siempre, sin techo de servidores, sin techo de jobs, sin feature gate. Business añade SSO/SAML, RBAC granular, auditoría detallada y soporte con SLA. Enterprise suma escrow de código fuente, contrato de continuidad y soporte 24×7.

Posts próximos: service mesh: cuándo vale la pena en SaaS pequeño y mediano y multi-tenant SaaS: aislamiento real entre clientes. Los tres temas juntos cubren la mayor parte de las decisiones de plataforma para startup en la franja de 1 a 500 servidores.

Orquestación de contenedores, sin ceremonia. Gateway solo cuando el dolor lo pida.