API Gateway self-hosted: quando vale instalar Kong, Traefik ou similar

"API gateway" é uma das categorias mais sobrecarregadas de jargão na arquitetura de back-end. O termo virou guarda-chuva pra coisas que reverse proxy simples já faz há vinte anos — rotear, terminar TLS, balancear entre instâncias — misturadas com coisas que de fato exigem um componente dedicado: validação de chave de API por cliente, limite de requisições por usuário, transformação de corpo da requisição, agregação de múltiplos back-ends numa só resposta. A confusão vende muito produto. E faz muita startup instalar componente crítico que ela não precisava — pagando depois em latência, RAM, complexidade operacional e área de superfície de falha.

Este post separa o que cada coisa cobre, lista os cinco jogadores principais com números honestos de consumo de recursos, e desenha uma régua prática: quando o reverse proxy embutido no orquestrador resolve, quando vale subir um Traefik standalone, e quando você de fato precisa de um Kong com plug-ins de autenticação. A audiência é o tech lead que está olhando pro stack atual e tentando decidir se a próxima dor merece mais um componente no caminho crítico — ou se a dor é falsa.

TL;DR — instalar gateway dedicado é decisão cara, mantenha a régua curta

Reverse proxy simples cobre o tronco do problema: HTTPS terminado, certificados Let's Encrypt automáticos, roteamento por host e caminho, balanceamento entre back-ends, health check, compressão. Pra um SaaS B2B típico com web app + alguns micro-serviços HTTP, isso basta. Não precisa instalar Kong, não precisa Tyk, não precisa KrakenD.

API gateway dedicado vira investimento defensável quando aparecem três sinais simultâneos: você publica uma API pra terceiros consumirem (não só sua própria web/mobile), você precisa de limite de requisições por chave de cliente (não por IP), e você quer documentação interativa com tentar-aqui pros consumidores. Nesse cenário, Kong, Tyk ou Traefik com middlewares ricos pagam o próprio custo. Fora desse cenário, você está adicionando 100–300 MB de RAM no caminho crítico, de 1 a 3 milissegundos de latência por requisição, e mais um componente que pode cair em produção — em troca de funcionalidades que ninguém vai usar.

A régua mais simples que conhecemos: se o seu cliente final é uma pessoa abrindo um navegador, reverse proxy basta. Se o seu cliente final é um desenvolvedor com chave de API, considere o gateway. Tudo o mais é variação em cima dessas duas linhas.

O que reverse proxy simples já cobre, e o que ainda falta

Antes de comparar gateways, vale fixar o piso. Um reverse proxy decente — Caddy, nginx, ou o roteador integrado de um orquestrador moderno — entrega bastante coisa de graça. Esta lista representa o estado da arte em 2026, não o mínimo histórico:

• Terminação HTTP/HTTPS com HTTP/2 e HTTP/3. O proxy fala com o cliente em qualquer protocolo moderno e fala com o back-end em HTTP/1.1 limpo se for o caso.
• Certificados Let's Encrypt automáticos. Emissão, renovação aos 60 dias, recuperação de erro. Hoje isso é commodity — qualquer roteador sério faz.
• Roteamento por host e caminho. api.exemplo.com.br vai pra um back-end, app.exemplo.com.br vai pra outro, /v1/usuarios vai pra um terceiro. Regras com prefixo, regex e prioridade.
• Balanceamento entre instâncias. Round-robin, menos conexões, hash por IP. Suficiente pra distribuir carga entre as réplicas de um mesmo serviço.
• Health check ativo e passivo. Tira instância doente do pool. Re-inclui quando ela volta.
• Compressão gzip e brotli. Negocia com o cliente, comprime o que vale a pena.
• Cache de conteúdo estático. Pra arquivos imutáveis, evita ida ao back-end.
• Limite básico por IP. Trinta requisições por segundo por endereço, por exemplo. Cobre boa parte de abuso bobo.
• Timeouts e tentativas. Falha rápido, tenta de novo num back-end alternativo se for caso.
• Cabeçalhos de proxy. X-Forwarded-For, X-Real-IP, X-Forwarded-Proto. O back-end enxerga o cliente real.

Isso é muita coisa. Pra 80% das aplicações web de SaaS B2B, é tudo o que se precisa no caminho de entrada. O que reverse proxy simples não cobre é o que diferencia gateway:

• Validação de chave de API por cliente. Cada consumidor recebe uma chave, o gateway valida, identifica o cliente, e usa essa identidade pra limites e auditoria.
• Validação de token JWT com chaves rotacionáveis. O gateway baixa as chaves públicas do emissor, valida assinatura e tempo, expõe claims pro back-end.
• Limite de requisições por chave/usuário/rota. Cliente A pode fazer 1.000 chamadas/hora; cliente B, 100. Por rota, por dia, com janela deslizante. Difícil de fazer em proxy simples.
• Transformação de requisição e resposta. Adicionar/remover cabeçalhos, reescrever corpo JSON, traduzir entre versões da API.
• Versionamento por cabeçalho ou caminho. Conviver com clientes em v1 enquanto v2 ganha tração. Política de descontinuação.
• Agregação de back-ends. Endpoint composto que chama três micro-serviços e devolve uma resposta unificada (padrão back-end-for-frontend).
• Validação de esquema da requisição. Rejeitar no gateway o que não bate com o contrato OpenAPI antes de tocar no back-end.
• Portal de documentação com tentar-aqui. Página interativa pra desenvolvedores explorarem a API.
• Métricas granulares por chave de API. Quem chamou, quanto, quando, com que latência. Vital se a API é o produto.

Cada item dessa segunda lista é uma feature que custa caro pra fazer em código de aplicação espalhado. Se você precisa da maioria, gateway paga. Se você não precisa de quase nada — o que é o caso comum em SaaS de produto — gateway é peso morto.

Os cinco jogadores que importam em 2026

O mercado se assentou. Há cinco escolhas defensáveis pra gateway self-hosted, com perfis razoavelmente distintos. Os números de RAM e latência abaixo são medidos com configuração padrão e workload modesto (algumas dezenas de chamadas por segundo); plug-ins pesados ou volume alto mudam tudo.

Kong (baseado em Lua, sobre OpenResty)

O nome mais conhecido da categoria. Kong começou em 2015 e tem o maior catálogo de plug-ins do espaço — autenticação OAuth, validação JWT, transformação, log pra Elasticsearch, integração com cofres externos, tudo pré-pronto. A versão de código aberto cobre a maioria dos casos; a paga adiciona portal de desenvolvedor mais polido, RBAC fino, e suporte com SLA.

Recursos: mínimo realista de 200 MB de RAM por instância, mais o banco de dados se você não usar modo sem-banco. Latência adicionada de 1 a 2 milissegundos por requisição em chamada simples. Plug-ins pesados (validação de esquema com OpenAPI grande, transformação JSON complexa) podem dobrar isso.

Quando faz sentido: API pública séria com vários consumidores externos, necessidade de plug-ins do catálogo, time disposto a aprender Lua se precisar customizar. Empresa de meio de pagamentos, plataforma de comunicação, qualquer negócio onde a API é o produto vendido.

Pegadinha: o modo com PostgreSQL coloca o banco no caminho crítico. Banco caiu, gateway não atualiza configuração. Use o modo sem-banco (configuração declarativa via arquivo) sempre que possível — elimina essa dependência.

Traefik (escrito em Go, falando vários proxies de orquestrador)

Conhecido como controlador de entrada de Kubernetes, mas tem middlewares ricos suficientes pra cobrir muitos casos de gateway. Limite de requisições por cliente, validação básica de JWT, transformação de cabeçalho, redirecionamentos complexos, autenticação encaminhada (delegando pra serviço externo). Versão paga adiciona plug-ins comerciais e dashboard mais robusto.

Recursos: 50 a 100 MB de RAM, latência adicionada de 0,5 a 1 milissegundo. Discovery automático de back-ends via etiquetas de contêiner é o ponto forte — você não escreve configuração de rota, ela aparece quando o serviço sobe.

Quando faz sentido: já está usando Traefik como roteador de entrada e quer evitar adicionar mais um componente; precisa de middlewares razoáveis mas não do catálogo gigante de Kong; valoriza configuração declarativa por etiqueta em vez de banco de dados.

Pegadinha: alguns padrões avançados (agregação de chamadas, validação OpenAPI completa, portal de documentação interativo) não cabem em Traefik. Se você precisa disso, a tentação de "esticar" Traefik via plug-ins customizados leva a complexidade que Kong resolveria mais limpo.

Tyk (escrito em Go, foco em portal de desenvolvedor)

A versão de código aberto entrega muito mais do que a maioria — limite de requisições por chave, gerenciamento de chaves, portal de desenvolvedor, todos no plano grátis. A versão paga adiciona painel multi-tenant, replicação multi-região, e suporte.

Recursos: 100 MB de RAM, latência adicionada de 1 a 2 milissegundos. Banco de dados (Redis) é parte central da arquitetura — limite de requisições e contadores vivem ali.

Quando faz sentido: API com muitos consumidores externos, portal de desenvolvedor é parte do produto, você quer pagar menos do que Kong cobra pelo equivalente em recursos. Times pequenos publicando API pra parceiros têm encontrado bom encaixe aqui.

Pegadinha: menos plug-ins prontos do que Kong. Se a sua integração esperada existe na lista de Kong mas não na de Tyk, o trade-off muda.

KrakenD (escrito em Go, sem banco de dados, foco em agregação)

KrakenD é o gateway pequeno que se especializa em agregação. Configuração 100% em arquivo, sem estado externo, projetado pra compor endpoints — o cliente faz uma chamada, KrakenD chama três back-ends em paralelo e devolve uma resposta combinada. Ótimo pra padrão back-end-for-frontend.

Recursos: 50 MB de RAM, latência adicionada de 0,5 milissegundo. O mais leve da categoria. Sem banco, sem painel — tudo é arquivo de configuração estático.

Quando faz sentido: você tem múltiplos micro-serviços e quer expor uma API mais limpa pro front-end mobile/web. Você não precisa de gerenciamento dinâmico de chaves nem portal de desenvolvedor. Você gosta de configuração imutável: muda arquivo, faz deploy novo, pronto.

Pegadinha: tudo é estático. Adicionar uma chave nova é deploy. Pra time pequeno isso é simplificação; pra plataforma de API com terceiros se cadastrando, vira gargalo.

Envoy Gateway (CNCF, sobre proxy Envoy)

O caçula sério da lista. Envoy é o proxy de altíssimo desempenho usado em malhas de serviço grandes. Envoy Gateway é o projeto que empacota Envoy como gateway de API com configuração declarativa. Foco em Kubernetes, alta vazão, integração com malha.

Recursos: Envoy puro consome 50 a 100 MB no proxy de dados; o plano de controle pesa mais. Latência adicionada baixa (< 1 milissegundo) em chamada simples. Mas a complexidade operacional é a mais alta da lista.

Quando faz sentido: você já roda malha de serviço com Envoy (Istio, Consul, Linkerd com proxy compatível) e quer consistência de configuração entre malha e gateway. Você opera em escala alta o suficiente pra que a vazão de Envoy importe (dezenas de milhares de requisições por segundo).

Pegadinha: pra startup com 4 servidores e algumas dezenas de requisições por segundo, Envoy Gateway é overkill por dois ou três tamanhos. A complexidade de configuração não se paga.

Quando reverse proxy simples basta?

Esta é a pergunta que economiza dinheiro. A resposta honesta é: na grande maioria dos SaaS B2B brasileiros que vemos rodando, basta. Os critérios pra "basta":

• Público da sua API é a sua própria aplicação. Web, mobile, integrações internas. Não há terceiros desconhecidos chamando endpoints com chaves emitidas por você.
• Autenticação acontece no aplicativo, não no caminho. Sessão por cookie, token JWT emitido pelo próprio back-end e validado por middleware da aplicação, OAuth via biblioteca dentro do código. O proxy não precisa enxergar o usuário.
• Limite de requisições é "evite abuso bobo". Trinta por segundo por IP, talvez. Não há plano comercial que limite Cliente A a 1.000 chamadas/dia e Cliente B a 10.000.
• Você não precisa combinar back-ends. Cada chamada do front-end vai pra um endpoint, esse endpoint chama o que precisa internamente. Sem agregação no caminho.
• Documentação da API é interna ou inexistente. Não há portal de desenvolvedor com tentar-aqui pra terceiros.
• Versionamento, se existir, é gerenciado em código. O back-end roteia internamente entre v1 e v2 quando preciso. Não há política formal no gateway.

Se cinco dos seis itens acima são verdade, instalar gateway dedicado é caro pelo benefício real. Reverse proxy embutido no orquestrador, ou Caddy/nginx standalone, cobre tudo.

Quando vale gateway dedicado?

A inversão da lista anterior. Gateway compensa quando aparecem alguns destes:

• API pública é parte do produto. Você cobra (ou planeja cobrar) por uso de API. Terceiros se cadastram, recebem chave, consomem.
• Limite por chave/usuário/rota é regra de negócio. Plano gratuito tem teto, plano pago tem teto maior, plano enterprise é negociado. Esse limite precisa viver em algum lugar — gateway é o lugar certo.
• Múltiplos back-ends precisam ser combinados em uma resposta. Padrão back-end-for-frontend, agregação de micro-serviços, fan-out e fan-in. Custos altos no aplicativo, custos modestos no gateway.
• Versionamento formal de API. Você suporta v1 e v2 simultaneamente, com data de descontinuação anunciada. Cabeçalho Accept-Version ou caminho /v2/. Cliente legado não pode quebrar.
• Autenticação complexa. Validação de JWT emitido por terceiro, com chaves públicas baixadas e cacheadas, com rotação automática. OAuth com vários provedores. Autenticação por certificado de cliente (TLS mútuo) pra integrações entre empresas.
• Portal de desenvolvedor com tentar-aqui. Documentação interativa, gerenciamento de chave self-service, painel de uso pro consumidor.
• Métricas por chave de API. Quem chama o quê, quando, latência por consumidor. Dashboards comerciais, relatórios de uso, SLA por cliente.

Três ou mais desses critérios verdadeiros, gateway é defensável. Um ou dois, ainda dá pra resolver de outras formas (autenticação no aplicativo, limite por aplicativo, métricas estruturadas no log).

Roteador integrado do HeroCtl — onde ele fica nessa régua

O roteador embutido no HeroCtl não tenta ser gateway. Cobre o lado de reverse proxy bem feito: HTTPS terminado, Let's Encrypt automático com renovação, roteamento por host e caminho, balanceamento entre as réplicas que o orquestrador subiu, health check coordenado com o agente em cada nó, compressão, cabeçalhos de proxy, limite básico por IP, política de tentativa em caso de falha de back-end.

O que o roteador integrado não faz: validação de chave de API por consumidor, limite por chave/usuário, transformação de corpo, agregação de back-ends, validação de esquema OpenAPI, portal de desenvolvedor. Pra os 80% dos casos onde o cliente final é navegador ou app mobile da própria empresa, o roteador embutido cobre o caminho de entrada inteiro — você não instala mais nada na frente.

Pros 20% que precisam de gateway dedicado, o caminho é direto: instale Kong, Traefik standalone, Tyk ou KrakenD como mais um job no cluster, atrás do roteador embutido. O roteador termina TLS na borda, o gateway faz o trabalho de gateway, os back-ends ficam atrás. Sem cerimônia, sem dependência circular.

Plano de controle do HeroCtl ocupa entre 200 e 400 MB por servidor — ou seja, um Kong instalado adiciona praticamente o mesmo peso do plano de controle inteiro. Vale lembrar a ordem de grandeza antes de "só instalar".

Tabela comparativa — 12 critérios

A tabela tem zonas claras. As três primeiras colunas resolvem o caminho de entrada com peso baixo. As quatro últimas resolvem caminho de entrada mais trabalho de gateway, com peso e complexidade crescentes.

Stack típica por estágio da empresa

Esta é a régua que recomendamos. Não é prescrição rígida — é o que vemos funcionar em times brasileiros de SaaS.

MVP (1 back-end, 1 desenvolvedor). Caddy standalone num servidor, ou roteador embutido se você já está em orquestrador. Não instala nada. Não pensa em gateway. Foca no produto.

Indie hacker (3 a 5 back-ends, time de 1 a 3). Roteador embutido no orquestrador, ponto. O caminho de entrada já cobre o que importa. Autenticação no aplicativo, limite básico por IP no proxy. Tempo gasto com gateway é tempo não gasto em feature do produto.

Startup early (10 a 20 back-ends, primeiros consumidores externos da API). Hora de avaliar. Se a API externa é experimento que ainda pode morrer, deixe a autenticação no aplicativo e limite por chave numa biblioteca compartilhada. Se a API é parte central da promessa do produto, instale Traefik standalone com middlewares de autenticação e limite, ou Tyk OSS pelo portal incluso. Kong nesta fase costuma ser pesado demais.

Startup mid (50+ back-ends, plataforma de API pública vira produto). Kong OSS ou Tyk pago. Você precisa de plug-ins, portal robusto, gerenciamento de chave self-service, métricas comerciais. O peso de Kong agora se justifica — você está cobrando por uso de API e o gateway é receita, não custo.

Empresa grande (centenas de serviços, integrações com parceiros sérios). Kong Enterprise ou Envoy Gateway, dependendo do contexto. Equipe dedicada cuidando do gateway. Política formal de versionamento, descontinuação, SLA por cliente.

A migração natural — reverse proxy → Traefik/Tyk → Kong — funciona porque cada degrau resolve dor real do degrau anterior. Pular degraus é caro: instalar Kong na fase de MVP é colocar um caminhão pra entregar uma pizza.

Os 4 erros caros mais comuns com gateway

Os tropeços que vemos em produção:

Instalar Kong com PostgreSQL no caminho crítico sem precisar. O modo sem-banco existe e é perfeito pra maioria dos casos. Configuração declarativa via arquivo, sem dependência externa, sem ponto extra de falha. Muitos times caem na configuração padrão com banco e descobrem isso só quando o banco fica indisponível e o gateway não consegue mais propagar mudanças. Se você precisa de gerenciamento dinâmico de chaves (consumidores se cadastrando self-service), banco compensa. Senão, modo sem-banco.

Não monitorar o gateway com a mesma severidade dos back-ends. Gateway na frente vira caixa-preta de fácil esquecimento. Latência cresce 5 ms, taxa de erro vai de 0,01% pra 0,5%, ninguém percebe até cliente reclamar. Métricas de gateway (latência por rota, taxa de erro 4xx/5xx, uso de memória, lag de propagação de configuração) merecem dashboard próprio e alertas, não só inclusão tímida no painel geral.

Plug-in customizado em Lua/JS rodando em produção. Kong permite plug-in customizado em Lua. Tyk em JavaScript. Tentação enorme pra resolver "só essa transformação" no gateway. Bug nesse plug-in derruba o gateway inteiro — bug que você criou, sem teste de carga, no caminho crítico de tudo. Se você precisa de transformação custom, faça em micro-serviço atrás do gateway. Plug-in customizado só com revisão séria, teste de carga, e plano de rollback automático.

Versão do gateway desatualizada. Kong, Envoy e Tyk recebem CVEs (vulnerabilidades de segurança) com regularidade. Gateway é exposto à internet — superfície de ataque relevante. Versão de 18 meses atrás é vulnerabilidade conhecida acumulando. Faça parte do ciclo de manutenção: atualizar o gateway é tão importante quanto atualizar o sistema operacional.

Cenários reais em que NÃO instalar gateway

Lista forte. Se você está em algum destes, evite o gateway dedicado mesmo que o tópico apareça no conselho:

• SaaS web com 5 endpoints, sem API externa pública. Cliente final é o navegador. Autenticação por sessão. Reverse proxy resolve o caminho de entrada inteiro. Adicionar gateway aqui é vaidade arquitetural.
• Time pequeno (1 a 3 desenvolvedores). Curva de aprendizado de Kong custa duas a quatro semanas de produtividade total do time. Em time de 3 pessoas, isso é trimestre de feature parado. A não ser que o gateway resolva dor concreta hoje, adia.
• Workload onde latência sub-10ms é requisito duro. Trading de baixa latência, leilão em tempo real, jogo multiplayer. Cada milissegundo conta. Gateway adiciona 1 a 3 ms — em workload sensível, é caro. Coloque a inteligência no aplicativo.
• Aplicação monolítica sem agregação. O monolito atende o front-end direto, sem composição entre serviços. Não há o que agregar. Gateway é solução procurando problema.
• Compliance que prefere superfície de ataque mínima. Cada componente exposto à internet é mais um item pra auditoria, mais um patch a aplicar, mais um log a guardar. Se a auditoria valoriza minimalismo, justifique cada componente — gateway que não cobre dor concreta é minus.

Perguntas frequentes

Kong sem banco é estável em 2026? Sim. O modo declarativo (db_less = on) é maduro, recomendado pelo próprio Kong pra grande parte dos casos, e elimina o PostgreSQL como dependência. Você perde gerenciamento dinâmico de chave via API admin (precisa fazer deploy de configuração nova), mas ganha simplicidade operacional enorme. Pra time pequeno, troca quase sempre vale.

Traefik faz tudo que Kong faz? Não. Traefik com middlewares cobre a maioria dos casos comuns — autenticação básica, limite por chave simples, transformação de cabeçalho, encaminhamento de autenticação. Não cobre catálogo de plug-ins de Kong, validação OpenAPI nativa, portal de desenvolvedor robusto, integrações comerciais prontas. Se a sua dor cabe em middleware de Traefik, fica em Traefik (mais leve, mais simples). Se você precisa de coisa do catálogo de Kong, Kong.

Posso ter dois gateways em série? Tecnicamente sim, na prática quase sempre é sintoma de organização confusa. Dois gateways = duas configurações pra manter, duas latências somadas, dois pontos de falha. O caso defensável é: roteador de borda fazendo TLS e roteamento básico, gateway dedicado atrás fazendo trabalho específico (validação de chave, agregação). Isso é diferente de "dois gateways completos em série" — é divisão de responsabilidade.

API gateway substitui malha de serviço? Não. Gateway cuida do tráfego norte-sul (cliente externo → seu sistema). Malha cuida do tráfego leste-oeste (serviço interno → serviço interno). Funções parecidas (autenticação, limite, observabilidade) mas escopo diferente. Pra startup média, gateway resolve a parte que importa; malha de serviço completa só vira investimento defensável em escala maior. Tratamos esse limite em service mesh: quando vale pra SaaS pequeno e médio.

Quanta latência Kong adiciona em chamada típica? Em hardware moderno, com configuração padrão e plug-ins leves (validação de chave + limite por chave): 1 a 2 milissegundos por requisição. Plug-ins pesados (validação OpenAPI completa em payload grande, transformação JSON complexa, log síncrono pra serviço externo) podem somar 3 a 10 ms. Meça antes e depois — não confie em número de blog post genérico.

Provedor de OAuth self-hosted — Keycloak ou Hydra? Keycloak é o padrão pra quem quer painel de administração robusto, federação com LDAP/SAML, gerenciamento de usuário completo. Pesa mais (1 GB de RAM mínimo, JVM). Hydra é minimalista, foca só em OAuth/OIDC, sem gerenciamento de usuário (você integra com seu sistema de usuários existente). Pra time pequeno que já tem sistema de usuário próprio, Hydra é mais adequado. Pra empresa que quer um lugar único pra identidade, Keycloak. Os dois falam protocolos padrão, então o gateway não diferencia entre eles.

Validação de esquema — OpenAPI ou JSON Schema? OpenAPI (anteriormente Swagger) é o padrão pra descrever API HTTP — engloba caminhos, métodos, requisição e resposta. Inclui JSON Schema pra descrever payloads. Kong, Tyk e validadores standalone falam OpenAPI direto. JSON Schema puro é mais portável (não amarrado a HTTP) mas exige mais cola. Use OpenAPI quando o gateway suportar; vale ter o esquema do contrato vivo, não desatualizado.

Posso fazer limite no aplicativo em vez de gateway? Pode. Bibliotecas como golang.org/x/time/rate ou Redis com INCR resolvem limite por usuário no nível da aplicação. A questão é onde o limite é mais barato: no gateway, antes do back-end ser tocado (economiza recursos do back-end, aplica antes do trabalho começar) ou no aplicativo, com regra de negócio mais perto do código (mais fácil de raciocinar, mais fácil de testar). Pra limite simples, aplicativo basta. Pra limite por plano comercial com múltiplos níveis e auditoria, gateway é o lugar certo.

Posso usar dois gateways diferentes em rotas distintas? Pode. Algumas empresas rodam Kong pra rotas "produto" (API pública vendida) e Traefik pra rotas "interno" (admin, ops, cron). A justificativa é que cada gateway resolve uma dor diferente, e ter um só forçaria comprometimento. Vale quando os perfis de uso de fato divergem. Não vale só pelo prazer de ter variedade — duas peças pra manter.

Fechamento — comece pelo mínimo, suba quando a dor for real

A cilada da categoria "API gateway" é tratar a decisão como binária — instalar ou não — quando ela é gradativa. Reverse proxy bem feito cobre 80% das aplicações. Roteador integrado no orquestrador cobre as mesmas 80% sem componente separado. Gateway dedicado é investimento defensável quando aparecem três ou quatro sinais simultâneos: API externa pública, limite por chave, agregação, portal de desenvolvedor.

A régua honesta: instale o mínimo até a dor concreta forçar o próximo degrau. Pular degraus custa caro em latência, RAM, complexidade, área de falha. Time pequeno que instala Kong "porque vai precisar" passa três semanas configurando algo que não usa, e ainda assim tem mais um componente pra monitorar.

HeroCtl entrega o degrau mais baixo embutido — roteador integrado com TLS automático, balanceamento, health check, limite por IP. Quando a dor de gateway aparecer pra valer, você sobe Kong, Traefik standalone, Tyk ou KrakenD como mais um job no cluster. Sem migração dolorosa, sem cerimônia.

Pra subir um cluster e testar:

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

Community é gratuito pra sempre, sem teto de servidores, sem teto de jobs, sem feature gate. Business adiciona SSO/SAML, RBAC granular, auditoria detalhada e suporte com SLA. Enterprise acrescenta escrow de código-fonte, contrato de continuidade e suporte 24×7.

Posts próximos: service mesh: quando vale pra SaaS pequeno e médio e multi-tenant SaaS: isolamento real entre clientes. Os três tópicos juntos cobrem a maior parte das decisões de plataforma pra startup brasileira na faixa de 1 a 500 servidores.

Orquestração de contêineres, sem cerimônia. Gateway só quando a dor pedir.