Einführung von cf: die agentenbasierte CLI für die gesamte Cloudflare API

Im vergangenen Jahr ist die Nutzung von Wrangler durch Agents sprunghaft angestiegen.

Im März 2026 entfiel bereits ein Viertel der Wrangler-Nutzung auf Agents. Ein Jahr zuvor hatte ihr Anteil noch im einstelligen Prozentbereich gelegen. Vergangene Woche erreichte er 48 %. 

Agents nutzen Wrangler intensiver als Menschen: Pro Tag verwenden sie fast doppelt so viele unterschiedliche Befehle. Zudem ist die Wahrscheinlichkeit, dass sie mindestens sechs Befehle verwenden, fast viermal so hoch.

Agents arbeiten gern mit Kommandozeilenwerkzeugen. Doch Wrangler unterstützt nur rund 280 Operationen, während Cloudflare Tausende anbietet. 

Zu Beginn des Jahres haben wir angedeutet, wie wir dieses Problem lösen wollten – und heute stellen wir cf vor: eine neue CLI, mit der Agents auf sämtliche Cloudflare-Produkte zugreifen können.

cf ist als CLI für die nächste Generation der Softwareentwicklung ausgelegt:

• Eine speziell auf Agents abgestimmte Suche und gezielte Hinweise helfen ihnen, den passenden Befehl für ihre Aufgabe zu finden.
• JSON ist das standardmäßige Ausgabeformat. Für Menschen werden die Ergebnisse übersichtlich formatiert, für Agents kompakt ausgegeben, damit sie möglichst wenig Platz im Kontextfenster beanspruchen.
• Mit cloudflare.config.ts führen wir ein neues Konfigurationsformat ein, das künftig ganz Cloudflare abdecken soll. Den Anfang machen Workers. Das Format bietet die Typsicherheit von TypeScript und unterstützt Sie und Ihren Agents über das Language Server Protocol (LSP) mit präzisen Hinweisen und Vorschlägen.
• Vite wird zum Standard. Damit stehen Ihnen ein erstklassiger lokaler Entwicklungsserver und zahlreiche Plugins für die Entwicklung von Anwendungen und Frameworks zur Verfügung.

Installieren Sie noch heute die offene Beta global und führen Sie sie von überall aus:

npm i -g cf

cf gibt Ihrem Agent Zugriff auf die gesamte Cloudflare-API

Was wäre, wenn Ihr Agent alle Möglichkeiten von Cloudflare nutzen könnte? Diese Frage hat uns Anfang des Jahres beschäftigt: Agents wurden immer leistungsfähiger, doch ihre Möglichkeiten mit der Cloudflare-CLI blieben begrenzt.

Die Befehle von Wrangler wurden einzeln implementiert. Dabei verfolgte jedes Produktteam einen eigenen Ansatz für ihre Gestaltung und Bedienung. Einheitliche Konventionen über alle Teams hinweg durchzusetzen, war selbst bei unseren rund 280 Befehlsvarianten nahezu unmöglich. Ähnliche Befehle waren unterschiedlich benannt, etwa d1 info, hyperdrive getund workflows describe, weil jedes Team zu unterschiedlichen Zeitpunkten eigene Konventionen entwickelt hatte. Manche Teams schrieben Tausende von Codezeilen für maßgeschneiderte Funktionen, die später kaum genutzt wurden . Gleichzeitig  entwickelten Teams unterschiedliche Ansätze zur Lösung derselben Probleme.

Wir wollten die bestehenden Befehle vereinheitlichen und den Funktionsumfang erheblich erweitern – und zwar in einem Schritt. Möglich wurde das durch Forge, Cloudflares neue einheitliche Pipeline zur API-Generierung. Die Idee dahinter: Wir erzeugen die CLI-Befehle direkt aus demselben API-Schema, das auch unserer API-Dokumentation und der Generierung unserer SDKs zugrunde liegt. Alle unsere API-Funktionen sind durch ein OpenAPI-Schema beschrieben. Wenn wir dieses um einige zusätzliche Angaben ergänzen, können Forge daraus eine CLI erzeugen.

Damit kann cf sämtliche mehr als 3.000 Operationen der Cloudflare-API abdecken – weit mehr als die rund 280 Funktionen, die Wrangler im Laufe der Zeit erhalten hat.

Jetzt ist es ganz einfach, Ihrem Agent cf zu geben und ihn zu bitten, einen Worker einzurichten, ihn bereitzustellen, ihn zu überwachen, ihn mit Cloudflare Access zu schützen, eine Domain zu kaufen und sie mit Cloudflare WAF abzusichern – alles mit einem einzigen Tool.

Für einen Agent entwickeln, der cf noch nie verwendet hat

cf ist auf die Zukunft der Softwareentwicklung ausgerichtet. Agents verändern grundlegend, wie Software entwickelt und bereitgestellt wird. Dieses Jahr haben wir uns darauf konzentriert, Werkzeuge zu entwickeln, die diesen Wandel unterstützen. cf bündelt diese Arbeit. Die CLI wurde von Grund auf für die Nutzung durch Agents entwickelt und bietet neue Funktionen, mit denen sie selbstständig passende Befehle finden können. Wir erwarten, dass solche Funktionen schon bald auch in anderen CLIs zum Standard gehören werden.

Wrangler hatte einen Vorteil: Über Jahre veröffentlichte Dokumentation, Blogbeiträge und Anleitungen von Drittanbietern sind in das Training großer Sprachmodelle eingeflossen. Doch dieser Vorteil hat auch eine Kehrseite. Wenn wir die Funktionsweise von Wrangler ändern, widerspricht das häufig den Nutzungsmustern, die diese Modelle bereits gelernt haben. Angesichts der umfangreichen Verbesserungen, die wir vorhaben, wären tiefgreifende Änderungen jedoch unvermeidlich gewesen.

Eine neue CLI einzuführen, die Agents noch nicht kennen, klingt zunächst nach einem einschneidenden Wechsel. Tatsächlich ist es die sauberste Lösung. Wir können cf gezielt gestalten und den Agenten zusätzliche Informationen im Kontext sowie Hinweise über AGENTS.md-Dateien bereitstellen. Das macht den Umstieg weniger verwirrend, als wenn ein Agent die erheblichen Unterschiede zwischen zwei Versionen eines vertrauten Tools erkennen und berücksichtigen müsste. Zum Start sind bereits einige dieser speziell für Agents entwickelten Funktionen enthalten. Weitere werden folgen.

Agents müssen JSON filtern, keine Tabellen lesen

Wenn Agents Wrangler verwenden, hängen sie --json an jeden Befehl an und filtern die Ausgabe oft mit jq, um eine Teilmenge der Felder zu extrahieren. Allerdings unterstützten bisher nur einige Wrangler-Befehle die Option --json. Viele lieferten stattdessen Unicode-Tabellen, die für Menschen gedacht waren, die Ergebnisse direkt im Terminal lesen. Agents können solche Tabellen zwar auswerten, benötigen dafür aber mehr Zeit und Tokens als ein jq-Filter.

Bei cf gehen wir deshalb anders vor: Agents brauchen JSON. Wenn sie künftig die Hauptnutzer dieses Werkzeugs sind, sollte JSON auch das Standardformat sein. Für die große Mehrheit der Befehle, die Menschen nur selten direkt aufrufen werden, ist das die naheliegende Lösung.

Als Mensch nutzen Sie diese CLI häufig indirekt über einen Agent. Sinnvoller ist es deshalb, wenn der Agent die Ergebnisse einfach filtern und im gewünschten Format für Sie aufbereiten kann. Tabellen, die Sie wahrscheinlich ohnehin nie direkt lesen würden, helfen dabei wenig.

Doch was ist, wenn eine Aufgabe Ihre eigenen Angaben oder Entscheidungen erfordert – etwa die Suche nach einer Domain, die Sie kaufen möchten?

Wo Ihr Agent eine lange Liste benannter Parameter übergeben muss, können Sie stattdessen einfach ein Formular ausfüllen. cf übersetzt die Anforderungen der API in einzelne Eingabefelder und prüft die eingegebenen Werte. So werden Sie auch bei Domains mit komplexeren Anforderungen Schritt für Schritt durch den Kauf geführt.

Oder Sie überlassen auch diese Aufgabe einfach Ihrem Agent.

Ihr Agent findet den passenden Befehl selbst

Bei rund 3.000 verfügbaren Operationen stellt sich eine Frage: Wie findet Ihr Agent schnell den passenden Befehl, ohne das Kontextfenster mit unnötigen Informationen zu füllen? Dafür haben wir cf cli search eingeführt.

Mit diesem Befehl kann Ihr Agent in natürlicher Sprache beschreiben, was er erledigen möchte. Ein kompakter Suchindex liefert daraufhin passende Befehle anhand ihrer API-Beschreibungen und Parameter. Sobald der Agent erstmals die Hilfe mit --help aufruft, weisen wir ihn automatisch auf diese Suchfunktion hin.

Konfiguration, die Typprüfungen für Ihren Agent durchführt

Unser neues Konfigurationsformat basiert auf TypeScript. Es ist für Menschen und Agents leicht zu lesen und ermöglicht es Ihnen, Ihre Konfiguration mithilfe von Code zu erzeugen.

Typinformationen sind für Agents besonders hilfreich. Unsere Erfahrungen zeigen, dass sie die Konfiguration auch ohne Vorkenntnisse des neuen Formats problemlos finden und bei Bedarf bearbeiten können. Das gilt selbst für Elemente wie env, deren Funktionsweise sich deutlich vom gleichnamigen Element in Wrangler unterscheidet. Agents mit LSP-Unterstützung, etwa Claude Code und Codex, können die Struktur und die Typinformationen der Konfiguration besser auswerten. Dadurch machen sie wesentlich präzisere Vorschläge.

Bei TOML stand dagegen kein zugängliches Schema zur Verfügung. JSONC hatte zwar ein verknüpftes Schema, doch Agents nutzten es nur selten.

Einige interne Wrangler-Konfigurationen mit mehr als 5.000 Zeilen konnten wir um 40 % verkürzen. Sie enthielten zahlreiche individuell angepasste Entwicklungsumgebungen. Statt diese einzeln festzulegen, erzeugen nun Factory-Dateien die Konfiguration für die jeweiligen Entwicklerinnen und Entwickler.

Dazu wird jede Umgebung auf Grundlage einer gemeinsamen Basiskonfiguration erzeugt. Das Kopieren von env-Blöcken, wie es bei Wrangler üblich war, entfällt.  Ein einfacher Worker mit mehreren Umgebungen wechselt einfach über das Vite-native Modus-Argument zwischen einem Konfigurationssatz und einem anderen.

Eine einfache Konfiguration dafür sieht so aus:

import { bindings, defineConfig } from "cf/config";
import * as entrypoint from "./index.js" with { type: "cf-worker" };

export default defineConfig(({ mode }) => ({
  worker: {
    name: "example-worker", 
      entrypoint,
      compatibilityDate: "2026-09-27",
      env: {
        Environment: bindings.text(`This is ${mode} environment`),
      },
    },
}));

Mit cf migrate können Sie Ihren Cloudflare Worker auf das neue Konfigurationsformat umstellen.

Außerdem stellen wir einige Hilfsfunktionen bereit, die Ihnen die Entwicklung Ihres Workers erleichtern.

Mit bindings findet Ihr KI-Agent an einer zentralen Stelle alle Möglichkeiten der Entwicklerplattform. Ihr Editor kann die verfügbaren Optionen automatisch vervollständigen und erläutern – von Umgebungsvariablen über Speicher und Datenbanken bis hin zu Warteschlangen

import { bindings, defineConfig } from "cf/config";

export default defineConfig(({ mode }) => ({
  worker: {
    // ...
    env: {
      API_URL: bindings.text(
        mode === "production"
          ? "https://example.com"
          : "https://staging.example.com",
      ),
      API_TOKEN: bindings.secret(),
      CACHE: bindings.kv({
        id: mode === "production"
          ? "production-namespace-id"
          : "staging-namespace-id",
      }),
      DATABASE: bindings.d1({ name: `example-${mode}-database` }),
      UPLOADS: bindings.r2({ name: `example-${mode}-uploads` }),
      JOBS: bindings.queue < { userId: string } > ({
        name: `example-${mode}-jobs`,
      }),
      AI: bindings.ai(),
      SEARCH_INDEX: bindings.vectorize({
        name: `example-${mode}-search`,
      }),
      API: bindings.worker({ worker: `example-${mode}-api` }),
    },
  },
}));

Außerdem haben wir eine Hilfsfunktion für triggers ergänzt. Damit definieren Sie Routen, Warteschlangen, Zeitpläne und E-Mail-Auslöser für Ihren Worker. Diese Angaben sind nicht mehr über die Konfigurationsdatei verteilt. Stattdessen sehen Sie in einem einzigen Block, welche Ereignisse die Ausführung Ihres Workers auslösen können.

import { defineConfig, triggers } from "cf/config";

export default defineConfig({
  worker: {
    // ...
    triggers: [
      triggers.fetch({ pattern: "example.com/*" }),
      triggers.scheduled({ schedule: "0 * * * *" }),
      triggers.queue({ name: "jobs", maxBatchSize: 10 }),
      triggers.email({ addresses: ["support@example.com"] }),
    ],
  },
});

defineConfig.worker ist dabei erst der Anfang. Unser Ziel ist es, dass Sie mit cloudflare.config.ts künftig Ihre gesamte Cloudflare-Konfiguration verwalten können. Jedes benötigte Produkt soll sich über eine typsichere Konfiguration einrichten lassen, während seine API Ihrem KI-Agenten über cf zur Verfügung steht. Schon bald können Sie über diese Konfigurationsdatei auch vollständige Richtlinien konfigurieren, Zonen einrichten, DNS-Einstellungen verwalten und vieles mehr.

Eine erstklassige Entwicklererfahrung

Als Wrangler erstmals Builds für JavaScript-Workers unterstützte, gab es Vite noch nicht. Deshalb nutzten wir esbuild, um Ihre Workers zu bündeln. Auch der Entwicklungsserver auf Port 8787 wurde vom Wrangler-Team selbst entwickelt. Änderungen daran erforderten Eingriffe in die internen Abläufe lokaler Cloudflare-Werkzeuge wie Miniflare.

Vite verbessert diesen Ansatz erheblich. Es bietet ein großes Plugin-Ökosystem und einen erstklassigen Entwicklungsserver mit Hot Module Replacement (HMR). Für Builds nutzt es die Rust-basierte Bibliothek Rolldown, die nicht benötigten Code durch Tree-Shaking entfernt. Alles, was mit Vite möglich ist, können Sie auch mit dem Cloudflare Vite Plugin umsetzen.

Wir empfehlen das Cloudflare Vite Plugin für die Entwicklung von Workers – unabhängig davon, ob Sie ein Frontend-Projekt oder eine Backend-API entwickeln. Zusammen mit unserem Vitest-Plugin bietet es eine einheitliche Entwicklungs- und Testumgebung, die der Laufzeitumgebung von Cloudflare Workers entspricht. Dabei haben Sie direkten Zugriff auf Bindings und Plattform-APIs.

cf nutzt standardmäßig Vite. Die meisten Ihrer Workers lassen sich mithilfe von Agents leicht migrieren. Bei anderen kann die Umstellung mehr Zeit benötigen. Deshalb greift cf für die lokale Entwicklung und Bereitstellung weiterhin auf Wrangler zurück, wenn JavaScript-Workers noch esbuild benötigen. Das gilt auch für Rust- und Python-Workers.

Von Wrangler zu cf migrieren

Um einen Worker von Wrangler zu cf zu migrieren, führen Sie einfach cf migrate aus.

cf migrate

Bei Workers, die bereits Vite nutzen, wird die Konfiguration automatisch in das Format cloudflare.config.ts überführt. Wenn Ihr Worker für die Nutzung von esbuild auf Wrangler angewiesen ist, übernimmt Wrangler weiterhin die Builds.

Nach dem Ende der öffentlichen Beta veröffentlichen wir eine letzte Hauptversion von Wrangler, die Sie und Ihren Agents auf die Nutzung von cf verweist. Anschließend werden wir Wrangler noch 18 Monate lang warten, damit Sie genügend Zeit für die Migration haben.

Auch neue Projekte können Sie mit cf init beziehungsweise cf deploy automatisch für Cloudflare konfigurieren. Dabei wird das Cloudflare Vite Plugin installiert und eine Konfigurationsdatei erstellt.

Für die Bereitstellung statischer Websites benötigen Sie weiterhin keine Konfigurationsdatei. Führen Sie dazu einfach cf deploy in Ihrem Projektverzeichnis aus.

Ein neues Hello-World-Projekt erstellen Sie mit cf init.

cf ist Open Source. Probleme können Sie in unserem GitHub-Repository melden.