Cloudflare cf: el CLI que reemplaza a Wrangler

Si has trabajado con Cloudflare Workers, conoces Wrangler. Es el CLI que usas para wrangler dev, wrangler deploy y poco más. El problema es que Cloudflare tiene más de 100 productos y casi 3.000 operaciones en su API HTTP, y Wrangler solo cubre una fracción. ¿Necesitas gestionar DNS desde la terminal? Vuelve al dashboard. ¿Configurar un WAF rule? Lo mismo. La solución hasta ahora era la API REST, Terraform o el SDK.

Eso está cambiando. Cloudflare acaba de anunciar cf, un nuevo CLI diseñado para cubrir toda la plataforma, y Local Explorer, una herramienta para inspeccionar los recursos locales de tu Worker durante el desarrollo. Ambos forman parte de lo que Cloudflare llama “Agents Week”, y son una señal clara de hacia dónde va la plataforma.

cf: un CLI para gobernarlos a todos

El nuevo CLI se instala como un paquete npm independiente:

# Probar sin instalar
npx cf

# O instalar globalmente
npm install -g cf

La versión actual en npm es 0.0.5, así que está en technical preview muy temprana. Por ahora solo cubre un subconjunto de productos, pero Cloudflare ya está probando internamente una versión que soporta la totalidad de su superficie API.

Los comandos disponibles hoy son:

# Autenticación
cf auth login       # Login con OAuth
cf auth whoami      # ¿Quién soy?
cf auth logout      # Cerrar sesión

# Gestión de DNS
cf dns records list --zone midominio.com
cf dns records create --zone midominio.com --type A --name api --content "1.2.3.4"

# Zonas
cf zones list
cf zones create --name nuevo-dominio.com --type full

# Cuentas
cf accounts list
cf accounts members list

La idea es que cada producto de Cloudflare tenga sus comandos equivalentes. Workers, D1, R2, KV, Pages, WAF, DNS, Registrar, etc. Todo desde el mismo binario.

Consistencia impuesta por schema: adiós al caos

Uno de los problemas de Wrangler es que los comandos crecieron de forma orgánica. Algunos usaban info, otros get, otros list. Las flags eran inconsistentes: --format en un sitio, --json en otro. Para un humano es molesto; para un agente de IA que genera comandos, es un desastre.

Cloudflare ha creado un sistema de schemas en TypeScript que definen no solo la API REST, sino también los comandos CLI, los argumentos, la configuración en wrangler.jsonc y los bindings de Workers. Todo se genera a partir del mismo schema.

Y con eso vienen reglas estrictas:

Siempre get, nunca info
Siempre --force, nunca --skip-confirmations
Siempre --json, nunca --format
Siempre disponibles en todos los comandos

// Nota: este ejemplo es ilustrativo y no proviene del código fuente real de Cloudflare.
// Ejemplo simplificado de cómo se define un comando en el schema
export default {
  name: "dns.records.create",
  description: "Crea un registro DNS en una zona",
  args: {
    zone: { type: "string", required: true, description: "Nombre de la zona" },
    type: { type: "string", required: true, description: "Tipo de registro (A, AAAA, CNAME...)" },
    name: { type: "string", required: true, description: "Nombre del registro" },
    content: { type: "string", required: true, description: "Contenido/valor del registro" },
    ttl: { type: "number", default: 1, description: "TTL en segundos (1 = auto)" },
    proxied: { type: "boolean", default: false, description: "¿Proxy de Cloudflare?" },
  },
  output: {
    json: true, // Siempre disponible
  },
} satisfies CommandSchema;

Este enfoque tiene una ventaja enorme: cuando sale un producto nuevo en Cloudflare, el CLI se genera automáticamente a partir del schema. No hay que escribir código a mano para cada comando.

Local Explorer: el dashboard que te faltaba en local

El segundo anuncio es Local Explorer, una interfaz web local que te permite inspeccionar todos los recursos simulados de tu Worker durante el desarrollo: KV, R2, D1, Durable Objects y Workflows.

Hasta ahora, si querías ver qué había en tu D1 local, tenías que explorar manualmente el directorio .wrangler/state o instalar herramientas de terceros. Con Local Explorer:

# Al hacer wrangler dev, ves un prompt:
# ▸ Press e to open Local Explorer
wrangler dev
# Pulsas 'e' y se abre http://localhost:XXXX en tu navegador

Y lo más interesante para los agentes: la API local está disponible en /cdn-cgi/explorer/api con una especificación OpenAPI. Esto significa que un agente de IA puede apuntar a esa URL y entender qué recursos tiene disponibles, qué datos hay en cada uno y modificarlos con las mismas llamadas API que usaría en producción.

# Un agente puede descubrir los recursos locales vía OpenAPI
curl http://localhost:8787/cdn-cgi/explorer/api/openapi.json

# Y luego consultar o modificar datos locales
curl -X DELETE "http://localhost:8787/cdn-cgi/explorer/api/d1/main-db/query" \
  -d '{"sql": "DELETE FROM sessions WHERE expires_at < datetime(\"now\")"}'

La ventaja es que la API local refleja la API remota. Lo que funciona en local funciona en producción, y viceversa. No hay sorpresas al hacer deploy.

¿Qué significa para Wrangler?

Cloudflare es claro: cf es el futuro de Wrangler, pero Wrangler no va a desaparecer mañana. Primero van a juntar lo mejor de Wrangler actual con las nuevas capacidades de cf, y el resultado será el CLI final. Si tienes scripts que usan wrangler deploy, van a seguir funcionando durante bastante tiempo.

Lo que sí va a cambiar es el modelo mental. En lugar de pensar en “Wrangler = Workers”, piensa en “cf = toda la plataforma”. Y eso tiene todo el sentido cuando tu stack vive en Cloudflare: Workers, D1, R2, KV, WAF, DNS, Pages… todo se gestiona desde el mismo lugar.

Mi opinión

Me parece un movimiento inteligente y necesario. Wrangler era una herramienta de su época: servía para desarrollar Workers y poco más. Pero Cloudflare ha evolucionado de “CDN con Workers” a plataforma completa, y el CLI se había quedado atrás.

Lo que más me gusta es el enfoque de schemas como fuente de verdad. Generar el CLI, el SDK, el provider de Terraform y el MCP server desde el mismo schema elimina un montón de inconsistencias. Y las reglas estrictas de naming (get no info, --json no --format) suenan simples, pero marcan una diferencia enorme cuando escribes scripts o cuando un agente genera comandos.

Lo que me genera dudas es el nombre. cf es corto y fácil de teclear, pero en el ecosistema ya hay otros cf. En distribuciones Linux, cf suele ser el binario de Cloud Foundry CLI. Si tienes ambos instalados, vas a tener conflictos. Veremos si Cloudflare mantiene el nombre o si eventualmente lo integran de vuelta en wrangler con un alias.

Local Explorer me parece el complemento perfecto. Poder inspeccionar D1, KV y R2 sin salir de la terminal es algo que echaba en falta cada vez que desarrollaba con Workers. Y que los agentes de IA puedan usar la misma API para gestionar recursos locales es un detalle que muestra que Cloudflare está pensando seriamente en el desarrollo asistido por IA.

¿Vale la pena probarlo hoy? Sí, para jugar y dar feedback. Pero producción, esperaría a que madure un poco más. Es un 0.0.5 al fin y al cabo.