Kostenlose Open Source CLI Tools für API Management

API-Management bedeutete früher eine GUI-Konsole und eine Anbieterrechnung. Das gibt es immer noch, aber ein Großteil der eigentlichen Arbeit findet heute im Terminal statt. Sie definieren Routen, Plugins und Ratenbegrenzungen in einer Konfigurationsdatei, committen diese zu Git und lassen sie über ein CLI an das Gateway übertragen. Kein Klicken durch ein Dashboard, keine Abweichung zwischen dem, was bereitgestellt und was überprüft wurde.

Der Open-Source-Aspekt ist hier wichtig. Wenn Sie Ihr eigenes Gateway betreiben, entscheidet die Lizenz, was Sie selbst hosten, forken und ausliefern können, ohne pro Benutzer zu zahlen. Die meisten der unten aufgeführten Tools sind unter Apache 2.0 oder MPL 2.0 lizenziert, was bedeutet, dass der Quellcode verfügbar ist, Sie ihn überall ausführen können und keine Pro-Benutzer-Kosten enthalten sind. Das ist eine andere Perspektive als die Auswahl des kleinsten Binärpakets; hier sind die Fragen Lizenz, Selbsthosting und wie aktiv das GitHub-Repository ist.

Dies ist eine Liste wirklich quelloffener Gateways mit einer echten Kommandozeilen-Geschichte: Kong Gateway OSS mit decK, Tyk, KrakenD Community Edition, Apache APISIX und Gravitee. Für jedes erhalten Sie die Lizenz, was das CLI tatsächlich tut, und einen echten Installations- und Ausführungsbefehl, den Sie einfügen können. Wenn Sie das breitere Feld wünschen, deckt der Überblick über Open-Source-API-Management-Tools die Plattformen ab; dieser Beitrag ist der "Terminal-First"-Ausschnitt davon. Der offizielle Lizenztext von Apache 2.0 ist einen Blick wert, wenn Sie die Bedingungen, auf die Sie sich verlassen, noch nie gelesen haben.

Eine ehrliche Anmerkung vorab. Apidog erscheint am Ende, aber nicht als Open-Source-Eintrag, denn das ist es nicht. Es ist ein kommerzielles Produkt mit einem kostenlosen Tarif. Ich werde erklären, wo es passt, ohne vorzugeben, dass es etwas ist, was es nicht ist.

Was macht ein CLI-Tool für das API-Management „Open Source“?

Drei Dinge unterscheiden eine echte Open-Source-Option von einer kostenlosen Testversion mit Countdown.

Lizenz. Achten Sie auf Apache 2.0, MIT oder MPL 2.0 auf dem Kern-Gateway, nicht nur auf den Client-SDKs. Apache 2.0 ermöglicht Ihnen das freie Selbsthosting und Modifizieren. MPL 2.0 (Tyks Wahl) ist ein Dateiebenen-Copyleft; Sie können es mit proprietärem Code kombinieren, solange die MPL-Dateien offen bleiben. Alles, was als „Quellcode verfügbar“ (source-available) oder BSL gekennzeichnet ist, ist nicht dasselbe, lesen Sie also die tatsächliche LICENSE-Datei im Repository.

Selbsthosting. Das Gateway läuft auf Ihrer Infrastruktur, ohne dass ein Lizenzserver nach Hause telefoniert. Sie kontrollieren die Datenebene. Wenn die „Community Edition“ so stark eingeschränkt ist, dass sie nur noch eine Demo darstellt, zählt sie nicht.

Ein gepflegtes Repository und ein funktionierendes CLI. Überprüfen Sie die GitHub-Sterne, aber noch wichtiger ist die Commit-Historie. Ein Gateway, das Sie deklarativ über die Kommandozeile konfigurieren, in Git versionieren und in CI ausführen können, ist der Kern dieser Liste. Für die allgemeinen Managementkonzepte, die dahinter stecken, siehe was API-Management tatsächlich umfasst.

Kong Gateway OSS (mit decK)

Kong Gateway OSS ist der unter Apache 2.0 lizenzierte Build von Kong. Kong Inc. liefert weiterhin OSS-Builds für Personen, die ausschließlich Apache 2.0-Code wünschen, getrennt von der Enterprise Edition. Das Gateway selbst wird über seine Admin-API konfiguriert, aber das Tool, mit dem Sie tatsächlich arbeiten, ist decK.

decK ist Kongs deklaratives Konfigurations-CLI. Sie speichern den Zustand des laufenden Gateways in einer YAML-Datei, bearbeiten sie und synchronisieren sie zurück. Es führt zuerst einen Diff durch, sodass Sie genau sehen, was sich ändern wird, bevor es sich ändert, wodurch Konfigurationsabweichungen sichtbar statt still bleiben.

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

# Deklarative Konfiguration zurück an das Gateway pushen
deck gateway sync kong.yaml

Am besten geeignet für: Infrastructure-as-Code für Kong. Wenn Sie bereits Kong betreiben und Ihre Routen und Plugins in Git mit Überprüfung und CI verwalten möchten, ist decK die Antwort. Ehrliche Einschränkungen: Es ist Kong-spezifisch und verwaltet die Konfiguration, anstatt Dokumentation oder Tests durchzuführen. Sie betreiben auch den gesamten Kong-Stack, der schwerfälliger ist als ein Single-Binary-Gateway.

Tyk

Tyks Gateway ist Open Source unter der Mozilla Public License 2.0. Die MPL ist ein Dateiebenen-Copyleft: Änderungen an MPL-lizenzierten Dateien müssen offen bleiben, aber Sie können das Gateway mit proprietären Plugins bündeln, solange diese in separaten Dateien liegen. Das Kern-Gateway, in Go geschrieben, unterstützt REST, GraphQL, TCP und gRPC.

Das Kommandozeilen-Tool, das die meisten Leute nutzen, ist der Bundler, der seit v2.8 in der Gateway-Binärdatei enthalten ist. Er verpackt Ihre benutzerdefinierten Middleware-Plugins in ein signiertes Bundle, das das Gateway laden kann.

# Ein Plugin-Bundle aus Ihren Manifest- und Middleware-Dateien erstellen
tyk bundle build -o bundle.zip

Am besten geeignet für: Teams, die das Gateway mit benutzerdefinierten Authentifizierungs- oder Transformations-Plugins erweitern möchten und eine wiederholbare Methode zum Verpacken benötigen. Ehrliche Einschränkungen: Das CLI ist auf das Bündeln beschränkt, nicht auf die vollständige deklarative Konfiguration des gesamten Gateways; ein Großteil des Tyk-Managements läuft immer noch über sein Dashboard (welches der kostenpflichtige Teil ist) oder direkt über die Gateway-API.

KrakenD Community Edition

KrakenD ist ein zustandsloses, hochleistungsfähiges Gateway, und die Community Edition liefert den vollen Kernfunktionsumfang unter Apache 2.0. Zustandslos ist der interessante Teil: Es gibt keine Datenbank. Das Gateway wird vollständig durch eine Konfigurationsdatei definiert, was es zu einer natürlichen Wahl für Git und CI macht.

Die krakend-Binärdatei ist das CLI. Sie validieren Konfigurationen mit check und führen das Gateway mit run aus. Da es sich um ein einzelnes Go-Binärprogramm handelt, besteht die Installation aus einem einzigen Download.

# Konfiguration vor der Bereitstellung validieren und linten
krakend check -c krakend.json --lint

# Das Gateway mit dieser Konfiguration ausführen
krakend run -c krakend.json

Die Funktion für flexible Konfiguration (FC_ENABLE=1) ermöglicht es Ihnen, eine große Konfiguration in Vorlagen-Dateien mit Variablen aufzuteilen, damit Sie Umgebungen DRY halten können. Am besten geeignet für: deklarative, zustandslose Gateways, bei denen die Konfigurationsdatei die einzige Quelle der Wahrheit ist. Ehrliche Einschränkungen: keine eingebaute Persistenz oder Admin-UI in der CE; Sie komponieren das Verhalten in der Konfiguration, anstatt Schalter zu klicken, was ein Vorteil ist, wenn Sie IaC mögen, und ein Hindernis, wenn nicht.

Apache APISIX

Apache APISIX ist ein Top-Level-Projekt der Apache Software Foundation, lizenziert unter Apache 2.0. Diese Governance ist für die Open-Source-Frage wichtig: Es ist ein Stiftungsprojekt, keine Community Edition eines einzelnen Anbieters, daher ist der OSS-Build das echte Projekt und nicht ein abgespeckter Teaser.

APISIX verfügt über ein Control-CLI für Lifecycle-Operationen und eine REST-Admin-API (standardmäßig an 127.0.0.1 gebunden) zur Verwaltung von Routen und Plugins. Das CLI startet, stoppt und lädt das Gateway neu; apisix reload übernimmt Konfigurationsänderungen, ohne Verbindungen zu unterbrechen.

# Verfügbare Steuerungsbefehle anzeigen
apisix help

# Das Gateway starten, dann nach einer Konfigurationsänderung neu laden (Hot-Reload)
apisix start
apisix reload

Am besten geeignet für: dynamisches Routing mit hohem Durchsatz, bei dem Routen und Plugins zur Laufzeit ohne Neustarts geändert werden sollen, gesteuert durch die Admin-API. Ehrliche Einschränkungen: Die Routing-Konfiguration befindet sich in der Admin-API und nicht in einem einzigen deklarativen CLI-Push, sodass Ihr „Config-in-Git“-Workflow normalerweise das Skripten von Admin-API-Aufrufen oder das Hinzufügen eines Tools wie APISIX’s ADC (API-Definition-Controller) bedeutet.

Gravitee

Gravitees zentrale API-Management-Plattform ist Open Source unter Apache 2.0. Es ist mehr als nur ein Gateway: Die Community Edition umfasst das APIM Gateway (die Laufzeitumgebung), die APIM API (eine REST-Management-Schnittstelle) und die APIM Konsole. Unternehmensfunktionen wie die ereignisnativen asynchronen APIs befinden sich in der kostenpflichtigen Edition, aber der REST-zentrierte Kern ist echtes OSS, das Sie selbst hosten können.

Die Kommandozeilen-Geschichte erfordert eine ehrliche Einschränkung. Gravitees tägliche Administration läuft über seine Management REST API und Konsole, und die offizielle selbst gehostete Installation wird oft mit dem Docker CLI durchgeführt. Es gibt ein von der Community gepflegtes graviteeio-cli auf GitHub, das die Management API umschließt, um Aktionen über Module hinweg zu automatisieren, aber es ist ein Community-Tool, keine primäre Binärdatei, daher behandeln Sie seinen Wartungsstatus so, wie Sie jedes Community-Projekt behandeln würden, bevor Sie sich darauf verlassen.

# Gravitee APIM Gateway Container ausführen (selbst gehostet, OSS)
docker run --name gravitee-gateway -p 8082:8082 graviteeio/apim-gateway:latest

Am besten geeignet für: Teams, die eine vollständige Open-Source-Managementschicht (Gateway plus Konsole plus eine Management-API zur Skripterstellung) wünschen, anstatt nur einen Proxy. Ehrliche Einschränkungen: Die Automatisierungsfläche des Herstellers ist die REST Management API, nicht ein ausgefeiltes einzelnes CLI; das Community CLI füllt die Lücke, aber Sie übernehmen dessen Wartungsrisiko.

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

Apidog ist nicht Open Source, gehört also nicht als Eintrag oben aufgeführt. Es ist ein kommerzielles Produkt mit einem kostenlosen Tarif, und ich würde Sie irreführen, wenn ich es unter Apache 2.0 einordnen würde.

Hier ist trotzdem der ehrliche Vorschlag. Die oben genannten Tools sind Gateways; sie verwalten Traffic, Routen und Plugins. Sie entwerfen nicht Ihr API-Schema, führen Ihre Endpunkt-Tests aus, generieren Ihre Dokumentation oder mocken Antworten, bevor das Backend existiert. Diese Aufgaben zusammenzuführen, bedeutet normalerweise Spectral plus openapi-generator plus einen Mock-Server plus Newman, jedes mit seiner eigenen Konfiguration. Apidog fasst Design, Tests, Mocking und Dokumentation in einem Arbeitsbereich zusammen, und apidog-cli bietet Ihnen einen Terminalpfad zu all dem.

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

# Ein Testszenario in CI ausführen (beendet sich mit einem Fehlercode ungleich Null bei Fehlschlag)
apidog run

Das CLI gibt strukturiertes JSON mit agentHints.nextSteps aus, sodass es sauber in CI- und AI-Agenten-Workflows integriert werden kann; wenn Sie API-Arbeit über Claude Code oder Ähnliches leiten, deckt APIs verwalten, ohne Ihre KI-Agenten zu verlassen dieses Muster ab. Es unterstützt auch den Import und Export von OpenAPI, das Ausführen von Szenarien und das Steuern von Mocks über die Kommandozeile. Der vollständige Apidog CLI-Leitfaden führt durch die Befehlsgruppen. Betrachten Sie es als die integrierte Free-Tier-Option neben einem selbst gehosteten OSS-Gateway, nicht als Ersatz dafür.

So wählen Sie aus

Wählen Sie basierend auf dem Workflow, nicht auf der Sternenanzahl. Wenn Sie bereits Kong betreiben, ist decK der schnellste Gewinn. Wenn Sie ein zustandsloses Gateway wünschen, das vollständig durch eine Datei definiert wird, passt KrakenD. APISIX punktet bei dynamischen Routing-Änderungen zur Laufzeit; Gravitee bietet Ihnen eine komplette Verwaltungsschicht mit Konsole. Für einen breiteren Vergleich, einschließlich der kommerziellen Plattformen, siehe die besten API-Management-Tools für 2026 und den Ansatz des Headless API Management, wenn Sie einen API-First-Stack aufbauen.

Zusammenfassung

Open-Source-API-Management über die Kommandozeile ist ausgereift. Kong Gateway OSS mit decK, Tyk, KrakenD CE, Apache APISIX und Gravitee sind alle unter Apache 2.0 oder MPL 2.0 lizenziert, alle selbst hostbar und alle vom Terminal aus steuerbar, was Git, Überprüfung und CI anstelle von Dashboard-Klicks bedeutet. Wählen Sie dasjenige, dessen Modell am besten zu Ihrer Bereitstellung passt.

Für Design, Tests, Mocking und Dokumentation, die Gateways nicht abdecken, schließt ein integriertes Tool die Lücke. Laden Sie Apidog herunter und führen Sie apidog run in Ihrer Pipeline aus, um den CLI-Pfad zu sehen, und integrieren Sie es dann in CI neben dem OSS-Gateway, für das Sie sich entscheiden.