Cloudflare lanzó cf el 28 de septiembre de 2026, su nuevo CLI en beta abierta: una sola herramienta para más de 3000 operaciones de la API que reemplazará a Wrangler. Puedes migrar un Worker hoy con cf migrate, salvo que esté escrito en Python o Rust: esos siguen pasando por Wrangler.
Aquí tienes qué cambia con cf, cómo instalarlo sin sorpresas y qué se queda en Wrangler por ahora.
¿Qué es cf, el nuevo CLI de Cloudflare?
cf es la nueva herramienta de línea de comandos de Cloudflare, generada directamente a partir del esquema OpenAPI de la API de Cloudflare. Wrangler acumuló con los años unos 280 comandos hechos a mano; cf cubre toda la API, más de 3000 operaciones: Workers, DNS, WAF, Access, registro de dominios y todo lo demás, desde un solo binario.
El motivo declarado son los agentes. Según Cloudflare, en marzo de 2026 los agentes ya generaban una cuarta parte del uso de Wrangler, y la semana anterior al lanzamiento llegaron al 48%. Son cifras de la propia Cloudflare. El diseño del CLI parte de ahí:
- JSON es la salida por defecto. Formateado para personas y compactado para agentes, listo para pasar por
jqsin flag--jsony sin tablas Unicode que parsear. cf cli searchrecibe una descripción en lenguaje natural de lo que quieres hacer y devuelve los comandos que encajan, a partir de la descripción y los parámetros de cada operación de la API. Cloudflare dice que los agentes se enteran de este comando automáticamente la primera vez que ejecutan--help.- Configuración tipada.
cloudflare.config.tsreemplaza awrangler.toml/wrangler.jsonc, así que el language server de tu editor (y cualquier agente que lo use, como Claude Code o Codex) puede validar la configuración mientras la escribes. - Vite es el build y el servidor de desarrollo por defecto. El Cloudflare Vite Plugin sustituye al bundling con esbuild propio de Wrangler y a su servidor de desarrollo en
:8787.
Los comandos generados siguen el patrón cf <product> [group…] <operation>. Si buscas documentación en inglés, los términos que vas a encontrar son cloudflare cf cli y wrangler migration.
¿Cómo se instala el CLI de Cloudflare?
Se instala de forma global desde npm:
npm i -g cf
Necesita Node.js 22 o superior. Después, autentícate y explora:
cf auth login # Authenticate with Cloudflare
cf --help # Browse all commands
cf <command> --help # Per-command help
cf complete bash >> ~/.bashrc # Install shell completions
En CI, o en cualquier entorno donde un login en el navegador no tenga sentido, cf lee primero la variable de entorno CLOUDFLARE_API_TOKEN, antes que cualquier perfil OAuth guardado.
¿Choca con otras herramientas que se llaman cf?
Puede pasar. El CLI de Cloud Foundry también se llama cf, y fue una de las primeras cosas que salieron en el hilo de Hacker News del lanzamiento. El paquete de npm instala el mismo binario con un segundo nombre, cloudflare, así que puedes usar ese si cf ya está ocupado en tu máquina.
Una nota sobre el nombre del paquete: en 2013, cf en npm era un paquete de configuración sin relación con Cloudflare (versiones 0.0.1 a 0.0.3). Cloudflare publica bajo ese nombre desde la versión 0.0.4, en abril de 2026. Si quieres comprobarlo antes de instalar, npm view cf debería mostrar description: 'The Cloudflare CLI' y el repositorio github.com/cloudflare/cf.
¿Cómo migrar de Wrangler a cf?
Desde el directorio del proyecto de tu Worker, ejecuta:
cf migrate
Lo que pasa después depende de cómo se construye hoy tu Worker, según el anuncio de Cloudflare:
- Los Workers que ya compilan con Vite se convierten a
cloudflare.config.tsautomáticamente. - Los Workers que dependen de Wrangler para el bundling con esbuild siguen funcionando:
cfle delega esos builds a Wrangler.
A partir de ahí, los comandos del día a día son:
cf dev
cf build
cf deploy
cf deploy compila por defecto y después sube el resultado. Pasa --prebuilt para reutilizar un build existente. Si quieres subir una versión sin desplegarla, usa cf workers versions create. cf workers triggers deploy aplica las rutas y los cron configurados.
Para trabajar con datos en local, añade --local a un comando compatible y se ejecutará contra una instancia local y temporal de Miniflare, no contra tu cuenta de producción. Eso cubre, entre otras, operaciones de KV, D1 y R2. Los comandos sin equivalente local devuelven un error en vez de ir a producción.
¿Y si empiezas un proyecto nuevo?
cf init my-worker crea un Worker de ejemplo con cloudflare.config.ts, vite.config.ts, src/index.ts, tsconfig.json y package.json. Si ejecutas cf init en un directorio que ya tiene archivos, configura el proyecto existente.
cf init my-worker
cd my-worker
cf dev
Los sitios estáticos siguen sin necesitar archivo de configuración: basta con cf deploy en el directorio del proyecto.
¿Qué es cloudflare.config.ts y en qué se diferencia de wrangler.toml?
Es un archivo TypeScript que exporta una llamada a defineConfig. Este es el ejemplo mínimo de Cloudflare: un Worker cuya configuración cambia según el mode de Vite.
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`),
},
},
}));
El cambio principal frente a Wrangler está en los entornos. En wrangler.toml o wrangler.jsonc lo habitual era copiar un bloque env por cada entorno. Aquí cada entorno se construye en código a partir de una misma base. Cloudflare dice que algunas de sus configuraciones internas de Wrangler, de más de 5000 líneas, se redujeron un 40% así. También es una cifra de la propia Cloudflare.
Dos helpers hacen casi todo el trabajo. bindings expone variables de entorno, secretos, KV, D1, R2, colas, IA, Vectorize y service bindings con autocompletado en el editor. triggers reúne en un solo bloque todo lo que puede invocar al Worker:
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"] }),
],
},
});
Cloudflare dice que el mismo archivo acabará cubriendo también zonas, DNS y políticas. Por ahora empieza por los Workers.
¿Los Cloudflare Workers en Python funcionan con cf?
Todavía no del todo: según el anuncio, cf sigue delegando el desarrollo y el despliegue en Wrangler para tres tipos de Worker:
- Workers en JavaScript que todavía compilan con esbuild en lugar de Vite
- Workers en Python
- Workers en Rust
Si seguiste nuestra guía para desplegar FastAPI en Cloudflare Workers, tu proyecto está en el segundo grupo. Puedes instalar cf y usarlo para todo lo demás en tu cuenta, pero el Worker en sí se sigue compilando y desplegando con Wrangler, así que no lo desinstales.
¿Wrangler va a dejar de funcionar?
No hay fecha todavía. Lo que Cloudflare se compromete a hacer es publicar, cuando termine la beta abierta, una última versión mayor de Wrangler que te dirija a ti y a tu agente hacia cf. A partir del fin de la beta, Wrangler seguirá recibiendo mantenimiento durante 18 meses.
Al momento de publicar esta nota (29 de septiembre de 2026), Cloudflare no había anunciado cuándo termina la beta, así que ese plazo de 18 meses todavía no ha empezado a correr.
¿cf o Wrangler? ¿Conviene migrar ya?
Depende de lo que tengas en producción. Al momento de publicar esta nota, cf está en la versión 1.0.0-beta.5, y su documentación oficial todavía es un pull request abierto y sin mergear en el repositorio cloudflare-docs (#33735). Ese PR advierte que algunas páginas describen el comportamiento de la próxima versión de cf, así que revisa el --help del comando antes de fiarte de una página de la documentación.
Un reparto razonable por ahora:
- Úsalo ya para explorar y operar tu cuenta (DNS, WAF, Access, todo lo que Wrangler nunca cubrió), sobre todo desde un agente. En el trabajo de consulta es donde
cf cli searchy la salida en JSON rinden desde el primer día. - Migra los Workers en JavaScript que usan Vite en una rama con
cf migrate, y revisa elcloudflare.config.tsgenerado antes de hacer merge. - Deja los Workers en Python, en Rust y los que usan esbuild en Wrangler, porque
cfse los devolvería a Wrangler de todos modos.
El código es open source bajo MIT o Apache-2.0 en github.com/cloudflare/cf, que es donde se reportan los problemas durante la beta.
Si usas Cloudflare con agentes, quizás también te interese cómo auditar la seguridad de tu código con el skill que liberó Cloudflare y cómo Browser Run convierte un Chrome headless en un endpoint HTTP.