Cloudflare Workers Builds: CI/CD sin GitHub Actions

Para proyectos en Vercel, el CI/CD viene resuelto: conectas el repo y cada push a main despliega. Al mover proyectos a Cloudflare Workers, buscaba lo mismo sin tener que mantener un workflow de GitHub Actions a mano para cada proyecto de cliente. Workers Builds resuelve exactamente eso.

Qué es Workers Builds

Es la integración nativa de Cloudflare que conecta un repositorio de GitHub directamente al dashboard de Workers & Pages. Cada push a la rama configurada (normalmente main) dispara un build usando el comando que definas (en mi caso, npm run deploy:cf), sin necesidad de secretos de API gestionados manualmente en Actions.

Por qué lo prefiero frente a un workflow manual

Menos superficie de mantenimiento: no hay un archivo YAML de Actions que actualizar cuando cambia una versión de Node, ni tokens de API de Cloudflare que rotar manualmente en secretos de GitHub. El propio dashboard de Cloudflare gestiona la autenticación de despliegue.

Cuándo sí uso GitHub Actions en su lugar

Cuando el pipeline necesita pasos adicionales que Workers Builds no cubre: tests automatizados antes del deploy, notificaciones a Slack, o despliegues condicionales según el contenido del commit. Para esos casos, GitHub Actions sigue siendo la herramienta correcta — pero para 'build y deploy en cada push a main', Workers Builds es más simple y con menos piezas que pueden romperse.

Conclusión

La regla que aplico: si el pipeline es 'compilar y desplegar', uso la integración nativa del proveedor. Si el pipeline necesita lógica adicional real, entonces sí invierto en un workflow de Actions. Añadir complejidad de CI/CD antes de necesitarla es tan mal criterio como no automatizar en absoluto.