Ferramentas CLI Open Source Gratuitas para Gerenciamento de API

Gerenciamento de API costumava significar um console gráfico 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 arquivos de configuração, versiona tudo no Git e deixa uma CLI aplicar as mudanças no gateway. O resultado é menos cliques, mais revisão de código e menos divergência entre o que foi aprovado e o que foi implantado.

Experimente o Apidog hoje

O ângulo de código aberto importa. Ao executar seu próprio gateway, a licença determina o que você pode auto-hospedar, modificar, distribuir e integrar sem custo por assento. As ferramentas abaixo usam principalmente Apache 2.0 ou MPL 2.0, permitindo executar o código na sua infraestrutura e automatizar a operação com Git e CI.

Esta lista foca em gateways realmente open source com uma história prática de linha de comando: Kong Gateway OSS com decK, Tyk, KrakenD Community Edition, Apache APISIX e Gravitee. Para uma visão mais ampla das plataformas, consulte as ferramentas de gerenciamento de API de código aberto. Também vale revisar o texto oficial da licença Apache 2.0.

Nota: o Apidog aparece ao final, mas não como uma opção open source. É um produto comercial com nível gratuito, útil para complementar gateways auto-hospedados.

O que torna uma ferramenta CLI realmente open source para gerenciamento de API

Antes de escolher um gateway, valide três pontos.

1. Licença do gateway principal

Procure licenças como Apache 2.0, MIT ou MPL 2.0 no repositório principal do gateway — não apenas em SDKs ou componentes auxiliares.

• Apache 2.0: permite uso, modificação e distribuição, inclusive em ambientes comerciais.
• MPL 2.0: copyleft em nível de arquivo. Alterações em arquivos MPL devem continuar abertas, mas você pode combinar o projeto com código proprietário em arquivos separados.
• Source-available ou BSL: não são equivalentes a open source. Leia o arquivo LICENSE do repositório antes de padronizar uma ferramenta.

2. Auto-hospedagem sem dependência de licença

O gateway deve executar na sua infraestrutura sem exigir que o plano de dados dependa de um serviço externo ou servidor de licença. Uma edição comunitária excessivamente limitada, usada apenas como demonstração, não atende a esse objetivo.

3. Repositório ativo e automação viável

Estrelas no GitHub ajudam, mas histórico de commits, issues e releases importam mais. Para um fluxo terminal-first, você precisa conseguir:

1. Declarar ou automatizar configurações.
2. Versionar essas configurações no Git.
3. Validar alterações antes do deploy.
4. Executar o processo no CI.

Para o contexto geral por trás dessas práticas, veja o que o gerenciamento de API realmente cobre.

Kong Gateway OSS com decK

O Kong Gateway OSS é distribuído sob a licença Apache 2.0. O gateway é administrado pela API de Administração, mas, para fluxos baseados em Git, a ferramenta central é o decK.

O decK transforma o estado do Kong em configuração declarativa. O fluxo básico é:

1. Exportar o estado atual do gateway.
2. Versionar o YAML no Git.
3. Revisar a alteração em pull request.
4. Sincronizar a configuração no ambiente alvo.

# Exporta a configuração atual do Kong
deck gateway dump -o kong.yaml

# Mostra as mudanças antes de aplicá-las
deck gateway diff kong.yaml

# Sincroniza a configuração declarativa com o gateway
deck gateway sync kong.yaml

Exemplo mínimo de um arquivo declarativo:

_format_version: "3.0"

services:
  - name: users-service
    url: http://users-api:8080
    routes:
      - name: users-route
        paths:
          - /users

Melhor para: infraestrutura como código em ambientes que já usam Kong.

Limites: o decK é específico do Kong e gerencia configuração, não design de APIs, documentação ou testes. Além disso, a pilha do Kong tende a ser mais pesada do que gateways de binário único.

Tyk

O gateway da Tyk é open source sob a Mozilla Public License 2.0. O núcleo, escrito em Go, suporta REST, GraphQL, TCP e gRPC.

A CLI mais usada no gateway é o bundler, incluído no binário desde a versão 2.8. Ele empacota plugins de middleware personalizados em um bundle que o gateway pode carregar.

# Cria um bundle a partir do manifesto e dos arquivos de middleware
tyk bundle build -o bundle.zip

Um fluxo prático para plugins é:

1. Criar o middleware customizado.
2. Declarar os arquivos no manifesto do bundle.
3. Gerar o ZIP com tyk bundle build.
4. Publicar o bundle no local esperado pelo gateway.
5. Associar o plugin à API pela configuração ou API do Gateway.

Melhor para: equipes que precisam de autenticação, transformação ou middleware customizado, com um processo repetível de empacotamento.

Limites: a CLI é focada em bundles, não em uma configuração declarativa completa do gateway. Grande parte da administração é feita pelo Dashboard pago ou diretamente pela API do Gateway.

KrakenD Community Edition

KrakenD Community Edition é um gateway de alto desempenho e sem estado, licenciado sob Apache 2.0. A ausência de estado é uma característica importante: não há banco de dados interno para persistir rotas ou políticas.

A configuração é a fonte de verdade. Isso simplifica o uso com Git, revisão de código e CI.

# Valida e aplica lint à configuração
krakend check -c krakend.json --lint

# Executa o gateway usando a configuração validada
krakend run -c krakend.json

Exemplo simplificado de krakend.json:

{
  "version": 3,
  "name": "api-gateway",
  "port": 8080,
  "endpoints": [
    {
      "endpoint": "/users",
      "method": "GET",
      "backend": [
        {
          "url_pattern": "/users",
          "host": ["http://users-api:8080"]
        }
      ]
    }
  ]
}

Para projetos maiores, habilite a Configuração Flexível:

FC_ENABLE=1 krakend check -c krakend.json

Isso permite dividir configurações em múltiplos arquivos e usar variáveis por ambiente, evitando duplicação entre desenvolvimento, homologação e produção.

Melhor para: gateways declarativos e stateless, onde arquivos de configuração são a única fonte da verdade.

Limites: a Community Edition não inclui persistência integrada ou uma UI administrativa. Você compõe o comportamento na configuração, o que favorece IaC, mas pode exigir mais trabalho inicial.

Apache APISIX

Apache APISIX é um projeto de alto nível da Apache Software Foundation, licenciado sob Apache 2.0. Isso significa que a versão OSS é o projeto principal, e não uma edição comunitária reduzida de um fornecedor.

O APISIX combina:

• CLI para operações de ciclo de vida;
• API REST Admin para rotas, consumidores e plugins;
• recarga de configuração sem derrubar conexões.

# Lista os comandos de controle disponíveis
apisix help

# Inicia o gateway
apisix start

# Recarrega a configuração sem interromper conexões
apisix reload

Um fluxo de automação comum é aplicar rotas pela API Admin em scripts de CI:

curl http://127.0.0.1:9180/apisix/admin/routes/1 \
  -H "X-API-KEY: $APISIX_ADMIN_KEY" \
  -X PUT \
  -d '{
    "uri": "/users",
    "upstream": {
      "type": "roundrobin",
      "nodes": {
        "users-api:8080": 1
      }
    }
  }'

Melhor para: roteamento dinâmico, alto throughput e alterações em tempo de execução via API de Administração.

Limites: as rotas normalmente vivem na API Admin, não em um único arquivo declarativo aplicado por CLI. Para um fluxo GitOps, você precisa versionar e executar scripts de API ou adicionar uma ferramenta como o ADC do APISIX.

Gravitee

A plataforma principal de gerenciamento de APIs da Gravitee é open source sob Apache 2.0. A Community Edition inclui:

• APIM Gateway;
• APIM API;
• APIM Console.

A plataforma vai além de um proxy: ela fornece gateway, console e API de gerenciamento para operações e automação. Recursos Enterprise, como APIs assíncronas nativas de eventos, ficam na edição paga, mas o núcleo REST pode ser auto-hospedado.

Para iniciar o gateway com Docker:

docker run --name gravitee-gateway \
  -p 8082:8082 \
  graviteeio/apim-gateway:latest

A automação diária é feita principalmente pela API REST de Gerenciamento e pelo Console. Existe também o graviteeio-cli, mantido pela comunidade, que encapsula chamadas à API para automatizar ações entre módulos.

Antes de adotá-lo em produção:

1. Verifique a atividade recente do repositório.
2. Fixe uma versão no pipeline.
3. Teste comandos em ambiente isolado.
4. Mantenha uma alternativa baseada diretamente na API REST.

Melhor para: equipes que desejam uma camada completa de gerenciamento open source — gateway, console e API de gerenciamento.

Limites: a interface de automação oficial é a API REST, não uma CLI única e completa. A CLI da comunidade pode ajudar, mas adiciona risco de manutenção.

Onde o Apidog se encaixa

O Apidog não é open source e não deve ser classificado como uma alternativa Apache 2.0 ou MPL 2.0. É um produto comercial com nível gratuito.

Ainda assim, ele resolve uma parte diferente do fluxo. Os gateways desta lista administram tráfego, roteamento, autenticação e plugins. Eles não substituem ferramentas para:

• projetar contratos de API;
• testar endpoints;
• criar mocks antes de o backend existir;
• gerar documentação;
• executar cenários de API em CI.

Você pode montar essa stack com ferramentas separadas, como Spectral, openapi-generator, um servidor de mock e Newman. O Apidog reúne design, testes, mocking e documentação em um workspace, com acesso via apidog-cli.

# Instala a CLI
npm install -g apidog-cli

# Autentica com token
apidog login --with-token <TOKEN>

# Executa um cenário de testes no CI
# O comando retorna código diferente de zero em caso de falha
apidog run

A CLI produz JSON estruturado com agentHints.nextSteps, facilitando a integração com CI e fluxos de agentes de IA. Para esse padrão, veja como gerenciar APIs sem sair dos seus agentes de IA.

Ela também suporta importação e exportação de OpenAPI, execução de cenários e gerenciamento de mocks pela linha de comando. O guia completo da CLI do Apidog detalha os grupos de comandos.

Use-o como complemento de um gateway OSS auto-hospedado, não como substituto.

Como escolher

Ferramenta	Melhor para	Licença	Código aberto?	CLI/comando
Kong Gateway OSS + decK	Configuração IaC para Kong no Git	Apache 2.0	Sim	deck gateway sync
Tyk	Empacotamento de plugins customizados e multiprotocolo	MPL 2.0	Sim	tyk bundle build
KrakenD CE	Gateway stateless e config-as-code	Apache 2.0	Sim	krakend run
Apache APISIX	Roteamento dinâmico de alto throughput	Apache 2.0	Sim, projeto ASF	apisix start / apisix reload
Gravitee	Camada completa de gerenciamento OSS com console	Apache 2.0	Sim, no núcleo	Docker CLI / REST API
Apidog CLI	Design, testes, mocks e documentação	Freemium	Não	apidog run

Escolha pelo fluxo de trabalho:

• Já usa Kong: adote decK para levar configuração ao Git rapidamente.
• Quer um único arquivo como fonte da verdade: use KrakenD.
• Precisa alterar rotas e plugins em runtime: avalie APISIX.
• Quer gateway, console e API de gerenciamento: considere Gravitee.
• Precisa cobrir design, testes, mocks e documentação: complemente o gateway com Apidog.

Para uma comparação mais ampla, incluindo plataformas comerciais, veja as melhores ferramentas de gerenciamento de API para 2026. Se você está montando uma stack API-first, confira também o conceito de gerenciamento de API headless.

Conclusão

O gerenciamento de API open source via CLI está maduro. Kong Gateway OSS com decK, Tyk, KrakenD CE, Apache APISIX e Gravitee permitem automatizar operações com Git, revisão de código e CI, reduzindo dependência de alterações manuais em painéis.

A decisão depende do modelo operacional:

• configuração declarativa para Kong;
• gateway stateless baseado em arquivos;
• rotas dinâmicas via API;
• ou uma plataforma completa com console.

Para cobrir design, teste, mocking e documentação — áreas que gateways normalmente não resolvem — use uma ferramenta complementar. Baixe o Apidog, execute apidog run no pipeline e conecte-o ao CI ao lado do gateway OSS escolhido.