cf CLI in der Praxis: Cloudflare steuern und Worker migrieren

Der eigentliche Gewinn liegt nicht in kürzeren Befehlen, sondern in weniger Integrationsaufwand. Gründer können ein Konto prüfen, ohne sich durch das Dashboard zu klicken. Plattformteams erhalten maschinenlesbare Ergebnisse für ihre Agenten. Agenturen wiederum können Cloudflare-Aufgaben über Kundenkonten hinweg vereinheitlichen, ohne für jedes Produkt einen eigenen API-Wrapper zu pflegen.

Für cf fällt keine separate Lizenz an. Das Repository ist Open Source, ein kleiner Worker kann im Cloudflare-Tarif Free starten, und Workers Paid hat einen monatlichen Mindestpreis von $5. Am anderen Ende des Budgets steht etwa Spacelift als allgemeine Plattform für Infrastruktur-Governance mit einem Starter+-Tarif für $20,000. cf spart einen großen Teil der API-Verkabelung zwischen diesen Extremen. Freigaben, Audit-Trails und sorgfältig zugeschnittene Berechtigungen ersetzt es nicht.

Was die neue cf CLI tatsächlich ist

cf kombiniert eine generierte Befehlsoberfläche für die gesamte Cloudflare API mit eigens entwickelten Projekt-Workflows, unter anderem zum Erstellen, Bauen, Migrieren und Bereitstellen von Workers. Wrangler lässt sich als gut ausgestattete Spezialwerkbank für Workers verstehen. cf ergänzt dazu das Verzeichnis und den Serviceschalter für das gesamte Cloudflare-Gebäude – und leitet bestimmte Worker-Aufgaben weiterhin an Wrangler weiter, wenn es dafür das zuverlässigere Werkzeug ist.

Genau darin unterscheidet sich diese Veröffentlichung auch von Cloudflares technischer Vorschau vom 13. April. Der April-Build deckte nur eine kleine Produktauswahl ab. Erst die Open Beta im September bringt die vollständige API-Abdeckung, standardmäßige JSON-Ausgaben, die Befehlssuche, eine TypeScript-Konfiguration für Workers und Vite als voreingestellten Worker-Pfad.

Vier Bausteine verändern den Arbeitsablauf:

• Vollständige API-Oberfläche: Generierte Befehle folgen dem Schema cf <product> [group…] <operation> und decken mehr als 3,000 Operationen ab.
• Befehlssuche: cf cli search nimmt eine natürlich formulierte Aufgabe entgegen und liefert fünf gewichtete Treffer als JSON. Der Befehlsbaum muss nicht auswendig gelernt werden.
• JSON als Standard: Strukturierte API-Ergebnisse landen als formatiertes JSON in der Standardausgabe. Menschen, Skripte und Coding-Agenten können deshalb dieselbe Antwort filtern.
• Typisierte Worker-Einrichtung: cloudflare.config.ts liefert TypeScript-Feedback in Editoren und für Coding-Agenten. Der Anfang gilt heute den Workers. Eine kontoweite Konfiguration für DNS, Zonen und Richtlinien ist eine Zukunftsperspektive, keine aktuelle Funktion.

cf CLI installieren, anmelden und den ersten Lesezugriff prüfen

Am besten beginnt der Test mit einem reinen Lesezugriff. Damit lassen sich Paket, Zugangsdaten, Kontowahl, Befehlssuche und JSON-Pfad prüfen, bevor ein Skript Änderungen vornehmen darf.

Das offizielle Paket setzt Node.js 22 oder neuer voraus. Bei der Nutzung im Terminal verwaltet cf auth login das standardmäßige OAuth-Profil. In CI wird ein eng begrenztes CLOUDFLARE_API_TOKEN gesetzt; cf prüft diese Umgebungsvariable vor einem gespeicherten OAuth-Profil. Wer zwischen Kunden- oder Unternehmenskonten wechselt, kann benannte Profile anlegen und unterschiedlichen Verzeichnissen zuordnen.

Die Anfrage an cf cli search sollte allgemein bleiben: Gesucht werden Aktion und Ressourcentyp, nicht Domain, E-Mail-Adresse, Konto-ID oder Token.

node --version
npm i -g cf
cf --version

cf auth login
cf auth whoami

cf cli search "list zones in an account"
cf zones list | jq -e 'type == "array" and all(.[]; has("name") and has("status"))'

Für diese Aufgabe setzt die Suche derzeit cf zones list auf Platz eins. Die letzte Zeile dient als Nachweis: Sie führt einen schreibgeschützten API-Aufruf aus und endet nur dann erfolgreich, wenn das Ergebnis ein JSON-Array ist, dessen Einträge name und status enthalten. Bei mehreren Konten lässt sich mit --profile ein benanntes Profil auswählen oder der Befehl mit --account-id auf ein Konto begrenzen.

Ein Token gehört nicht in den Verlauf der Shell. Ein CI-Prozess erhält stattdessen ein Token mit genau den Lese- oder Schreibrechten, die der Job benötigt. Für eine persönliche Terminalsitzung ist OAuth die bequemere Voreinstellung, weil cf das ausgewählte Profil aktualisieren kann.

Was der isolierte Test belegt hat

Eine frische, isolierte Installation lieferte am 29. September cf v1.0.0-beta.5. Die Befehlssuche gab ein gültiges JSON-Array mit fünf Einträgen zurück, cf init erzeugte ein typisiertes Worker-Projekt, und sowohl das neue Projekt als auch ein migriertes Vite-Testprojekt ließen sich lokal bauen. In der Umgebung waren keine Zugangsdaten für ein Cloudflare-Testkonto vorhanden. Ein authentifizierter Lesezugriff auf Zonen und ein Deployment wurden deshalb nicht als erfolgreich abgeschlossene Tests ausgewiesen.

Diese Grenze ist entscheidend: Ein erfolgreicher lokaler Build bestätigt den Projektpfad. Er beweist weder, dass das Token die nötigen Produktionsrechte besitzt, noch dass ein Deployment Cloudflare erreicht hat.

Mit der cf CLI einen Cloudflare Worker erstellen und das Ergebnis prüfen

cf init ist der schnellste saubere Test für den neuen Projekt-Workflow. In einem leeren Verzeichnis entstehen TypeScript-Quellcode, cloudflare.config.ts, vite.config.ts, Paketskripte und generierte Worker-Typen. Anschließend übergibt cf build an das Cloudflare Vite Plugin und erzeugt eine standardisierte Build-Ausgabe.

cf init hello-cf --package-manager npm
cd hello-cf
npm run build

# In a copied existing Vite Worker:
cf migrate --dry-run
cf migrate
npm run build

Nach beiden Varianten lohnt sich ein Blick in cloudflare.config.ts. Bei einem einfachen Worker ist dort ein worker-Block mit Name, Kompatibilitätsdatum, Einstiegspunkt und typisierten Bindings zu erwarten. Ein Text-Binding wird über die Konfigurations-API deklariert, statt durch mehrere Umgebungsblöcke kopiert zu werden. Hier zahlt sich TypeScript aus: Ein falsch geschriebener Feldname kann schon im Editor auffallen, bevor das Deployment scheitert.

Die erzeugte Vite-Konfiguration ist kein Beiwerk. Für lokale Entwicklung und Builds ist Vite jetzt der Standardpfad von cf; Cloudflare empfiehlt das Vite-Plugin sowohl für Frontends als auch für Backend-APIs. Im isolierten Projekt wurde npm run build an Vite delegiert und erfolgreich abgeschlossen. Auf ein Deployment wurde bewusst verzichtet. Sobald Review und Kontotest abgeschlossen sind, baut der dokumentierte Befehl cf deploy das Projekt und lädt es standardmäßig hoch.

Wo Wrangler weiterhin hingehört

Eine erfolgreiche cf-Installation ist kein Grund, Wrangler zu entfernen. Die richtige Migrationsentscheidung hängt vom Buildpfad des Projekts ab.

Bei einem bestehenden Vite-Worker kann cf migrate eine Wrangler-Konfiguration in JSON, JSONC oder TOML in cloudflare.config.ts übertragen. Der Befehl erkennt das Cloudflare Vite Plugin neben der Wrangler-Konfiguration und wählt dann den Vite-Pfad. Ist das Plugin nicht deklariert, greifen aktuelle Beta-Versionen stattdessen auf den Wrangler-Bundler zurück. Zuerst sollte die Vorschau ausgeführt und jeder Folgehinweis gelesen werden. Migriert wird eine Kopie oder ein sauberer Branch, nicht direkt das Arbeitsprojekt.

Bei JavaScript-Workers, die weiterhin vom esbuild-Verhalten von Wrangler abhängen, delegiert cf Entwicklung und Deployment an Wrangler. Dasselbe gilt für Rust- und Python-Workers. Das ist Kompatibilität, keine gescheiterte Migration: Das Team nutzt cf als Eingangstür, während der bewährte Builder im Ablauf bleibt.

Auch Cloudflares Support-Zeitplan wird leicht missverstanden. Wrangler soll nach dem Ende der Open Beta noch 18 Monate gepflegt werden – nicht 18 Monate ab dem Start am 28. September. Es gibt keinen Grund, ein Rust-, Python- oder esbuild-Projekt noch diese Woche mit Gewalt auf Vite umzustellen.

Sieben Workflows, die sich zuerst auszahlen

Die besten ersten Einsatzfälle haben eines gemeinsam: Sie sparen wiederholte Such- und Formatierungsarbeit, ohne schon am ersten Tag weitreichende Schreibrechte zu vergeben.

1. Eine Agentur vereinheitlicht Kontoprüfungen

Ein Agenturteam kann jedem Kundenverzeichnis ein benanntes OAuth-Profil zuweisen, den passenden Lesebefehl suchen und immer dieselbe JSON-Struktur an ein Prüfskript übergeben. Das verringert Abweichungen, die entstehen, wenn eine Person durch Dashboards klickt und eine andere einen eigenen curl-Befehl pflegt. Besonders bei DNS, Zonen, Kontoeinstellungen und Sicherheitsprüfungen zahlt sich die Wiederholbarkeit über Kundenprojekte hinweg aus.

2. Ein Plattformteam gibt Coding-Agenten eine sichere Cloudflare-Schnittstelle

Ein Plattformverantwortlicher kann cf cli search mit einer Regel in AGENTS.md absichern, Lesebefehle standardmäßig zulassen und für Änderungen eine menschliche Freigabe verlangen. Die Suche verhindert, dass der Agent veraltete Wrangler-Syntax errät; JSON hält die Ausgabe kompakt und filterbar. Das ist besonders nützlich, wenn Agenten bereits Buildstatus, Logs, Queues oder Kontoressourcen prüfen und das Team dafür eine einheitliche Schnittstelle benötigt.

3. Der Bereitschaftsdienst sammelt Kontext zu einem Vorfall

Während eines Vorfalls kann die zuständige Person nach dem passenden Lesezugriff für Logs, Zonen, Regelsätze oder Analysen suchen, statt mehrere Produktoberflächen zu durchforsten. Der genaue Befehl bleibt wichtig und die Berechtigungen gelten weiterhin; die Suche findet jedoch lokal statt und die Antwort ist direkt für jq nutzbar. Bei Teams mit Jobs wie Cloudflare Browser Run verkürzt das den Weg vom fehlgeschlagenen Job zum umgebenden Kontostatus.

4. Ein Gründer startet einen Worker ohne eigenen Toolchain-Entwurf

Für einen Webhook, einen Weiterleitungsdienst oder eine kleine interne API kann ein Gründer cf init ausführen, den erzeugten Worker samt Binding prüfen und anschließend mit Vite bauen, ohne jedes Paket einzeln auszuwählen. Das Projekt kann im Tarif Workers Free beginnen. Wird der kostenpflichtige Tarif benötigt, liegt der aktuelle Mindestpreis bei $5 pro Konto und Monat. Der Nutzen ist ein kurzer Weg zu einem lokal prüfbaren Artefakt – kein Versprechen kostenloser Produktionsabläufe.

5. Ein Vite-Team überführt die Konfiguration, ohne die Anwendung neu zu schreiben

Ein Engineering-Team mit Vite-basiertem Worker kann cf migrate --dry-run auf einer Kopie ausführen, das erzeugte TypeScript prüfen und vor jeder Änderung am Deployment einen Build starten. Das lohnt sich besonders, wenn sich Umgebungsblöcke ständig wiederholen. Das neue Format kann die Konfiguration aus einer gemeinsamen Basis berechnen; migriert werden sollte jedoch das Verhalten, nicht bloß die Dateisyntax.

6. Ein Daten- oder Betriebsteam übernimmt Cloudflare-Lesezugriffe in Berichte

Da strukturierte Ergebnisse standardmäßig als JSON erscheinen, lässt sich ein Lesezugriff an jq, einen Warehouse-Loader oder einen geplanten Bericht weiterreichen, ohne eine Unicode-Tabelle auszulesen. Der geschäftliche Nutzen ist angenehm unspektakulär: weniger Ausgabeadapter und weniger fragile Parsing-Regeln. Dafür wird ein begrenztes Lesetoken verwendet, und die Befehlsausgabe gehört nicht in öffentliche CI-Logs.

7. Ein Worker-Team prüft lokale Ressourcen vor dem Produktionszugriff

Unterstützte Befehle akzeptieren --local und sprechen mit einer kurzlebigen Miniflare-Instanz, die lokalen Zustand verwendet. Dazu gehören definierte Operationen für KV, D1 und R2. Existiert keine lokale Entsprechung, meldet cf einen Fehler, statt unbemerkt auf die Produktion auszuweichen. Beim Bau eines Cloudflare AI Search Workers lässt sich über diese Grenze mit unterstützenden lokalen Daten testen, ohne dass ein Entwicklungsbefehl zum Remote-Schreibzugriff wird.

Zwei Produkte, die sich rund um cf lohnen

Die Geschäftschance liegt nicht in der CLI selbst, sondern in der Kontrollebene, die Teams trotz der sehr breiten API-Oberfläche weiterhin benötigen.

Beste Chance: Cloudflare-Änderungskontrolle für Agenturen

Sinnvoll ist eine schlanke Freigabe- und Nachweisebene für Agenturen oder kleine Plattformteams, die mehrere Cloudflare-Konten verwalten. Ein Nutzer schlägt eine Änderung an DNS, Zone, WAF oder Worker vor. Das Produkt erfasst per cf den aktuellen JSON-Zustand, zeigt eine lesbare Differenz, holt eine Freigabe ein, führt die Änderung mit einem begrenzten Profil aus und speichert das Ergebnis.

Das Nachfragesignal ist überschaubar, aber kommerziell: cloudflare dns management kommt in den USA auf etwa 170 Suchanfragen pro Monat, einen CPC von $6 und Gebote für die oberen Anzeigenplätze zwischen $3.85 und $36.64. Auch allgemeine Infrastruktur-Governance trägt reale Budgets. Spacelift nennt für Starter+ einen Preis von $20,000. Ein Cloudflare-spezifisches Produkt kann günstiger und leichter einzuführen sein, weil es nicht jede Cloud verwalten muss.

Die kleinste verkaufbare Variante ist eine GitHub-App oder eine gehostete Review-Warteschlange für DNS- und Worker-Änderungen: getrennte Profile, eine Positivliste erlaubter Befehle, Vorher-nachher-JSON und Rollback per Klick, sofern die zugrunde liegende API das unterstützt. Die entscheidende Hürde ist der Burggraben. cf liefert die Befehlsabdeckung bereits; verteidigbar sind Richtlinien, Nachweise, Berechtigungen und der Agentur-Workflow. Eine dünne grafische Hülle lässt sich schnell kopieren.

Nützliches Feature: Bereitschaft für die Worker-Migration prüfen

Denkbar ist ein Scanner, der ein Repository als natives Vite-, Wrangler-gestütztes esbuild-, Python- oder Rust-Projekt einordnet, anschließend die sichere Migrationsvorschau ausführt und alle Folgeaufgaben in eine Pull-Request-Checkliste überführt. Käufer sind Teams mit einem ganzen Worker-Portfolio, nicht einzelne Entwickler, die nur ein kleines Projekt migrieren.

Als eigenständiges Unternehmen ist die Nachfrage zu gering. cloudflare worker deployment erreicht in den USA etwa 10 Suchanfragen pro Monat, auch wenn die Suchabsicht transaktional ist. Das vernünftige MVP ist ein kostenpflichtiges Feature innerhalb eines Cloudflare-Betriebsprodukts oder ein Migrationsservice: Repository-Scan, cf migrate --dry-run, Build-Prüfung und ein klarer Bericht zum Wrangler-Fallback. Der Haken ist die hohe Änderungsgeschwindigkeit während der Beta. Der Scanner muss die Versionen von cf und Cloudflare Vite Plugin eng verfolgen, sonst veraltet seine Empfehlung schneller als die geprüften Projekte.

Grenzen und die nüchterne Entscheidung

cf eignet sich jetzt für die Befehlssuche, JSON-basierte Kontolesungen, neue Vite-Workers und vorsichtige Migrationstests. Wo cf an Wrangler delegiert, bleibt Wrangler installiert. Schreibzugriffe auf die Produktion gehören hinter ausdrückliche Berechtigungsumfänge und ein Review.

Die Open Beta macht cloudflare.config.ts noch nicht zur zentralen Wahrheit für das gesamte Konto. Sie beginnt mit Workers. Ebenso wenig wird jede Cloudflare-API-Operation automatisch zu einem sicheren Geschäftsprozess. Die vollständige API-Abdeckung vergrößert die Reichweite eines Tokens. Dadurch werden Minimalberechtigungen und Befehlsprüfungen wichtiger, nicht unwichtiger.

Auch die lokale Option ist bewusst begrenzt. Unterstützte Operationen für KV, D1, R2, Durable Object und Workflow können lokalen Zustand verwenden; fehlt einer Operation jedoch eine Entsprechung im lokalen Explorer, endet sie mit einem Fehler. Das ist eine sinnvolle Sicherheitseigenschaft, bedeutet aber zugleich: --local ist kein universelles Offline-Abbild von Cloudflare.

Beta-Versionen entwickeln sich schnell. Für die Teamarbeit sollte cf deshalb in den Projektabhängigkeiten festgeschrieben, die erzeugte Konfiguration geprüft und in CI die lokale Projektversion verwendet werden. Eine globale Installation ist für die Befehlssuche praktisch; eine festgeschriebene Version stellt bei allen Beteiligten dasselbe Verhalten sicher.

Wenn ein sicherer Cloudflare-Automatisierungspfad für Ihr Team entworfen und umgesetzt werden soll, finden sich weitere Informationen unter KI-Produktionssysteme.