Durante mucho tiempo, mi reflejo para publicar cualquier cosa web era bastante automático: repo, Vercel, dominio y a correr. Y ojo, sigo pensando que Vercel tiene una de las mejores experiencias de despliegue que se han hecho para frontend. Importas un proyecto, detecta el framework, te monta previews por rama y en cinco minutos tienes algo online.

Pero cuanto más he ido moviendo piezas pequeñas, APIs, redirects, tareas programadas y sitios estáticos con algo de lógica, más claro tengo que Cloudflare Workers juega en otra liga distinta. No digo “mejor para todo”, porque eso casi nunca existe. Digo que para muchísimos proyectos modernos me parece una mezcla muy difícil de superar: barato, rápido, global y con un ecosistema de bindings que encaja muy bien con cómo construyo hoy.

Lo que me gusta de Workers

La idea base es muy simple: escribes una función que vive cerca del usuario, en la red de Cloudflare, y responde sin que tengas que pensar demasiado en servidores. Eso ya suena bien, pero la gracia real aparece cuando empiezas a juntar piezas: Workers Static Assets para servir una web, R2 para ficheros, KV para datos sencillos, Durable Objects para estado coordinado, Queues para trabajo en segundo plano, Cron Triggers para tareas programadas y D1 si quieres SQLite gestionado.

A mí eso me cambia bastante la cabeza. En vez de pensar “necesito un backend”, muchas veces pienso “necesito un Worker pequeño con dos bindings”. Para webhooks, APIs internas, endpoints de RSS, tareas de build o herramientas personales, ese modelo es muy cómodo.

Y luego está el precio, que es donde Cloudflare se vuelve especialmente interesante. A día de hoy, el plan gratuito de Workers incluye 100.000 peticiones al día. El plan de pago parte de 5 USD al mes por cuenta e incluye 10 millones de peticiones mensuales y 30 millones de milisegundos de CPU. A partir de ahí, el exceso se cobra a 0,30 USD por millón de peticiones y 0,02 USD por millón de milisegundos de CPU. Además, Cloudflare no cobra aparte por transferencia de datos de Workers. Para proyectos pequeños o medianos, eso es una tranquilidad enorme.

Comparado con Vercel

Vercel sigue siendo comodísimo, sobre todo si trabajas con Next.js y quieres previews, integración perfecta con el framework y una experiencia muy pulida para equipos. No lo vendería como “malo”, porque sería injusto. De hecho, si mañana montase un SaaS muy centrado en Next.js App Router y quisiera ir rápido con un equipo, Vercel seguiría en mi lista.

La diferencia está en el modelo mental y en el modelo de facturación. Vercel Pro cuesta 20 USD por usuario al mes e incluye crédito de uso, pero luego entran más dimensiones: invocaciones de funciones, CPU activa, memoria provisionada, transferencia, edge requests, image optimization y demás. Tiene controles de gasto, sí, pero el coste deja de ser tan fácil de estimar cuando el proyecto empieza a moverse.

En Cloudflare Workers, en cambio, siento que el coste inicial es más predecible. No me obliga a pensar en asientos por desarrollador para algo que muchas veces soy solo yo manteniendo una herramienta. Y si el proyecto crece, el precio por millón de peticiones sigue siendo muy razonable.

Las pegas, porque también las tiene

Workers no es Node “tal cual”. Ha mejorado muchísimo, pero sigues estando en un runtime con sus propias reglas. Hay límites de memoria, límites de tamaño de bundle y ciertos paquetes del ecosistema Node que no encajan sin cambios. Si tu app depende de binarios nativos, APIs raras de Node o librerías muy pensadas para servidor clásico, puede que te pegues con el entorno.

También hay que acostumbrarse a wrangler, a los bindings y a la forma de depurar. En local funciona bien, pero no tiene esa sensación ultra redonda de “importo en Vercel y listo” para todos los frameworks. Y para Next.js completo, con todas sus particularidades, Vercel sigue teniendo una ventaja obvia: juegan en casa.

Otra cosa importante: Workers factura CPU activa, no tiempo de espera tradicional. Eso es buenísimo para muchas APIs que hacen I/O, pero no significa que sea el sitio ideal para trabajos pesados de CPU, procesado grande o cosas que quieren memoria a lo bestia. Para eso hay que elegir otra pieza.

Dónde lo usaría sin pensarlo demasiado

Lo usaría para APIs pequeñas, webhooks, sitios estáticos con algo de SSR, redirects inteligentes, proxies ligeros, tareas programadas, herramientas internas, endpoints para bots, feeds RSS, validadores, mini dashboards y proyectos personales que quiero mantener baratos durante años.

También me gusta mucho para productos que empiezan pequeños. Esa fase en la que no sabes si algo va a tener 200 visitas o 200.000 es justo donde una plataforma barata y global te evita muchas decisiones prematuras.

Mi resumen sincero

Cloudflare Workers me gusta porque no me hace sentir que estoy montando infraestructura para cada idea. Es más bien una libreta rápida para publicar lógica cerca del usuario. Vercel me sigue pareciendo superior cuando el proyecto es muy Next.js, muy de equipo y muy de frontend productivo. Pero para herramientas pequeñas, APIs y sitios con poco backend, Workers me parece ahora mismo una de las mejores compras del mundo dev.

Y lo mejor es que no tienes que casarte con una plataforma. Puedes tener el frontend donde te dé mejor DX y mover piezas concretas a Workers cuando tenga sentido. En mi caso, cada vez que hago eso, acabo preguntándome por qué no lo había hecho antes.

Fuentes que he revisado