Tabla de Contenidos

• Resumen estratégico
• 1. Cuándo usar Pages y cuándo usar Workers
• 2. Límites importantes del plan gratuito

  • Consejo poco común
• 3. El problema clásico de las SPA: las rutas profundas

  • Consejo poco común
• 4. Variables de entorno: públicas no significa secretas

  • Consejo poco común
• 5. No pongas toda la API dentro de una SPA

  • Consejo poco común: no invoques Functions para todo
• 6. Usa el dominio personalizado al final del despliegue
• 7. Protege el origen y la API
• 8. Aprovecha los Preview Deployments

  • Consejo poco común
• 9. Usa R2 para archivos grandes
• 10. Evita la caché agresiva durante el desarrollo
• 11. Métricas que deberías vigilar
• Arquitectura recomendada para empezar
• Conclusión

Resumen estratégico

Necesidad	Herramienta	Recomendación
Desplegar el frontend	Cloudflare Pages	Conectar el repositorio Git y desplegar automáticamente
Servir archivos estáticos	Pages CDN	Aprovechar que las solicitudes de assets son gratuitas e ilimitadas
Gestionar dominios	Cloudflare DNS	Usar dominio personalizado y registros proxyados
Proteger la aplicación	WAF Custom Rules	Proteger login, registro y endpoints sensibles
Crear una API pequeña	Pages Functions o Workers	Usarlos para lógica ligera y endpoints sencillos
Almacenar archivos	R2	Separar imágenes, PDFs y archivos grandes del frontend
Guardar datos simples	KV o D1	Utilizarlos para configuración, sesiones o prototipos
Proteger formularios	Turnstile	Añadirlo únicamente donde exista abuso
Manejar rutas SPA	_redirects o _routes.json	Enviar las rutas desconocidas a index.html
Gestionar secretos	Variables y Secrets	Nunca incluir claves privadas en el bundle del frontend
Validar cambios	Preview Deployments	Revisar cada pull request antes de producción
Controlar costos	Límites y analítica	Medir Pages Functions y Workers por separado

1. Cuándo usar Pages y cuándo usar Workers

Para una SPA tradicional, el punto de partida más sencillo es Cloudflare Pages.

Pages es adecuado cuando tu aplicación se compila en archivos estáticos:

npm run build

y genera una carpeta como:

dist/

El flujo sería:

1. Conectar el repositorio Git.
2. Elegir el framework.
3. Definir el comando de build.
4. Indicar la carpeta de salida.
5. Desplegar automáticamente cada cambio.

Cloudflare Pages permite configurar comandos, carpetas de salida, variables de entorno y presets para distintos frameworks. (Build configuration)

Usa Workers cuando necesites:

• Una API personalizada.
• Middleware avanzado.
• Autenticación.
• Transformación de solicitudes.
• Lógica ejecutada en el edge.
• Un proyecto que combine frontend y backend en un mismo despliegue.

La recomendación práctica es:

Empieza con Pages para el frontend y añade Workers o Pages Functions solo cuando tengas una necesidad concreta de backend.

2. Límites importantes del plan gratuito

El plan gratuito de Pages permite hasta 500 builds mensuales, una compilación simultánea, 20.000 archivos por sitio y un tamaño máximo de 25 MiB por archivo. También permite despliegues de preview ilimitados. (Pages Limits)

Esto es suficiente para muchas aplicaciones personales, MVPs y proyectos pequeños.

Sin embargo, no conviene subir directamente a Pages:

• Videos grandes.
• Instaladores.
• Backups.
• Archivos multimedia pesados.
• Colecciones grandes de imágenes.

Para eso es mejor utilizar R2 o un almacenamiento especializado y dejar Pages exclusivamente para la aplicación.

Consejo poco común

Cuenta los archivos generados por tu build:

Get-ChildItem -Recurse dist | Measure-Object

Una aplicación puede parecer pequeña en megabytes, pero superar el límite de archivos debido a mapas de origen, traducciones, fuentes o assets duplicados.

3. El problema clásico de las SPA: las rutas profundas

Una SPA puede funcionar perfectamente al navegar desde /, pero mostrar un error 404 si el usuario entra directamente a:

/dashboard
/settings/profile
/projects/123

Esto sucede porque el servidor busca un archivo físico llamado dashboard o settings/profile, aunque esas rutas deberían ser interpretadas por el router del frontend.

La solución es redirigir las rutas desconocidas hacia index.html.

En muchos proyectos de Pages puedes crear un archivo _redirects dentro de la carpeta pública:

/* /index.html 200

El código 200 indica que el navegador debe recibir el contenido de index.html sin convertir la ruta en una redirección visible.

Consejo poco común

No apliques este fallback indiscriminadamente a archivos estáticos o APIs. Una configuración mal planteada puede convertir errores reales como estos:

/api/users
/assets/logo.svg
/favicon.ico

en respuestas HTML de index.html.

Prueba siempre:

• La ruta principal.
• Una ruta interna.
• Una ruta inexistente.
• La recarga del navegador.
• Un enlace compartido directamente.
• El acceso desde un dispositivo móvil.

4. Variables de entorno: públicas no significa secretas

Una SPA se ejecuta en el navegador. Por eso, cualquier variable que se incluya durante el build puede terminar siendo visible para el usuario.

Es válido exponer:

VITE_API_URL
NEXT_PUBLIC_API_URL
PUBLIC_SUPABASE_URL

Pero nunca debes exponer:

DATABASE_PASSWORD
STRIPE_SECRET_KEY
JWT_PRIVATE_KEY
CLOUDFLARE_API_TOKEN

Las variables públicas pueden utilizarse para configurar el frontend. Los secretos deben permanecer en Pages Functions, Workers o tu backend.

Cloudflare permite configurar variables diferentes para producción y preview desde el panel del proyecto. (Pages Bindings)

Consejo poco común

Crea dos entornos separados:

Preview → API de pruebas
Production → API real

Así puedes revisar un pull request sin que el frontend de prueba modifique datos reales.

Además, fija explícitamente la versión de Node.js mediante .nvmrc, .node-version o NODE_VERSION. Esto evita que un cambio en el entorno de build rompa el despliegue inesperadamente. (Pages Build Image)

5. No pongas toda la API dentro de una SPA

Una SPA no debe comunicarse directamente con servicios que requieran claves privadas.

Arquitectura insegura:

SPA → Servicio externo usando clave secreta

Arquitectura recomendada:

SPA → Worker o Pages Function → Servicio externo

El Worker puede:

• Validar los datos recibidos.
• Comprobar autenticación.
• Aplicar rate limiting.
• Ocultar las credenciales.
• Normalizar respuestas.
• Registrar errores.

Pages Functions se ejecuta como Workers y sus solicitudes cuentan dentro de la cuota de Workers. En el plan gratuito, la cuota combinada es de 100.000 solicitudes diarias. (Pages Functions Pricing)

Consejo poco común: no invoques Functions para todo

Si añades una Function a un proyecto Pages sin configurar rutas, puedes terminar ejecutando lógica dinámica para solicitudes que solo deberían servir archivos estáticos.

Configura las rutas para que la Function responda únicamente a:

/api/*

y deja los assets como contenido estático. Cloudflare permite definir rutas de inclusión y exclusión para controlar qué solicitudes invocan Functions. (Pages Functions Routing)

6. Usa el dominio personalizado al final del despliegue

Primero prueba la aplicación en:

mi-app.pages.dev

Después conecta:

app.ejemplo.com

Esto facilita separar:

app.ejemplo.com       → producción
staging.ejemplo.com   → pruebas
api.ejemplo.com       → API
assets.ejemplo.com    → archivos grandes

Activa el proxy de Cloudflare para el tráfico HTTP y HTTPS, pero deja como DNS-only los servicios que no sean compatibles con el proxy web, como algunos registros de correo.

7. Protege el origen y la API

Si el frontend está en Pages pero la API vive en otro servidor, protege también ese origen.

Medidas recomendadas:

• No revelar innecesariamente la IP del backend.
• Aplicar autenticación en la API, no solo en el frontend.
• Validar CORS.
• Limitar solicitudes a /api/login, /api/register y /api/reset-password.
• Usar Turnstile en formularios atacados.
• Aplicar Managed Challenge antes de bloquear usuarios.

Las reglas personalizadas de Cloudflare permiten realizar acciones como bloquear o desafiar solicitudes. En el plan gratuito existen límites de cantidad y funcionalidad, por lo que conviene reservarlas para rutas críticas. (Custom Rules)

8. Aprovecha los Preview Deployments

Una de las funciones más útiles para equipos pequeños es tener una URL de preview por pull request.

El flujo recomendado:

Pull request
   ↓
Preview deployment
   ↓
Pruebas visuales y funcionales
   ↓
Merge a producción

Esto es especialmente importante para SPAs porque permite detectar:

• Rutas que devuelven 404.
• Variables de entorno ausentes.
• Errores de CORS.
• Cambios rotos en móviles.
• Problemas de caché.
• Fallos en autenticación.

Consejo poco común

Incluye en tu aplicación una pequeña etiqueta visual que indique el entorno:

Preview · commit a81f2c

Así nadie confunde una URL de prueba con producción durante una revisión.

9. Usa R2 para archivos grandes

El bundle de una SPA debería contener únicamente lo necesario para ejecutar la aplicación.

Guarda fuera de Pages:

• Imágenes subidas por usuarios.
• Videos.
• PDFs.
• Archivos de proyectos.
• Backups.
• Exportaciones generadas.

R2 está pensado para almacenamiento de objetos y puede utilizarse junto con Workers o una API propia. En la oferta actual de Cloudflare, el plan gratuito incluye una cuota de almacenamiento y operaciones para R2. (Cloudflare Plans)

Una arquitectura sencilla sería:

SPA → Worker → R2

El Worker genera URLs controladas y evita que el bucket sea un punto de acceso completamente abierto.

10. Evita la caché agresiva durante el desarrollo

Cloudflare puede cachear archivos de frontend durante mucho tiempo. Esto es positivo en producción, pero puede ser frustrante cuando estás desarrollando.

Para evitar problemas:

• Usa nombres versionados para CSS y JavaScript.
• No caches respuestas privadas.
• Purga URLs específicas en lugar de purgar todo.
• Usa el modo Development Mode durante cambios rápidos.
• Verifica CF-Cache-Status.
• Recuerda que la caché del navegador puede sobrevivir a una purga de Cloudflare.

El plan gratuito permite Cache Rules, purga de caché y analítica de caché, aunque con límites inferiores a los planes superiores. (Cache Features by Plan)

11. Métricas que deberías vigilar

Para una SPA, no basta con medir visitas.

Observa:

• Tiempo de carga del JavaScript principal.
• Porcentaje de respuestas cacheadas.
• Errores 404 en rutas internas.
• Errores 4xx y 5xx de la API.
• Solicitudes a Functions.
• Uso diario de Workers.
• Tiempo de CPU por solicitud.
• Tasa de errores de autenticación.
• Tamaño del bundle.
• Tasa de abandono en formularios.

El plan gratuito de Workers tiene un límite de 100.000 solicitudes diarias y 10 ms de CPU por solicitud. Una función pequeña puede funcionar bien, pero una función que procesa imágenes, autentica usuarios complejos o realiza cálculos pesados puede superar ese límite. (Workers Limits)

Arquitectura recomendada para empezar

Cloudflare DNS
      ↓
Cloudflare Pages
      ↓
SPA estática
      ↓
Pages Functions / Workers
      ↓
Base de datos externa o D1
      ↓
R2 para archivos

Para un MVP, puedes comenzar con:

• Pages para el frontend.
• Un Worker o Pages Function para la API.
• Supabase, Neon o D1 para la base de datos.
• R2 para archivos.
• Turnstile para formularios sensibles.
• Preview Deployments para revisar cambios.

Conclusión

La capa gratuita de Cloudflare es especialmente interesante para desplegar SPAs porque combina hosting estático, CDN, HTTPS, dominios personalizados, previews y funciones serverless.

La estrategia más eficiente es:

1. Desplegar primero el frontend en Pages.
2. Resolver correctamente las rutas de la SPA.
3. Separar variables públicas de secretos.
4. Usar Functions o Workers solo para lógica dinámica.
5. Guardar archivos grandes en R2.
6. Proteger login, registro y API.
7. Medir consumo, errores y rendimiento.
8. Escalar únicamente cuando exista un límite real.

Cloudflare no sustituye automáticamente a todo el backend, pero sí permite construir una aplicación web funcional, segura y bastante económica con una arquitectura modular.