La gestión de API solía significar una consola GUI y una factura de proveedor. Eso todavía existe, pero gran parte del trabajo real ahora ocurre desde la terminal. Se definen rutas, plugins y límites de tasa en un archivo de configuración, se envía a Git y se permite que una CLI lo envíe a la pasarela. Sin clics a través de un panel de control, sin desviaciones entre lo que está implementado y lo que está revisado.
El ángulo de código abierto importa aquí. Si ejecuta su propia pasarela, la licencia decide lo que puede autoalojar, bifurcar y enviar sin pagar por asiento. La mayoría de las herramientas a continuación son Apache 2.0 o MPL 2.0, lo que significa que el código fuente está disponible, puede ejecutarlo en cualquier lugar y no hay un costo por usuario incorporado. Esa es una perspectiva diferente a elegir el binario más pequeño; aquí las preguntas son la licencia, el autoalojamiento y cuán activo está el repositorio de GitHub.
Esta es una lista de pasarelas genuinamente de código abierto con una verdadera historia de línea de comandos: Kong Gateway OSS con decK, Tyk, KrakenD Community Edition, Apache APISIX y Gravitee. Para cada una obtendrá la licencia, lo que realmente hace la CLI y un comando real de instalación y ejecución que puede pegar. Si desea el campo más amplio, el resumen de herramientas de gestión de API de código abierto cubre las plataformas; esta pieza es la versión con prioridad de terminal. El texto oficial de la licencia Apache 2.0 vale la pena echarle un vistazo si nunca ha leído los términos en los que se basa.
Una nota honesta de antemano. Apidog aparece al final, pero no como una entrada de código abierto, porque no lo es. Es un producto comercial con un nivel gratuito. Explicaré dónde encaja sin pretender que sea algo que no es.
¿Qué hace que una herramienta CLI sea “de código abierto” para la gestión de API?
Tres cosas separan una opción real de código abierto de una prueba gratuita con una cuenta regresiva.
Licencia. Busque Apache 2.0, MIT o MPL 2.0 en la pasarela principal, no solo en los SDK del cliente. Apache 2.0 le permite autoalojar y modificar libremente. MPL 2.0 (la elección de Tyk) es copyleft a nivel de archivo; puede combinarlo con código propietario siempre que los archivos MPL permanezcan abiertos. Cualquier cosa etiquetada como “código fuente disponible” o BSL no es lo mismo, así que lea el archivo LICENSE real en el repositorio.
Autoalojamiento. La pasarela se ejecuta en su infraestructura sin que un servidor de licencias se comunique a casa. Usted controla el plano de datos. Si la “edición comunitaria” está limitada hasta el punto de ser una demostración, no cuenta.
Un repositorio mantenido y una CLI que funcione. Revise las estrellas de GitHub, pero revise más el historial de commits. Una pasarela que puede configurar declarativamente desde la línea de comandos, versionar en Git y ejecutar en CI es el objetivo principal de esta lista. Para los conceptos generales de gestión detrás de todo esto, consulte lo que realmente cubre la gestión de API.
Kong Gateway OSS (con decK)
Kong Gateway OSS es la compilación de Kong con licencia Apache 2.0. Kong Inc. sigue distribuyendo compilaciones OSS para personas que solo quieren código Apache 2.0, separado de la edición Enterprise. La pasarela en sí se configura a través de su API de administración, pero la herramienta en la que realmente se trabaja es decK.
decK es la CLI de configuración declarativa de Kong. Vuelca el estado de la pasarela en ejecución a un archivo YAML, lo edita y lo sincroniza de nuevo. Primero hace un diff, para que vea exactamente qué cambiará antes de que cambie, lo que hace que la desviación de la configuración sea visible en lugar 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
Ideal para: infraestructura como código para Kong. Si ya ejecuta Kong y desea sus rutas y plugins en Git con revisión y CI, decK es la respuesta. Límites honestos: es específico de Kong y gestiona la configuración en lugar de hacer documentación o pruebas. También está ejecutando la pila completa de Kong, que es más pesada que una pasarela de un solo binario.
Tyk
La pasarela de Tyk es de código abierto bajo la Licencia Pública de Mozilla 2.0. La MPL es copyleft a nivel de archivo: los cambios en los archivos con licencia MPL deben permanecer abiertos, pero puede agrupar la pasarela con plugins propietarios siempre que esos residan en archivos separados. La pasarela principal, escrita en Go, soporta REST, GraphQL, TCP y gRPC.
La pieza de línea de comandos que la mayoría de la gente usa es el empaquetador (bundler), incluido en el binario de la pasarela desde la versión 2.8. Empaqueta sus plugins de middleware personalizados en un paquete firmado que la pasarela puede cargar.
# Build a plugin bundle from your manifest and middleware files
tyk bundle build -o bundle.zip
Ideal para: equipos que desean extender la pasarela con autenticación personalizada o plugins de transformación y necesitan una forma repetible de empaquetarlos. Límites honestos: la CLI está limitada al empaquetamiento, no a una configuración declarativa completa de toda la pasarela; gran parte de la gestión de Tyk aún se realiza a través de su Panel de Control (que es la parte de pago) o directamente a través de la API de la pasarela.
KrakenD Community Edition
KrakenD es una pasarela sin estado y de alto rendimiento, y la Community Edition ofrece el conjunto completo de características principales bajo Apache 2.0. Sin estado es la parte interesante: no hay base de datos. La pasarela se define completamente por un archivo de configuración, lo que la hace ideal para Git y CI.
El binario krakend es la CLI. Se validan las configuraciones con check y se ejecuta la pasarela con run. Como es un único binario Go, la instalación es una sola descarga.
# Validate and lint your config before deploying
krakend check -c krakend.json --lint
# Run the gateway with that config
krakend run -c krakend.json
La función de Configuración Flexible (FC_ENABLE=1) permite dividir una configuración grande en archivos con plantillas y variables, para mantener los entornos DRY. Ideal para: pasarelas declarativas y sin estado donde el archivo de configuración es la única fuente de verdad. Límites honestos: no hay persistencia integrada ni interfaz de usuario de administración en la CE; se compone el comportamiento en la configuración en lugar de hacer clic en interruptores, lo cual es una característica si le gusta IaC y una fricción si no.
Apache APISIX
Apache APISIX es un proyecto de alto nivel de la Apache Software Foundation, con licencia Apache 2.0. Esa gobernanza es importante para la cuestión del código abierto: es un proyecto de una fundación, no la edición comunitaria de un único proveedor, por lo que la compilación OSS es el proyecto real en lugar de un adelanto reducido.
APISIX tiene una CLI de control para operaciones de ciclo de vida y una API de administración REST (vinculada a 127.0.0.1 por defecto) para gestionar rutas y plugins. La CLI inicia, detiene y recarga la pasarela; apisix reload recoge los cambios de configuración sin interrumpir las conexiones.
# See the available control commands
apisix help
# Start the gateway, then hot-reload after a config change
apisix start
apisix reload
Ideal para: enrutamiento dinámico de alto rendimiento donde se desean cambiar rutas y plugins en tiempo de ejecución sin reinicios, impulsado por la API de administración. Límites honestos: la configuración de enrutamiento reside en la API de administración en lugar de una única operación declarativa de la CLI, por lo que su flujo de trabajo de "configuración en Git" generalmente significa escribir scripts de llamadas a la API de administración o agregar una herramienta como ADC de APISIX encima.
Gravitee
La plataforma principal de gestión de API de Gravitee es de código abierto bajo Apache 2.0. Es más que una pasarela: la Community Edition incluye la pasarela APIM (el tiempo de ejecución), la API APIM (una interfaz de gestión REST) y la Consola APIM. Las características empresariales, como las API asíncronas nativas de eventos, se encuentran en la edición de pago, pero el núcleo centrado en REST es un OSS genuino que puede autoalojar.
La historia de la línea de comandos necesita una advertencia honesta. La administración diaria de Gravitee se realiza a través de su API REST de gestión y su Consola, y la instalación oficial autoalojada a menudo se realiza con la CLI de Docker. Existe una graviteeio-cli mantenida por la comunidad en GitHub que envuelve la API de gestión para automatizar acciones en los módulos, pero es una herramienta de la comunidad, no un binario de primera parte, así que trate su estado de mantenimiento como trataría cualquier proyecto comunitario antes de depender de él.
# Run the Gravitee APIM gateway container (self-hosted, OSS)
docker run --name gravitee-gateway -p 8082:8082 graviteeio/apim-gateway:latest
Ideal para: equipos que desean una capa completa de gestión de código abierto (pasarela más consola más una API de gestión para scriptar) en lugar de solo un proxy. Límites honestos: la superficie de automatización de primera parte es la API REST de gestión, no una CLI pulida; la CLI de la comunidad llena el vacío, pero asume su riesgo de mantenimiento.
Dónde encaja Apidog (y por qué no está en la lista de código abierto)
Apidog no es de código abierto, por lo que no debe figurar como una entrada anterior. Es un producto comercial con un nivel gratuito, y estaría engañándole si lo incluyera bajo Apache 2.0.
Aquí está la presentación honesta de todos modos. Las herramientas anteriores son pasarelas; gestionan el tráfico, las rutas y los plugins. No diseñan su esquema de API, no ejecutan sus pruebas de endpoint, no generan su documentación ni simulan respuestas antes de que exista el backend. Unir esos trabajos generalmente significa Spectral más openapi-generator más un servidor de simulación más Newman, cada uno con su propia configuración. Apidog integra el diseño, las pruebas, la simulación y la documentación en un solo espacio de trabajo, y apidog-cli le brinda una ruta de terminal para todo ello.
# 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
La CLI genera JSON estructurado con agentHints.nextSteps, por lo que se integra limpiamente en CI y en flujos de trabajo de agentes de IA; si está dirigiendo el trabajo de API a través de Claude Code o similar, gestionar APIs sin salir de sus agentes de IA cubre ese patrón. También soporta la importación y exportación de OpenAPI, la ejecución de escenarios y la gestión de simulaciones desde la línea de comandos. La guía completa de la CLI de Apidog recorre los grupos de comandos. Piénselo como la opción integrada de nivel gratuito junto a una pasarela OSS autoalojada, no como un reemplazo de una.
Cómo elegir
| Herramienta | Ideal para | Licencia | ¿Código abierto? | CLI/comando |
|---|---|---|---|---|
| Kong Gateway OSS + decK | Configuración IaC para Kong en Git | Apache 2.0 | Sí | deck gateway sync |
| Tyk | Agrupación de plugins personalizados, multiprotocolo | MPL 2.0 | Sí | tyk bundle build |
| KrakenD CE | Pasarela sin estado, configuración como código | Apache 2.0 | Sí | krakend run |
| Apache APISIX | Enrutamiento dinámico de alto rendimiento | Apache 2.0 | Sí (proyecto ASF) | apisix start/reload |
| Gravitee | Capa de gestión OSS completa + consola | Apache 2.0 | Sí (núcleo) | Docker CLI / REST API |
| Apidog CLI | Diseño + prueba + simulación + documentación en uno | Freemium | No | apidog run |
Elija en función del flujo de trabajo, no del número de estrellas. Si ya utiliza Kong, decK es la victoria más rápida. Si desea una pasarela sin estado definida completamente por un archivo, KrakenD encaja. APISIX destaca en cambios de enrutamiento dinámicos en tiempo de ejecución; Gravitee le ofrece una capa de gestión completa con una consola. Para una comparación más amplia que incluya las plataformas comerciales, consulte las mejores herramientas de gestión de API para 2026 y el enfoque de gestión de API sin cabeza si está construyendo una pila API-first.
Conclusión
La gestión de API de código abierto desde la CLI está madura. Kong Gateway OSS con decK, Tyk, KrakenD CE, Apache APISIX y Gravitee son todos Apache 2.0 o MPL 2.0, todos autoalojables y todos controlables desde la terminal, lo que significa Git, revisión y CI en lugar de hacer clic en un panel de control. Elija el que su modelo se ajuste a cómo implementa.
Para el diseño, pruebas, simulaciones y documentación que las pasarelas no manejan, una herramienta integrada cubre la brecha. Descargue Apidog y ejecute apidog run en su pipeline para ver la ruta de la CLI, luego intégralo en CI junto con la pasarela OSS que elija.