Kostenlose Open Source CLI Tools für API Management

API-Management bedeutete früher meist: GUI-Konsole öffnen, Einstellungen klicken und anschließend eine Anbieterrechnung prüfen. Heute liegt ein großer Teil der Arbeit im Terminal: Sie definieren Routen, Plugins und Rate Limits in Konfigurationsdateien, versionieren sie in Git und übertragen sie per CLI an das Gateway. Das reduziert manuelle Schritte und macht Abweichungen zwischen überprüfter und bereitgestellter Konfiguration sichtbar.

Apidog noch heute testen

Der Open-Source-Aspekt ist dabei entscheidend. Wenn Sie ein Gateway selbst betreiben, bestimmt die Lizenz, was Sie hosten, forken und verteilen dürfen – ohne nutzerbasierte Gebühren. Die hier behandelten Gateways stehen überwiegend unter Apache 2.0 oder MPL 2.0. Entscheidend sind daher nicht nur Paketgröße oder Performance, sondern auch Lizenz, Self-Hosting-Fähigkeit, CLI-Workflow und Aktivität des Repositories.

Dieser Beitrag fokussiert auf Open-Source-Gateways mit terminalorientiertem Workflow: Kong Gateway OSS mit decK, Tyk, KrakenD Community Edition, Apache APISIX und Gravitee. Sie erhalten pro Tool die Lizenz, den praktischen CLI-Einsatz und Befehle für den Einstieg. Einen breiteren Überblick liefert der Beitrag zu Open-Source-API-Management-Tools. Prüfen Sie außerdem den offiziellen Lizenztext von Apache 2.0, bevor Sie eine Lizenzentscheidung treffen.

Apidog erscheint weiter unten als Ergänzung, aber ausdrücklich nicht als Open-Source-Option. Es ist ein kommerzielles Produkt mit kostenlosem Tarif.

Was macht ein CLI-Tool für API-Management wirklich Open Source?

Prüfen Sie drei Kriterien, bevor Sie ein Gateway in Ihren Stack aufnehmen.

1. Lizenz

Achten Sie auf die Lizenz des Kern-Gateways, nicht nur auf SDKs oder Hilfstools.

• Apache 2.0 erlaubt Self-Hosting, Nutzung und Modifikation.
• MPL 2.0 ist ein Copyleft auf Dateiebene: Änderungen an MPL-Dateien müssen offen bleiben, proprietärer Code kann jedoch in separaten Dateien kombiniert werden.
• „Source available“ oder BSL ist nicht dasselbe wie Open Source.

Praktischer Schritt: Prüfen Sie vor dem Einsatz die LICENSE-Datei im Repository und nicht nur die Produktseite.

2. Self-Hosting

Das Gateway sollte auf Ihrer Infrastruktur laufen, ohne dass für den Kernbetrieb ein Lizenzserver erforderlich ist. Sie kontrollieren damit Datenebene, Deployment und Upgrade-Prozess.

3. Gepflegtes Repository und nutzbares CLI

Sterne sind nur ein Signal. Prüfen Sie zusätzlich:

• aktuelle Commits und Releases,
• dokumentierte Installationswege,
• deklarative Konfiguration oder skriptbare APIs,
• CI-taugliche Befehle mit brauchbaren Exit-Codes.

Für die grundlegenden Konzepte dahinter siehe: Was API-Management tatsächlich umfasst.

Kong Gateway OSS mit decK

Kong Gateway OSS ist unter Apache 2.0 lizenziert. Das Gateway wird über die Admin API konfiguriert; für einen Git- und CI-basierten Workflow verwenden Sie typischerweise decK.

decK exportiert den Zustand eines laufenden Gateways in YAML, erzeugt vor Änderungen einen Diff und synchronisiert anschließend den gewünschten Zustand zurück.

# Aktuelle Kong-Konfiguration exportieren
deck gateway dump -o kong.yaml

# Konfiguration in Git bearbeiten, prüfen und dann synchronisieren
deck gateway sync kong.yaml

Praktischer Workflow

1. Exportieren Sie den aktuellen Zustand mit deck gateway dump.
2. Committen Sie kong.yaml in Ihr Repository.
3. Prüfen Sie Änderungen im Pull Request.
4. Führen Sie deck gateway sync in Ihrer Deployment-Pipeline aus.

Am besten geeignet für: Kong-Installationen, deren Routen und Plugins als Infrastructure as Code in Git verwaltet werden sollen.

Einschränkungen: decK ist Kong-spezifisch und verwaltet Gateway-Konfiguration – nicht API-Dokumentation oder Tests. Außerdem betreiben Sie den vollständigen Kong-Stack, der umfangreicher als ein Single-Binary-Gateway ist.

Tyk

Das Tyk Gateway steht unter der Mozilla Public License 2.0. Der Kern ist in Go geschrieben und unterstützt REST, GraphQL, TCP und gRPC.

Für die CLI-Arbeit ist vor allem der seit Version 2.8 in der Gateway-Binärdatei enthaltene Bundler relevant. Er verpackt benutzerdefinierte Middleware-Plugins als Bundle, das das Gateway laden kann.

# Plugin-Bundle aus Manifest- und Middleware-Dateien erzeugen
tyk bundle build -o bundle.zip

Praktischer Workflow

1. Implementieren Sie Middleware oder Plugins.
2. Definieren Sie Manifest und Bundle-Inhalte.
3. Erzeugen Sie das Bundle in CI.
4. Stellen Sie das erzeugte Artefakt zusammen mit der Gateway-Konfiguration bereit.

Am besten geeignet für: Teams mit benutzerdefinierten Authentifizierungs-, Transformations- oder Middleware-Anforderungen.

Einschränkungen: Das CLI konzentriert sich auf Plugin-Bundles, nicht auf die vollständige deklarative Verwaltung des Gateways. Viele Management-Aufgaben erfolgen über die Gateway API oder das Dashboard, das zum kostenpflichtigen Teil gehört.

KrakenD Community Edition

KrakenD Community Edition ist ein zustandsloses Gateway unter Apache 2.0. Der zentrale Unterschied zu vielen anderen Gateways: Es benötigt keine Datenbank. Die gesamte Gateway-Definition liegt in einer Konfigurationsdatei.

Das macht KrakenD besonders passend für Git, Pull Requests und CI.

# Konfiguration vor dem Deployment validieren und linten
krakend check -c krakend.json --lint

# Gateway mit der Konfiguration starten
krakend run -c krakend.json

Für größere Setups können Sie die flexible Konfiguration aktivieren. Mit FC_ENABLE=1 teilen Sie umfangreiche Konfigurationen in Vorlagen und Variablen auf.

FC_ENABLE=1 krakend check -c krakend.json --lint

Praktischer Workflow

1. Speichern Sie krakend.json im Repository.
2. Validieren Sie jede Änderung mit krakend check --lint.
3. Nutzen Sie Umgebungsvariablen und Vorlagen für umgebungsspezifische Werte.
4. Starten Sie das Gateway mit derselben geprüften Konfiguration.

Am besten geeignet für: Zustandslose, vollständig deklarative Gateways mit Konfiguration als einziger Quelle der Wahrheit.

Einschränkungen: Die Community Edition bietet keine eingebaute Persistenz oder Admin-UI. Verhalten wird in Konfiguration modelliert statt über ein Dashboard geschaltet.

Apache APISIX

Apache APISIX ist ein Top-Level-Projekt der Apache Software Foundation und steht unter Apache 2.0. Das ist für die Open-Source-Bewertung relevant: Der OSS-Build ist das eigentliche Projekt und keine reduzierte Community-Ausgabe eines proprietären Produkts.

APISIX kombiniert ein Control-CLI für Lifecycle-Aufgaben mit einer REST Admin API. Die Admin API ist standardmäßig an 127.0.0.1 gebunden und verwaltet unter anderem Routen und Plugins.

# Verfügbare CLI-Befehle anzeigen
apisix help

# Gateway starten
apisix start

# Konfigurationsänderungen ohne Verbindungsunterbrechung übernehmen
apisix reload

Praktischer Workflow

1. Starten Sie APISIX mit apisix start.
2. Verwalten Sie Routen und Plugins über die Admin API.
3. Automatisieren Sie API-Aufrufe per Skript oder CI-Job.
4. Übernehmen Sie Änderungen mit apisix reload, wenn nötig.

Am besten geeignet für: Dynamisches Routing mit hohem Durchsatz, bei dem Routen und Plugins zur Laufzeit geändert werden sollen.

Einschränkungen: Die Konfiguration liegt primär in der Admin API und nicht in einem einzelnen deklarativen CLI-Push. Für „Config in Git“ benötigen Sie daher Skripte für Admin-API-Aufrufe oder ein zusätzliches Tool wie APISIX ADC.

Gravitee

Gravitee stellt eine zentrale API-Management-Plattform unter Apache 2.0 bereit. Die Community Edition umfasst:

• APIM Gateway als Laufzeitumgebung,
• APIM API als REST-Management-Schnittstelle,
• APIM Console für die Verwaltung.

Funktionen wie ereignisnative asynchrone APIs gehören zur kostenpflichtigen Edition. Der REST-zentrierte Kern kann jedoch selbst gehostet werden.

Für die tägliche Verwaltung stehen die Management REST API und die Konsole im Mittelpunkt. Die Installation erfolgt häufig über Docker. Zusätzlich existiert mit graviteeio-cli ein Community-Tool, das die Management API für Automatisierung umschließt. Prüfen Sie dessen Wartungsstatus, bevor Sie es produktiv einsetzen.

# Gravitee APIM Gateway selbst gehostet starten
docker run --name gravitee-gateway -p 8082:8082 graviteeio/apim-gateway:latest

Praktischer Workflow

1. Starten Sie das Gateway als Container.
2. Konfigurieren Sie APIs und Policies über Management API oder Konsole.
3. Skripten Sie wiederkehrende Aufgaben über die REST API.
4. Bewerten Sie Community-CLIs wie jedes andere externe Automatisierungstool.

Am besten geeignet für: Teams, die neben dem Gateway eine vollständige Open-Source-Managementebene mit Konsole und Management API benötigen.

Einschränkungen: Die primäre Automatisierungsschnittstelle ist die REST Management API, nicht ein einzelnes umfassendes CLI. Das Community-CLI kann helfen, bringt aber eigenes Wartungsrisiko mit.

Wo Apidog passt – und warum es nicht auf der Open-Source-Liste steht

Apidog ist nicht Open Source und gehört deshalb nicht in die vorherige Liste. Es ist ein kommerzielles Produkt mit kostenlosem Tarif.

Die genannten Tools sind Gateways: Sie verwalten Traffic, Routen und Plugins. Sie sind nicht primär für API-Design, Endpunkt-Tests, Dokumentationsgenerierung oder Mocking vor der Backend-Implementierung gedacht.

Ohne integriertes Tool kombinieren Teams dafür häufig mehrere Werkzeuge, etwa Spectral, openapi-generator, einen Mock-Server und Newman. Apidog bündelt Design, Tests, Mocking und Dokumentation in einem Arbeitsbereich und bietet mit apidog-cli einen Terminalzugang.

# CLI installieren und authentifizieren
npm install -g apidog-cli
apidog login --with-token <TOKEN>

# Testszenario in CI ausführen
# Bei Fehlern wird ein Exit-Code ungleich 0 zurückgegeben.
apidog run

Das CLI gibt strukturiertes JSON mit agentHints.nextSteps aus und kann damit in CI- und KI-Agenten-Workflows eingebunden werden. Das Muster beschreibt der Beitrag APIs verwalten, ohne Ihre KI-Agenten zu verlassen.

Weitere CLI-Aufgaben umfassen OpenAPI-Import und -Export, das Ausführen von Szenarien und die Steuerung von Mocks. Details finden Sie im vollständigen Apidog CLI-Leitfaden.

Betrachten Sie Apidog als ergänzende Free-Tier-Option für Design, Tests, Mocking und Dokumentation – nicht als Ersatz für ein selbst gehostetes OSS-Gateway.

So wählen Sie aus

Tool	Am besten geeignet für	Lizenz	Open Source?	CLI/Befehl
Kong Gateway OSS + decK	IaC-Konfiguration für Kong in Git	Apache 2.0	Ja	deck gateway sync
Tyk	Bündelung benutzerdefinierter Plugins, Multi-Protokoll	MPL 2.0	Ja	tyk bundle build
KrakenD CE	Zustandsloses Gateway, Konfiguration als Code	Apache 2.0	Ja	krakend run
Apache APISIX	Dynamisches Routing mit hohem Durchsatz	Apache 2.0	Ja, ASF-Projekt	apisix start / apisix reload
Gravitee	Komplette OSS-Verwaltungsebene mit Konsole	Apache 2.0	Ja, Kern	Docker CLI / REST API
Apidog CLI	Design, Tests, Mocks und Dokumentation	Freemium	Nein	apidog run

Wählen Sie nach Workflow, nicht nach Sternenanzahl:

• Sie nutzen bereits Kong: Beginnen Sie mit decK und versionieren Sie Gateway-Zustände in Git.
• Sie wollen ein vollständig zustandsloses Gateway: Verwenden Sie KrakenD mit validierter Konfiguration im Repository.
• Sie benötigen dynamische Laufzeitänderungen: Nutzen Sie APISIX und automatisieren Sie die Admin API.
• Sie benötigen Gateway, Management API und Konsole: Prüfen Sie Gravitee.
• Sie brauchen Plugin-Bundles und Multi-Protokoll-Unterstützung: Prüfen Sie Tyk.
• Sie möchten Design, Tests, Mocks und Dokumentation ergänzen: Verwenden Sie Apidog neben Ihrem Gateway.

Für weitere Vergleiche siehe die besten API-Management-Tools für 2026 sowie den Ansatz des Headless API Management.

Zusammenfassung

Open-Source-API-Management per CLI ist ausgereift. Kong Gateway OSS mit decK, Tyk, KrakenD CE, Apache APISIX und Gravitee sind selbst hostbar, unter Apache 2.0 oder MPL 2.0 lizenziert und über Terminal oder API automatisierbar.

Der entscheidende nächste Schritt ist die Umsetzung in Ihrem Delivery-Workflow:

1. Konfiguration in Git ablegen.
2. Änderungen per Pull Request prüfen.
3. Konfiguration vor dem Deployment validieren.
4. Deployment und Synchronisierung in CI ausführen.
5. Gateway-Verhalten, API-Tests und Dokumentation getrennt, aber automatisiert behandeln.

Für Design, Tests, Mocking und Dokumentation neben dem Gateway können Sie Apidog herunterladen und apidog run in Ihrer Pipeline ausführen.