Cloudflare ha messo in open beta una nuova CLI, cf, pensata per sviluppatori e agenti. Wrangler resta, ma il piano è chiaro: dopo la beta, una major finale che punta a cf, poi circa 18 mesi di manutenzione. Non è un rename: è un cambio di contratto con chi automatizza i deploy. Al 15/10/2026 il changelog di cf riporta solo l'avvio della beta, il 28 settembre: nessuna data di fine beta, nessuna nuova data di deprecazione. Cloudflare avverte che comandi, configurazione e Build Output possono ancora cambiare.
Cosa cambia davvero
Wrangler è stato addestrato nei modelli per anni. Se chiedi a un LLM di deployare su Cloudflare, ti propone wrangler.toml e comandi wrangler. Cloudflare lo sa: una CLI nuova evita di litigare con quel comportamento appreso e può scegliere default diversi senza rompere i tutorial già impressi nei modelli.
Nella pratica, cf punta a tre cose che Wrangler non aveva come priorità:
Output JSON di default, così un agente filtra senza parseare tabelle ASCII.
Command discovery strutturata, così un modello può esplorare migliaia di operazioni API senza indovinare i flag.
Config in TypeScript (cloudflare.config.ts) al posto di wrangler.toml o wrangler.jsonc: tipizzazione e LSP aiutano sia te sia l’agente che modifica il file.
Vite diventa l’ambiente di sviluppo di default. Non è solo gusto: allinea il percorso locale a quello che molti già usano sui frontend Workers. Per i progetti esistenti, però, cf migrate tiene il bundler di Wrangler, a meno che il progetto non usi già il plugin Vite. Migrare non ti obbliga ad adottare Vite.
Cosa conviene fare adesso
Se hai un progetto stabile su Wrangler, non migrare di corsa. La finestra è lunga e una CLI in open beta cambia ancora. Vale però aggiornare i runbook e i prompt degli agenti: quando generi comandi Cloudflare, cita esplicitamente se stai ancora su Wrangler o se stai sperimentando cf. Quando sarà il momento, la guida ufficiale alla migrazione parte da cf migrate --dry-run.
Nel frattempo puoi usare cf accanto a un progetto Wrangler, senza migrarlo. I comandi su account e risorse, come cf d1 list, funzionano in qualsiasi cartella. Non leggono però il file di Wrangler: l'account lo indichi con CLOUDFLARE_ACCOUNT_ID o lo scegli quando cf lo chiede. I dettagli sono nella pagina ufficiale cf per chi usa Wrangler.
Quello che non devi fare è lanciare cf dev, cf build o cf deploy in un progetto non ancora migrato, neanche da CI. Leggono solo cloudflare.config.ts. A seconda del progetto falliscono, oppure generano una configurazione che non c'entra con il tuo Worker e modificano package.json. Prima cf migrate, poi i comandi di progetto.
Anche dopo la migrazione, per ora, due cose restano a Wrangler. I log live: npx wrangler tail <WORKER_NAME>. Il singolo secret: npx wrangler secret put, oppure --secrets-file su cf deploy. E gli environment diventano mode: dove passavi --env ora passi --mode. Sono righe da scrivere nei runbook e nei prompt degli agenti (elenco ufficiale dei comandi non ancora coperti).
Se stai partendo da zero su Workers, D1 o R2, prova cf in parallelo su un repo di prova. Il test utile non è “deploya hello world”: è “lista le risorse, cambia un binding, leggi l’output JSON”. È lì che si vede se la CLI è davvero agent-friendly o solo un rebrand.
Per chi scrive tool per agenti
Qui torna il pezzo sui tool mal descritti: una CLI con discovery e JSON stabile riduce i fallimenti silenziosi. Se i tuoi agenti chiamano Cloudflare via shell, conviene trattare cf come API con schema, non come transcript da wrappare. Wrangler resta il ponte di migrazione; cf è il contratto verso cui spostare i tool nuovi.
Lo stesso vale per la Web Search API di Cloudflare: un contratto esplicito che l'agente chiama senza indovinare.
La domanda che conta
Non “Wrangler è morto?”. È: i tuoi script e i tuoi agenti dipendono dall’output umano di Wrangler, o da un contratto che puoi versionare? Se è il primo caso, hai debito. cf non lo cancella da solo, ma rende più costoso restare legati alle tabelle.
