Cloudflare entwickelt eine einheitliche CLI für das gesamte Produktportfolio

• Cloudflare baut Wrangler der nächsten Generation neu auf, um mehr als 100 Produkte und rund 3.000 HTTP-APIs über eine einzige einheitliche CLI (cf) bereitzustellen; eine technische Vorschau ist derzeit über npx cf verfügbar
• Da sich mit bestehenden OpenAPI-Schemata verschiedene Schnittstellen wie CLI-Befehle, Workers-Bindings und Agent Skills nicht ausreichend ausdrücken lassen, führt das Unternehmen ein neues schema-basiertes System auf TypeScript-Basis ein
• Entsprechend dem Trend, dass Agenten die CLI als primären Consumer verwenden, werden Regeln für Befehls-Konsistenz und Guardrails wie get/--force/--json auf Schema-Ebene erzwungen
• Mit Local Explorer startet eine Open Beta, mit der sich simulierte Ressourcen in der lokalen Entwicklung einfach durchsuchen lassen, sodass lokale Daten in KV, R2, D1 und weiteren Diensten direkt überprüft werden können
• Indem Cloudflare seine gesamte API in CLI und lokaler Umgebung in derselben API-Form konsistent bereitstellt, will das Unternehmen eine für Agenten und Entwickler gleichermaßen optimierte Developer Experience schaffen

---

Die Größe von Cloudflares API und der Wechsel zu agentenzentrierter Nutzung

• Cloudflare verfügt über mehr als 100 Produkte und rund 3.000 HTTP-API-Operationen
• Agenten entwickeln sich zu den wichtigsten Consumern von APIs, und Entwickler erstellen und deployen Anwendungen, Agenten und Plattformen auf Cloudflare über Coding-Agenten
• Cloudflare stellt seine gesamte API bereits über einen einzelnen Code Mode MCP-Server mit weniger als 1.000 Tokens bereit, muss aber noch mehr Schnittstellen abdecken, etwa CLI-Befehle, Workers-Bindings, SDKs, Konfigurationsdateien, Terraform, Entwicklerdokumentation und Agent Skills
• In der bisherigen Wrangler CLI fehlten CLI-Befehle für viele Cloudflare-Produkte, und Agenten bevorzugen tendenziell die CLI

Neuaufbau der Wrangler CLI der nächsten Generation

• Die Wrangler CLI wird zu einer CLI für ganz Cloudflare umgebaut, die Befehle für alle Produkte bereitstellt und eine einheitliche Konfiguration im Stil von infrastructure-as-code ermöglicht
• Die technische Vorschau kann über npx cf oder npm install -g cf installiert werden
• Derzeit werden nur einige Produkte unterstützt, intern testet Cloudflare jedoch bereits eine Version, die die gesamte Cloudflare-API-Oberfläche unterstützt
• Die Befehle für jedes Produkt werden aktuell mit Blick auf ergonomische Ausgaben für Agenten und Menschen geprüft und abgestimmt
• In den kommenden Monaten sollen die Stärken des bisherigen Wrangler damit zusammengeführt werden

TypeScript-basiertes Schema und Pipeline zur Code-Generierung

• Bisher wurden auf Basis von OpenAPI-Schemata automatisch API-SDKs, Terraform-Provider und der Code Mode MCP-Server generiert
• CLI, Workers-Bindings, die Konfiguration in wrangler.jsonc, Agent Skills, Dashboard und Dokumentations-Updates liefen jedoch weiterhin als manueller Prozess, was häufig zu Fehlern führte und nicht skalierbar war
• OpenAPI-Schemata können nur REST-APIs beschreiben und daher weder interaktive CLI-Befehle, die lokale Entwicklung und API-Anfragen kombinieren, noch RPC-basierte Workers-Bindings, Agent Skills oder Dokumentation abbilden
• Weil TypeScript intern bei Cloudflare als gemeinsame Sprache verwendet wird, hat sich gezeigt, dass sich APIs in TypeScript in Bereichen wie Cap n' Web, Code Mode und dem RPC-System der Workers-Plattform wirksamer ausdrücken lassen
• Deshalb wird ein neues TypeScript-Schema eingeführt, das APIs, CLI-Befehle und -Argumente sowie allen nötigen Kontext für die Generierung von Schnittstellen definiert
  • TypeScript-Typen werden dabei mit Konventionen, Linting und Guardrails versehen
  • Als eigenes Format unterstützt es flexibel jede benötigte Schnittstelle und kann zugleich OpenAPI-Schemata erzeugen

Konsistenz für Agenten und CLI sowie Context Engineering

• Agenten erwarten Konsistenz in der CLI; wenn ein Befehl info verwendet und ein anderer get, kommt es vor, dass Agenten nicht existente Befehle aufrufen
• In großen Organisationen mit Hunderten bis Tausenden von Ingenieuren lässt sich Konsistenz allein per Review kaum sicherstellen; Löcher entstehen unvermeidlich wie im Schweizer-Käse-Modell
• Würde Konsistenz nur auf der CLI-Ebene erzwungen, würden Unterschiede in der Benennung zwischen CLI, REST-API und SDK eher noch verstärkt
• Deshalb werden Regeln und Guardrails auf Schema-Ebene angewendet: immer get (niemals info), immer --force (niemals --skip-confirmations), immer --json (niemals --format) und dies konsistent über alle Befehle hinweg
• Die Wrangler CLI hat eine besondere Struktur, weil sie sowohl mit lokal simulierten Ressourcen als auch mit Remote-Ressourcen arbeitet
  • D1-Datenbanken, R2-Storage-Buckets und KV-Namespaces werden sowohl lokal als auch remote unterstützt
  • Das kann zu Verwirrung führen, wenn ein Agent glaubt, eine Remote-Datenbank zu verändern, tatsächlich aber einen Datensatz in einer lokalen Datenbank anlegt
  • Durch konsistente Standardwerte und Ausgaben, die klar machen, ob lokal oder remote gearbeitet wird, erhalten Agenten explizite Orientierung

Local Explorer — dieselbe Ressourcen-Erkundung lokal wie remote

• Local Explorer startet als Open Beta und ist sowohl in der Wrangler CLI als auch im Cloudflare Vite-Plugin verfügbar
• Während der lokalen Entwicklung lassen sich die von einem Worker verwendeten simulierten Ressourcen direkt erkunden: KV, R2, D1, Durable Objects, Workflows
• Dieselben Aktionen, die über die Cloudflare-API und das Dashboard möglich sind, lassen sich vollständig lokal in derselben API-Struktur ausführen
• Cloudflare investiert seit Jahren in vollständige lokale Entwicklung; selbst gehostete serverlose Datenbanken wie D1 können über Bindings ohne zusätzliche Einrichtung oder Tools vollständig lokal ausgeführt werden
  • Miniflare (ein Emulator für lokale Entwicklungsplattformen) stellt dieselbe API wie in der Produktion bereit und nutzt lokale SQLite-Datenbanken
  • Tests lassen sich schnell ohne Netzwerkzugriff schreiben und ausführen, und das Ganze funktioniert auch offline
• Bislang musste man zum Prüfen lokal gespeicherter Daten das Verzeichnis .wrangler/state reverse engineeren oder Tools von Drittanbietern installieren
• Wenn eine App über die Wrangler CLI oder das Cloudflare Vite-Plugin gestartet wird, erscheint eine Eingabeaufforderung zum Öffnen des Local Explorer; per Tastenkürzel e ist er erreichbar
  • Er bietet eine lokale Oberfläche, auf der sich die aktuell mit dem Worker verbundenen Bindings und die dazugehörigen Daten einsehen lassen
• Beim Bauen mit Agenten ist das hilfreich, um nachzuvollziehen, wie Agenten mit Daten umgehen; außerdem sind Schema-Validierung, das Seeding von Testdatensätzen und das Zurücksetzen per DROP TABLE möglich
• Zudem stellt Cloudflare einen Spiegel der Cloudflare-API bereit, der nur lokale Daten verändert, sodass lokale Ressourcen über dieselbe API wie Remote-Ressourcen angesprochen werden können
  • Da lokale und Remote-APIs dieselbe Form haben, wird bei Übergabe des Flags --local in der CLI die Anfrage einfach an die lokale Mirror-API umgeleitet und funktioniert unverändert
• Auf die lokale API kann über den Pfad /cdn-cgi/explorer/api zugegriffen werden; Agenten können dort die OpenAPI-Spezifikation erkennen und lokale Ressourcen verwalten

Bitte um Feedback und nächste Schritte

• Die technische Vorschau der CLI der nächsten Generation ist über npx cf oder npm install -g cf verfügbar
• Gesucht wird Feedback nicht nur zu den Funktionen der aktuellen technischen Vorschau, sondern auch dazu, was Nutzer von einer CLI für die gesamte Cloudflare-Plattform erwarten
  • Aufgaben, für die man im Dashboard mehrfach klicken muss, die aber als einzelner CLI-Befehl gewünscht sind
  • Dinge, die in wrangler.jsonc konfiguriert werden sollen, etwa DNS-Einträge oder Cache-Regeln
  • Stellen, an denen Agenten hängen bleiben, und Befehle, die in der CLI verfügbar sein sollten
• Feedback nimmt Cloudflare im Cloudflare Developers Discord entgegen

[eoeoe]

Ich wünschte, man würde auch den Fehler beheben, der auftritt, wenn man versucht, eine D1-Datenbank mit konfigurierter FTS-Tabelle zu exportieren.
Das ist für mich beim Einsatz von wrangler nämlich am unbequemsten.

[GN⁺]

Hacker-News-Kommentare

• Es wäre gut, wenn die Wrangler CLI die für die lokale Entwicklung nötigen API-Token-Berechtigungen im Voraus anzeigen würde.
  So wäre vor dem Deployment klar, welche Berechtigungen benötigt werden, und ideal wäre ein Befehl wie cf permissions check, mit dem sich fehlende oder unnötige Berechtigungen prüfen lassen.

  • Stimme voll zu. Wenn ChatGPT anfangs die Berechtigungen falsch setzt, muss man am Ende stundenlang in der Dokumentation wühlen oder verschiedene Token-Kombinationen ausprobieren.
  • Ein Doctor-Befehl für so etwas wäre wirklich praktisch. Ich wünschte, mehr Dienste würden so etwas anbieten.
  • Ich habe früher einmal versehentlich ein Token wegen eines Tippfehlers falsch eingerichtet; so eine Funktion hätte damals sehr geholfen.
  • Noch besser wäre es, wenn die CLI automatisch Schlüssel erzeugen könnte.
  • Im Kern geht es meiner Meinung nach darum, die Discoverability der API zu erhöhen.
    GraphQL folgt den HATEOAS-Prinzipien gut, deshalb ist es für LLMs vorteilhaft, APIs zu erkunden.
    Viel besser als Probleme durch nicht passende Dokumentationsversionen ist eine Struktur, in der die API ihre Funktionen selbst offenlegt.

• Ich hätte gern zuerst Berechtigungssteuerung auf Ebene von Ressourcengruppen.
  Derzeit gibt es nur zonenbasierte Berechtigungen, sodass bei Ressourcen wie Workern, die keiner Zone zugeordnet sind, Code selbst mit niedrigen Rechten ersetzt oder gelöscht werden kann.
  Noch besser wäre Unterstützung für eine Super-Account- + Sub-Account-Struktur wie bei GitHub Enterprise. Beispiel: ACME Corp / ACME Corp (Prod)

  • Ich frage mich, ob das vielleicht dasselbe Konzept ist wie die Funktion Cloudflare Organization.
  • Auch wenn sich Domains nicht teilen lassen, wäre eine Superaccount- + Subaccount-Struktur wirklich nützlich.
  • Ich stimme zu, dass Worker, weil sie nicht zonenbasiert sind, weniger nützlich eingebunden werden können.

• Toller Artikel, hat mich inspiriert. Ich war nur überrascht, dass TypeSpec nicht erwähnt wurde.
  Das ist eine Schema-Sprache im TypeScript-Stil, die ich gern als „so würde OpenAPI aussehen, wenn es wirklich gut gemacht wäre“ beschreibe.
  Vermutlich wurde entschieden, dass eine Eigenimplementierung einfacher und flexibler ist. Heutzutage sind dank Agenten die BYO-Kosten auch deutlich gesunken.

  • Ich mag TypeSpec wirklich sehr. OpenAPI zu schreiben wird damit viel einfacher.
    In letzter Zeit bevorzuge ich aber APIs im Stil von aep.dev. Wegen der konsistenten Muster lässt sich aepcli sofort verwenden oder leicht selbst bauen.
    Auch Terraform funktioniert direkt ohne separaten Provider.
  • Mich würde interessieren, welche Teile von OpenAPI dadurch verbessert wurden.

• Das aktuelle CLI-first-Design rund um AI-Agenten finde ich spannend.
  Als wir selbst Developer-Tools gebaut haben, haben wir zuerst CLI und API erstellt und das Dashboard erst später ergänzt.
  Besonders gut gefällt mir die oben erwähnte Idee zu cf permissions check.
  Agenten können CLI zwar gut nutzen, sind aber schwach bei der Diagnose von Fehlerursachen.
  Klare Fehlermeldungen wie „Scope X fehlt, führe cf token add --scope X aus“ sind viel wichtiger.

• Man soll die Technical Preview direkt mit npx cf ausprobieren können, aber ich habe ein paar Fragen.
  Ist das Open Source, und ist geplant, es ohne Node.js als Single-Binary bereitzustellen?
  Könnte vielleicht etwas wie das kürzlich übernommene Bun dafür genutzt werden?

  • Ich habe das Repository auch nicht gefunden, aber das npm-Paket hat eine MIT-Lizenz und enthält Sourcemaps, daher wirkt es so, als würde es bald veröffentlicht.

• Langzeit-Token würde ich gern vermeiden.
  Stattdessen wäre es gut, wenn man in der CLI leicht kurzlebige, eingeschränkte Token erzeugen und per Datei verwalten oder automatisch erneuern könnte.
  Eine andere Möglichkeit wäre ein Proxy-Modus, bei dem Zugriffsrechte nur für bestimmte Domains oder Buckets delegiert werden.

  • Mir gefällt das Vorgehen von GitLab, bei dem über einen SSH-Server in einem Schritt kurzlebige PATs erzeugt werden.

• Ironischerweise führt das Zeitalter der AI-Agenten wieder zurück zu CLI-zentrierter Entwicklung.
  Jedes Mal, wenn ich den Cloudflare-Cache leere, muss ich im Web-UI mehrere Schritte anklicken; es wäre viel besser, einfach dem OpenClaw-Agenten einen Befehl zu geben.

  • Man muss nicht unbedingt OpenClaw verwenden. Man kann den CLI-Befehl direkt aufrufen. Genau das ist der Kern einer CLI.

• Wranglers Authentifizierung bietet nur zwei Wege: OAuth (mit Vollzugriff) und im Dashboard manuell erzeugte statische Token.
  Das passt aber nicht zu Fällen, in denen Menschen und AI-Agenten unterschiedliche Berechtigungsgrenzen haben sollen.
  Es wäre gut, wenn sich direkt in der CLI scoped, kurzlebige Token erzeugen ließen.
  Das wird auch in GitHub Issue #13042 diskutiert.
  Token sollten nicht nur nach Ressourcentyp, sondern auch nach Ressourcen-ID und Aktion granularisiert werden.

• Am 1. April hat Cloudflare EmDash zusammen mit Unterstützung für x402 vorgestellt, und jetzt scheint der Fokus auf der CLI zu liegen.
  Es wirkt, als würde Cloudflare sein Developer-Ökosystem still und leise neu aufbauen, mit Agenten statt Menschen als primären Nutzern.

• Es heißt, API, CLI-Befehle, Argumente und Kontext seien mit TypeScript-Schemata definiert worden.
  Ich frage mich, warum dieses Tool oder Framework hier nicht vorgestellt wurde.
  Mich würde interessieren, ob es eine ähnliche Struktur wie das oben erwähnte TypeSpec hat.