Un sitio personal en Cloudflare Workers sin servidor de origen, sin framework, y sin base de datos en el sentido tradicional. KV para contenido, R2 para imágenes, D1 para conteos de vistas, Workers AI para resúmenes y traducciones.
Llevo aproximadamente un año corriendo este setup. Esto es lo que le diría a quien empieza.
Lo Que Funciona Notablemente Bien
Tiempo de despliegue. Hacer push a main y ver los cambios en vivo en 30 segundos es el baseline correcto. No un build de Docker de 3 minutos, no un ciclo de provisionamiento de cold-start serverless de 10 minutos. El Worker se despliega a 300+ ubicaciones edge simultáneamente en menos de un minuto.
Cero mantenimiento de infraestructura. Sin servidor que parchear, sin certificados que renovar, sin base de datos que tunear, sin espacio en disco que monitorear. Cloudflare lo maneja todo. En un año no he tenido ningún incidente de infraestructura.
Costo. El tier gratuito cubre todo para un sitio personal: 100,000 peticiones de Worker por día, 10GB de almacenamiento en R2, 5GB de almacenamiento en KV. Nunca he recibido una factura. Si el tráfico sube, el plan de pago es $5/mes para uso razonable.
Confiabilidad. Los Workers son stateless. Una petición en Buenos Aires y una en Tokio son independientes. No hay estado mutable compartido que pueda corromperse, no hay pool de conexiones que pueda agotarse, no hay memory leak que se acumule. Cada petición es fresca.
Lo Que Realmente Duele
El debugging es remoto. No puedes adjuntar un debugger a un Worker de producción. Tienes console.log (que hace streaming a wrangler tail), páginas de error, e inferencia a partir del comportamiento. Reproducir bugs localmente a veces requiere recrear estado de KV, lo cual es tedioso.
wrangler dev ayuda pero no replica perfectamente el entorno de producción. Algunos comportamientos — particularmente alrededor de la consistencia de KV y la latencia del binding de IA — solo se manifiestan en producción.
KV tiene consistencia eventual. Después de una escritura en KV, una lectura en una ubicación edge diferente puede devolver el valor viejo durante segundos o minutos. Para el contenido de posts, esto significa que un post recién publicado puede no aparecer inmediatamente para todos los visitantes globalmente.
En práctica, nunca he tenido un usuario que lo note. Pero construir features que dependan de que las lecturas de KV reflejen inmediatamente las escrituras de KV (como un contador en tiempo real) sería poco confiable.
El límite de 1MB de script requiere disciplina. Añadir una dependencia grande — un syntax highlighter, un parser de Markdown, una librería de fechas — puede empujarte más allá del límite. He escrito workarounds (tokenizer personalizado, utilidades a mano) que no necesitaría en un servidor tradicional.
marked (el parser de Markdown) es la dependencia más grande con ~50KB. Todo lo demás es desde cero. Esto es sostenible pero limitante.
Los rate limits de Workers AI te sorprenden en el momento equivocado. Correr pruebas que tocan varios endpoints de IA en rápida sucesión, o publicar múltiples posts a la vez, puede agotar el rate limit del tier gratuito. El error es silencioso (capturado por try/catch) y la feature simplemente no funciona. Diagnosticarlo lleva tiempo.
Qué Haría Diferente
Pre-generar resúmenes IA al publicar. Actualmente el primer visitante de cada post paga la latencia de BART de 1-2 segundos. El script de publicación debería ejecutar BART para cada post y sembrar el caché de KV. Esta es una adición de 20 líneas al script de publicación que sigo sin escribir.
Usar Hono para el routing. El routing manual if (path === "/blog") en la función del Worker funciona pero no escala a muchas rutas. Hono es un router primero-para-Workers de 14KB — suficientemente pequeño para quedar bajo el límite de script, tipado, y bien probado. Lo usaría en un proyecto nuevo.
Usar un namespace de KV separado para staging. El setup actual comparte KV entre producción y staging. Funciona porque los datos son seguros de compartir, pero es conceptualmente desordenado. Un namespace de staging con datos de producción sembrados bajo demanda sería más limpio.
Añadir logging estructurado desde el primer día. Actualmente los errores desaparecen silenciosamente en bloques try/catch. Un reporter de errores ligero (incluso solo una escritura de KV de logging o un data point de Analytics Engine para errores) detectaría problemas más rápido.
La Evaluación Honesta
La plataforma Workers es genuinamente buena para este caso de uso. Un sitio personal o blog se beneficia del modelo edge: lecturas globalmente rápidas, cero mantenimiento, costo trivial.
Las restricciones — tamaño de script, consistencia de KV, debugging remoto — se vuelven relevantes cuando vas más allá de la entrega simple de contenido. Si estuviera construyendo una aplicación multi-usuario con estado complejo, usaría un backend más tradicional.
Para un blog que renderiza Markdown, sirve imágenes, y cuenta vistas: Workers es exactamente la herramienta correcta. Las restricciones que encontré fueron las que busqué. Las que no busqué, aún no las he encontrado.