Ich brauche keinen KI-Agenten, der besser durch ein Dashboard klickt. Ich will, dass er einen klaren Befehl hat, das Ergebnis versteht und stoppt, bevor er etwas tut, das ich nicht freigegeben habe.
Genau deshalb interessiert mich Cloudflares neue cf CLI. Cloudflare hat die Open Beta am 28. September 2026 vorgestellt.
Der Einstieg ist einfach: cf installieren, bei Bedarf mit cf login anmelden und ein bestehendes Wrangler-Projekt mit cf migrate umstellen. Diese Befehle sind aber nur der Anfang. Interessanter ist, wie das Werkzeug aufgebaut ist.
Was ist Cloudflare cf?
cf ist Cloudflares neue Kommandozeilenoberfläche. Laut offizieller Paketdokumentation wird sie aus der öffentlichen OpenAPI-Definition erzeugt, also der strukturierten Beschreibung der Cloudflare-API.
Einfach gesagt: Entwickler und Agenten bekommen Terminalbefehle für Cloudflare-Funktionen, statt jede HTTP-Anfrage selbst zusammensetzen zu müssen.
Laut Cloudflares Ankündigung deckt cf über 3.000 API-Operationen ab, gegenüber ungefähr 280 bei Wrangler.
Mich interessiert daran weniger die Zahl als die Einheitlichkeit. Ein wiederholbarer Vorgang sollte nicht jedes Mal eine neue Tour durchs Dashboard erfordern. Egal, ob ich selbst arbeite oder einen Agenten unterstützend einsetze.
Das Projekt ist Open Source auf GitHub. Bei Infrastruktur-Werkzeugen ist mir das wichtig: Ich möchte nachsehen können, was ein Befehl tatsächlich macht, statt seinem Namen vertrauen zu müssen. Dahinter steckt derselbe Gedanke wie in meinem Beitrag über offenen und einsehbaren Code.
Installieren und bei Bedarf anmelden
Du brauchst Node.js 22 oder neuer, wie die Paket-README angibt. Prüfe die Version und installiere das offizielle npm-Paket:
node --version npm install --global cf cf --help
Sobald du mit deinem Cloudflare-Konto arbeiten möchtest:
cf login
Ein hilfreiches Detail: cf login ist ein Alias für cf auth login. Das bestätigt die Implementierung ausdrücklich. Verwende einen der beiden Befehle, nicht beide hintereinander. Anmeldung und Profilverwaltung liegen unter cf auth.
Für Automatisierung hat CLOUDFLARE_API_TOKEN laut dokumentierter Reihenfolge Vorrang vor OAuth-Profilen. Ein gesetzter Token kann also das Profil übersteuern, mit dem du eigentlich arbeiten wolltest. Prüfe Zugangsdaten und Ziel, bevor du etwas auf Cloudflare änderst. Tokens gehören in die Secret-Verwaltung, nicht in den Quellcode oder in Agenten-Prompts.
Einen neuen Worker starten: lokal ist nicht live
Der dokumentierte Ablauf für ein neues Projekt:
cf init my-worker cd my-worker cf dev
Die Initialisierung erstellt einen Hello-World-Worker samt Konfiguration und Entwicklungsdateien und installiert die Abhängigkeiten. cf dev startet die Entwicklung. Das ist noch keine Veröffentlichung.
Wenn das Projekt geprüft und getestet ist, beende den Entwicklungsserver oder öffne ein weiteres Terminal im Projektverzeichnis. Das Deployment ist eine eigene Entscheidung:
cf deploy
cf deploy baut das Projekt standardmäßig und lädt das Ergebnis hoch. Das ist das dokumentierte Deployment-Verhalten, kein temporärer Link zu deinem Laptop.
Hier liegt der Unterschied zum Quick-Tunnels-Ablauf aus meinem vorherigen Beitrag. Ein Tunnel macht einen laufenden lokalen Dienst erreichbar. Ein Deployment veröffentlicht dein Projekt auf Cloudflare. Diese Unterscheidung muss klar bleiben, gerade wenn ein Agent die Befehle ausführt.
Ein bestehendes Wrangler-Projekt sicher migrieren
Der Befehl lautet:
cf migrate
Meine Empfehlung: Sorge zuerst dafür, dass du die Änderungen sauber prüfen kannst. Starte im bestehenden Projektverzeichnis, committe deine bisherigen Änderungen und lege einen eigenen Branch an:
git status --short git switch -c chore/migrate-to-cf cf migrate --dry-run
Die Ausgabe von git status --short sollte vor dem Fortfahren leer sein. Der Migrationsbefehl unterstützt --dry-run ausdrücklich, um die betroffenen Dateien anzuzeigen, ohne sie zu schreiben. Es gibt auch --force für ein Arbeitsverzeichnis mit uncommitteten Änderungen. Das würde ich aber nicht zur Standardanleitung für eine Migration machen.
Nach der Prüfung der Vorschau:
cf migrate
Lies das Ergebnis, bevor du weitermachst. Der Migrationsablauf kann erforderliche Nacharbeiten melden und mit einem Fehler enden. Behebe diese zuerst. Dass Dateien erzeugt wurden, ist noch kein Grund, zum Deployment weiterzugehen.
Prüfe nach erfolgreicher Migration sowohl bestehende Änderungen als auch neue Dateien:
git status --short git diff --stat git diff cf build
git diff zeigt keine unversionierten Dateien. Öffne deshalb auch neue Konfigurationsdateien, die git status --short auflistet.
Führe anschließend die vorhandenen Projekttests aus und prüfe die Deployment-Einstellungen, bevor du veröffentlichst.
Dabei gibt es zwei wichtige Wege. Die Bundler-Auswahl im Quellcode verwendet standardmäßig Vite, wenn @cloudflare/vite-plugin deklariert ist, andernfalls Wrangler.
cf migrate bedeutet also nicht, dass jedes Projekt automatisch auf Vite umgebaut wird. Und eine migrierte Konfiguration beweist noch nicht, dass alles bereit für Produktion ist. Prüfe den tatsächlichen Diff, einschließlich Änderungen an Abhängigkeiten und Skripten.
Warum das für KI-Agenten sinnvoll ist
Interessant ist nicht, vor ein Terminal das Wort „KI“ zu schreiben. Interessant ist, unnötiges Raten zu vermeiden.
Befehle finden statt erfinden
Ein Agent kann nach der benötigten Operation suchen:
cf cli search "list DNS records"
Cloudflares Hinweise zur Befehlssuche sagen Agenten, zuerst zu suchen und danach den ausgewählten Befehl mit --help zu prüfen. Die Suchanfrage oben beschreibt eine Operation. Sie ändert keine DNS-Einträge.
Dieselben Hinweise verlangen anonyme Suchanfragen. Keine Domainnamen, Konto-IDs, E-Mail-Adressen oder Tokens hineinschreiben. „List DNS records“ reicht, um einen Befehl zu finden. Das konkrete Ziel gehört in den anschließenden, geprüften Aufruf.
Meine Anweisung an einen Agenten wäre:
Finde den Befehl zum Auflisten von DNS-Einträgen. Erkläre, welches Konto und welche Zone du verwenden würdest. Erstelle, ändere oder lösche nichts ohne meine Freigabe.
Das ist eine Anweisung, die ich einem Agenten geben würde, kein eingebautes Berechtigungssystem.
Strukturierte Daten statt dekorativer Ausgabe
Laut Ausgabedokumentation erscheinen strukturierte API-Ergebnisse als JSON auf stdout. Dadurch lassen sie sich beispielsweise mit jq filtern, bevor die relevanten Felder an einen Agenten gehen.
Eine Einschränkung gehört dazu: Text- und Binär-Endpunkte können ihre Daten direkt ausgeben. „JSON-first“ heißt nicht, dass jeder denkbare Befehl ein JSON-Dokument zurückliefert.
Für mich liegt der Nutzen auf der Hand: Nur die Felder herausziehen, die für die nächste Entscheidung gebraucht werden. Nicht die ganze Unterhaltung mit Ausgabe füllen, die niemand benötigt.
Lokale Operationen ausdrücklich kennzeichnen
Die Dokumentation lokaler Ressourcen beschreibt --local für unterstützte Ressourcenbefehle. Nicht unterstützte lokale Operationen liefern einen Fehler, statt still auf Produktion auszuweichen.
Diese Grenze gefällt mir. Ein Befehl, der die gewünschte lokale Operation nicht ausführen kann, sollte sichtbar scheitern. Das Flag bedeutet aber nicht, dass jedes Cloudflare-Produkt vollständig lokal unterstützt wird. Prüfe den konkreten Befehl.
TypeScript-Konfiguration ist hilfreich, aber keine Magie
Das neue Konfigurationsformat heißt cloudflare.config.ts, beginnt bei Workers und setzt für die Entwicklung standardmäßig auf Vite. Typprüfung kann Entwicklern und Agenten helfen, eine ungültige Eigenschaft schon vor dem Deployment zu erkennen.
Sie sagt dir nicht, ob das ausgewählte Konto stimmt, ob eine Route öffentlich sein sollte oder ob Zugangsdaten zu viele Rechte haben. Typen helfen bei der Struktur einer Konfiguration. Sie genehmigen keine Infrastrukturentscheidungen.
Die Konfiguration der gesamten Plattform ist weiterhin Roadmap, keine Zusage für den ersten Veröffentlichungstag.
Kopierbarer Agent-Prompt: cf installieren und von Wrangler migrieren
Wenn ein KI-Coding-Agent die lokale Migration übernehmen soll, füge den folgenden Prompt ein, während der Agent im Stammverzeichnis deines bestehenden Wrangler-Projekts arbeitet. Der Codeblock hat einen Copy-Button.
Du arbeitest in einem bestehenden Cloudflare-Projekt, das derzeit Wrangler verwendet. Migriere es sorgfältig auf Cloudflares neue `cf` CLI. Ziele: - Die offizielle `cf` CLI installieren und verifizieren. - Das bestehende Verhalten und die Cloudflare-Konfiguration des Projekts erhalten. - Das Projekt mit `cf migrate` migrieren. - Das Ergebnis lokal validieren. - Nicht in Produktion deployen, außer ich fordere es ausdrücklich an. Vorgehen: 1. Prüfe zuerst das Projekt. Ermittle Paketmanager, Node.js-Version, Wrangler-Konfiguration, Package-Skripte, Cloudflare-Bindings und den aktuellen Git-Status. Ändere noch nichts. 2. `cf` benötigt Node.js 22 oder neuer. Ist die aktuelle Laufzeit älter, verwende den bereits im Projekt eingerichteten Version-Manager, falls vorhanden. Nimm keine anderen unnötigen Änderungen an der Umgebung vor. 3. Stelle sicher, dass der Git-Worktree sauber ist. Falls nicht, stoppe und nenne mir exakt die uncommitteten Änderungen. Verwende weder `git reset` noch `git clean` oder `cf migrate --force` und verwerfe keine meiner Änderungen. 4. Erstelle einen Migrations-Branch namens `chore/migrate-to-cf`. 5. Installiere die offizielle CLI mit `npm install --global cf` und führe danach `cf --version` sowie `cf --help` aus, um die Installation zu prüfen. 6. Prüfe die Authentifizierung. Falls eine Anmeldung nötig ist, führe `cf login` aus und lass mich den Browser-/OAuth-Flow abschließen. Gib API-Tokens, Secrets oder Zugangsdaten niemals aus und schreibe sie weder in Quelldateien noch in den Chat. 7. Führe zuerst `cf migrate --dry-run` aus. Fasse alle vorgesehenen Datei-, Abhängigkeits-, Skript- und Konfigurationsänderungen sowie alle Warnungen zusammen. Falls die Migration Blocker oder mehrdeutige Entscheidungen meldet, stoppe und frage mich, bevor du sie anwendest. 8. Wenn der Dry-Run sauber ist und keine Freigabe für destruktive oder entfernte Aktionen nötig ist, führe `cf migrate` aus. 9. Prüfe das vollständige Ergebnis mit `git status --short`, `git diff --stat` und `git diff`. Prüfe auch jede neue oder unversionierte Datei. 10. Führe `cf build` sowie die vorhandenen Tests, Typechecks, Lint- und Build-Befehle des Projekts aus, sofern vorhanden. 11. Prüfe, ob Cloudflare-Bindings, Routes, Compatibility-Einstellungen, Referenzen auf Umgebungsvariablen/Secrets, Package-Skripte und das lokale Entwicklungsverhalten weiterhin dem ursprünglichen Wrangler-Setup entsprechen. 12. Führe `cf deploy` nicht aus, lösche keine Cloudflare-Ressourcen und nimm keine anderen Änderungen an der Produktionsumgebung vor. 13. Beende die Arbeit mit einem knappen Bericht: Was wurde geändert, welche Validierungen waren erfolgreich, welche Warnungen oder Nacharbeiten bleiben offen und welche Dateien soll ich konkret prüfen? Arbeite bei sicheren lokalen Migrationsschritten selbstständig, stoppe aber vor destruktiven, irreversiblen, geheimnisbezogenen oder produktiven Aktionen.
Mein Fazit: gezielt ausprobieren, nicht überall gleichzeitig
Cloudflare sagt 18 Monate Wrangler-Wartung nach Ende der Beta zu, nicht ab Veröffentlichung. Es gibt keinen Grund, aus dieser Ankündigung eine hektische Migration aller funktionierenden Projekte zu machen.
Ich würde mit einem kleinen Worker beginnen und danach ein repräsentatives bestehendes Projekt auf einem Branch migrieren. Erzeugte Dateien prüfen. Das tatsächliche Verhalten testen. Änderungen an Produktion ausdrücklich freigeben.
Mich überzeugt die Richtung: Befehle, die sich finden lassen. Ergebnisse, die sich verarbeiten lassen. Änderungen, die sich nachvollziehen lassen.
Weniger Dashboard-Klicks. Weniger erratene Befehle. Mehr Kontrolle darüber, was wirklich passiert.
Ankündigung, Paketdokumentation und verlinkter Quellcode wurden am 29. September 2026 geprüft. Dies ist eine quellenbasierte Anleitung, kein eigener Deployment-Benchmark. Für den Artikel wurde kein Cloudflare-Konto angemeldet oder verändert.