Ferramentas CLI Open Source Gratuitas para Gerenciamento de API

Gerenciamento de API costumava significar um console GUI e uma fatura de fornecedor. Isso ainda existe, mas grande parte do trabalho real agora acontece pelo terminal. Você define rotas, plugins e limites de taxa em um arquivo de configuração, o submete ao Git e permite que uma CLI o envie para o gateway. Sem cliques em um painel, sem divergência entre o que é implantado e o que é revisado.

O ângulo de código aberto importa aqui. Se você executa seu próprio gateway, a licença decide o que você pode auto-hospedar, ramificar (fork) e distribuir sem pagar por assento. A maioria das ferramentas abaixo são Apache 2.0 ou MPL 2.0, o que significa que o código-fonte está disponível, você pode executá-lo em qualquer lugar e não há custo por usuário embutido. Essa é uma lente diferente de escolher o menor binário; aqui as questões são licença, auto-hospedagem e quão ativo é o repositório do GitHub.

Esta é uma lista de gateways genuinamente de código aberto com uma verdadeira história de linha de comando: Kong Gateway OSS com decK, Tyk, KrakenD Community Edition, Apache APISIX e Gravitee. Para cada um você terá a licença, o que a CLI realmente faz e um comando real de instalação e execução que você pode colar. Se você quiser um campo mais amplo, o resumo das ferramentas de gerenciamento de API de código aberto cobre as plataformas; esta peça é o recorte terminal-first disso. O texto oficial da licença Apache 2.0 vale a pena dar uma lida se você nunca leu os termos em que você está confiando.

Uma nota honesta logo de cara. Apidog aparece no final, mas não como uma entrada de código aberto, porque não é. É um produto comercial com um nível gratuito. Explicarei onde ele se encaixa sem fingir que é algo que não é.

O que torna uma ferramenta CLI “código aberto” para gerenciamento de API

Três coisas separam uma opção de código aberto real de uma avaliação gratuita com contagem regressiva.

Licença. Procure por Apache 2.0, MIT ou MPL 2.0 no gateway principal, não apenas nos SDKs de cliente. Apache 2.0 permite que você auto-hospede e modifique livremente. MPL 2.0 (a escolha da Tyk) é copyleft em nível de arquivo; você pode combiná-lo com código proprietário, desde que os arquivos MPL permaneçam abertos. Qualquer coisa rotulada como “código-fonte disponível” ou BSL não é a mesma coisa, então leia o arquivo LICENSE real no repositório.

Auto-hospedagem. O gateway é executado em sua infraestrutura sem um servidor de licença "telefonando para casa". Você controla o plano de dados. Se a “edição comunitária” for tão limitada a ponto de ser uma demonstração, ela não conta.

Um repositório mantido e uma CLI funcional. Verifique as estrelas do GitHub, mas verifique mais o histórico de commits. Um gateway que você pode configurar declarativamente a partir da linha de comando, versionar no Git e executar em CI é o objetivo principal desta lista. Para os conceitos gerais de gerenciamento por trás de tudo isso, veja o que o gerenciamento de API realmente cobre.

Kong Gateway OSS (com decK)

Kong Gateway OSS é a compilação do Kong licenciada sob Apache 2.0. A Kong Inc. continua a distribuir compilações OSS para pessoas que desejam apenas código Apache 2.0, separadamente da edição Enterprise. O gateway em si é configurado através de sua API de Administração, mas a ferramenta em que você realmente vive é o decK.

decK é a CLI de configuração declarativa do Kong. Você despeja o estado do gateway em execução em um arquivo YAML, o edita e o sincroniza de volta. Ele faz um "diff" primeiro, então você vê exatamente o que mudará antes de mudar, o que torna a divergência de configuração visível em vez de silenciosa.

# Export the current Kong config to a file
deck gateway dump -o kong.yaml

# Push a declarative config back to the gateway
deck gateway sync kong.yaml

Melhor para: infraestrutura como código para Kong. Se você já executa o Kong e deseja suas rotas e plugins no Git com revisão e CI, decK é a resposta. Limites honestos: é específico do Kong e gerencia a configuração em vez de fazer documentos ou testes. Você também está executando a pilha completa do Kong, que é mais pesada do que um gateway de binário único.

Tyk

O gateway da Tyk é de código aberto sob a Licença Pública Mozilla 2.0. A MPL é copyleft em nível de arquivo: as alterações nos arquivos licenciados pela MPL devem permanecer abertas, mas você pode agrupar o gateway com plugins proprietários, desde que estes vivam em arquivos separados. O gateway principal, escrito em Go, suporta REST, GraphQL, TCP e gRPC.

A parte da linha de comando que a maioria das pessoas usa é o "bundler", incluído no binário do gateway desde a v2.8. Ele empacota seus plugins de middleware personalizados em um pacote assinado que o gateway pode carregar.

# Build a plugin bundle from your manifest and middleware files
tyk bundle build -o bundle.zip

Melhor para: equipes que desejam estender o gateway com autenticação personalizada ou plugins de transformação e precisam de uma maneira repetível de empacotá-los. Limites honestos: a CLI é restrita ao empacotamento, não à configuração declarativa completa de todo o gateway; grande parte do gerenciamento da Tyk ainda é feito por meio de seu Dashboard (que é a parte paga) ou diretamente pela API do Gateway.

KrakenD Community Edition

KrakenD é um gateway sem estado (stateless) e de alto desempenho, e a Community Edition entrega o conjunto completo de recursos principais sob a licença Apache 2.0. Sem estado é a parte interessante: não há banco de dados. O gateway é definido inteiramente por um arquivo de configuração, o que o torna um ajuste natural para Git e CI.

O binário krakend é a CLI. Você valida configurações com check e executa o gateway com run. Por ser um único binário Go, a instalação é um único download.

# Validate and lint your config before deploying
krakend check -c krakend.json --lint

# Run the gateway with that config
krakend run -c krakend.json

O recurso de Configuração Flexível (FC_ENABLE=1) permite dividir uma grande configuração em arquivos com variáveis, para que você possa manter os ambientes DRY. Melhor para: gateways declarativos e sem estado, onde o arquivo de configuração é a única fonte da verdade. Limites honestos: sem persistência integrada ou UI de administração na CE; você compõe o comportamento na configuração em vez de clicar em botões, o que é um recurso se você gosta de IaC e um atrito se não gosta.

Apache APISIX

Apache APISIX é um projeto de alto nível da Apache Software Foundation, licenciado sob Apache 2.0. Essa governança é importante para a questão do código aberto: é um projeto de fundação, não uma edição comunitária de um único fornecedor, então a compilação OSS é o projeto real, em vez de um "teaser" simplificado.

O APISIX possui uma CLI de controle para operações de ciclo de vida e uma API REST Admin (vinculada a 127.0.0.1 por padrão) para gerenciar rotas e plugins. A CLI inicia, para e recarrega o gateway; apisix reload detecta as mudanças de configuração sem derrubar as conexões.

# See the available control commands
apisix help

# Start the gateway, then hot-reload after a config change
apisix start
apisix reload

Melhor para: roteamento dinâmico e de alto throughput onde você deseja alterar rotas e plugins em tempo de execução sem reinícios, impulsionado pela API de Administração. Limites honestos: a configuração de roteamento reside na API de Administração, em vez de um único envio declarativo da CLI, então seu fluxo de trabalho de “configuração no Git” geralmente significa scriptar chamadas da API de Administração ou adicionar uma ferramenta como o ADC do APISIX por cima.

Gravitee

A plataforma principal de Gerenciamento de API da Gravitee é de código aberto sob a licença Apache 2.0. É mais do que um gateway: a Community Edition inclui o APIM Gateway (o tempo de execução), a APIM API (uma interface de gerenciamento REST) e o APIM Console. Recursos Enterprise, como as APIs assíncronas nativas de eventos, estão na edição paga, mas o núcleo centrado em REST é um OSS genuíno que você pode auto-hospedar.

A história da linha de comando precisa de um aviso honesto. A administração diária da Gravitee é feita por meio de sua API REST de Gerenciamento e Console, e a instalação oficial auto-hospedada é frequentemente impulsionada pela CLI do Docker. Existe um graviteeio-cli mantido pela comunidade no GitHub que envolve a API de Gerenciamento para automatizar ações entre módulos, mas é uma ferramenta da comunidade, não um binário de primeira parte, então trate seu status de manutenção da mesma forma que trataria qualquer projeto da comunidade antes de depender dele.

# Run the Gravitee APIM gateway container (self-hosted, OSS)
docker run --name gravitee-gateway -p 8082:8082 graviteeio/apim-gateway:latest

Melhor para: equipes que desejam uma camada completa de gerenciamento de código aberto (gateway mais console mais uma API de gerenciamento para script) em vez de apenas um proxy. Limites honestos: a superfície de automação de primeira parte é a API REST de Gerenciamento, não uma CLI única e polida; a CLI da comunidade preenche a lacuna, mas você assume o risco de sua manutenção.

Onde o Apidog se encaixa (e por que não está na lista de código aberto)

Apidog não é de código aberto, então não deve ser incluído como uma entrada acima. É um produto comercial com um nível gratuito, e eu estaria te enganando ao classificá-lo sob Apache 2.0.

Aqui está a proposta honesta, de qualquer forma. As ferramentas acima são gateways; elas gerenciam tráfego, rotas e plugins. Elas não projetam seu esquema de API, executam seus testes de endpoint, geram sua documentação ou simulam respostas antes que o backend exista. Unir esses trabalhos geralmente significa Spectral mais openapi-generator mais um servidor de mock mais Newman, cada um com sua própria configuração. Apidog integra design, teste, mocking e documentação em um único workspace, e o apidog-cli oferece um caminho via terminal para tudo isso.

# Install and authenticate the Apidog CLI
npm install -g apidog-cli
apidog login --with-token <TOKEN>

# Run a test scenario in CI (exits non-zero on failure)
apidog run

A CLI gera JSON estruturado com agentHints.nextSteps, o que permite sua fácil integração em CI e em fluxos de trabalho de agentes de IA; se você está roteando o trabalho da API através do Claude Code ou similar, gerenciar APIs sem sair dos seus agentes de IA aborda esse padrão. Também suporta importação e exportação de OpenAPI, execução de cenários e gerenciamento de mocks a partir da linha de comando. O guia completo da CLI do Apidog percorre os grupos de comandos. Pense nele como a opção integrada de nível gratuito ao lado de um gateway OSS auto-hospedado, não como um substituto.

Como escolher

Escolha com base no fluxo de trabalho, não na contagem de estrelas. Se você já usa o Kong, decK é a vitória mais rápida. Se você quer um gateway sem estado definido inteiramente por um arquivo, KrakenD se encaixa. APISIX se destaca em mudanças de roteamento dinâmicas em tempo de execução; Gravitee oferece uma camada de gerenciamento completa com um console. Para uma comparação mais ampla, incluindo as plataformas comerciais, veja as melhores ferramentas de gerenciamento de API para 2026 e o ângulo de gerenciamento de API headless se você está construindo uma stack API-first.

Conclusão

O gerenciamento de API de código aberto pela CLI está maduro. Kong Gateway OSS com decK, Tyk, KrakenD CE, Apache APISIX e Gravitee são todos Apache 2.0 ou MPL 2.0, todos auto-hospedáveis e todos controláveis pelo terminal, o que significa Git, revisão e CI em vez de cliques em painéis. Escolha aquele cujo modelo corresponde à forma como você implanta.

Para o design, teste, mocking e documentação que os gateways não tratam, uma ferramenta integrada preenche a lacuna. Baixe o Apidog e execute apidog run em seu pipeline para ver o caminho da CLI, então conecte-o ao CI ao lado do gateway OSS que você escolher.