Casos de uso

WordPress / WooCommerce gestionado

Necesidad: alojar uno o varios sitios WordPress con .htaccess propio, TLS automático, defensa contra bots y caché de estáticos.

Este caso depende de una capacidad experimental

El Alojamiento PHP está en estado experimental. Este escenario es viable como piloto, no recomendado para producción crítica hasta la disponibilidad general.

Combinación:

• Alojamiento PHP (experimental) con la raíz apuntando al sitio.
• TLS automático: emisión inmediata al apuntar el DNS.
• Caché de contenido para wp-content/uploads/*, *.css, *.js.
• WAF bloqueando /wp-admin salvo direcciones IP conocidas.
• Limitación de tasa en /wp-login.php.
• CrowdSec opcional para mitigación de bots generalizada.

API + aplicación de una sola página en el mismo dominio

Necesidad: app.miempresa.com sirve una aplicación de una sola página en / y una API en /api/*, cada uno con un servidor de origen distinto.

Combinación:

• Dos rutas en el mismo dominio: / → servidor de la aplicación, /api → servidor de la API.
• TLS automático.
• Caché de contenido solo en / para los archivos compilados.
• Limitación de tasa específica en rutas sensibles de la API (/api/auth/*).

Página de aterrizaje con restricción geográfica y mantenimiento programado

Necesidad: página de aterrizaje de campaña que se libera el martes 10:00 y solo se sirve en Uruguay y Argentina.

Combinación:

• TLS automático.
• Geo-bloqueo en modo lista de permisos (UY, AR).
• Mantenimiento programado con HTML “próximamente” hasta el martes 10:00.
• Direcciones IP autorizadas del equipo de marketing para probar antes de la puesta en marcha.

Sitio bajo ataque sostenido de bots

Necesidad: una API pública está recibiendo extracción masiva de contenido y ataques de relleno de credenciales.

Combinación:

• WAF bloqueando agentes de usuario conocidos.
• Limitación de tasa agresiva en /auth/* (ej. 5/min por dirección IP).
• CrowdSec con escenarios apropiados.
• Geo-bloqueo en regiones donde no operás.
• Monitoreo de tero_waf_blocks_total para ajustar reglas.

Sitio institucional con cero cortes de TLS

Necesidad: un sitio corporativo simple, pero el equipo no quiere preocuparse jamás por renovaciones.

Combinación:

• Proxy inverso hacia un servidor de origen estático.
• TLS automático.
• Caché de contenido agresivo (es estático).
• Alertas básicas sobre las métricas expuestas.

API que valida la entrada en el borde

Necesidad: una API recibe formularios y JSON de varios frontends, y querés rechazar los datos mal formados (email inválido, campos faltantes, valores fuera de rango) sin repetir las mismas comprobaciones en cada servicio.

Combinación:

• Validación de formularios con esquemas estilo Zod sobre /api/**, respondiendo 422 con el detalle de errores.
• Reutilización de los esquemas de Zod que el front ya define.
• WAF en paralelo para los ataques (el WAF responde 403; la validación, 422).
• Limitación de tasa en los endpoints de escritura.
• Modo “solo registro” al principio, para medir el impacto antes de activar el bloqueo.

Función en el borde sin servidor de origen

Necesidad: una redirección con lógica, un pequeño webhook o una transformación de respuesta, sin levantar ni mantener un backend.

Combinación:

• Funciones Lambda con el motor JavaScript embebido para lógica liviana (o Bun/TypeScript si necesitás npm).
• TLS automático.
• Limitación de tasa si el endpoint es público.

Sitio estático / aplicación de una sola página sin servidores

Necesidad: publicar una landing, una documentación generada estáticamente o una aplicación de una sola página compilada (React/Vue/Svelte), sin mantener ningún servidor de origen. La API vive aparte.

Combinación:

• Sitios estáticos en / desde un origen S3 (Garage/MinIO) o disco local, con fallback de aplicación de una sola página activado.
• TLS automático.
• (Opcional) Una segunda ruta /api/* con Proxy inverso hacia el backend.
• WAF y Limitación de tasa en las rutas de la API.
• Publicás subiendo archivos al bucket; la caché de borde sirve el resto.