El despliegue de Humaniza AI separa la página web, la API de edición y el servicio de autenticación y pagos en tres servicios de Cloud Run. Un servidor con Caddy recibe las solicitudes del dominio y las dirige al servicio correspondiente. Esta página describe esa configuración y delimita lo que podemos concluir de una prueba: una página que responde no certifica que el inicio de sesión, una reescritura o un pago funcionen.
Qué había que conservar
Supabase mantiene identidad y perfiles; Paddle mantiene productos, transacciones y suscripciones. Desplegar una nueva imagen de la aplicación no implica recrear esas bases externas. Aun así, comprobar que una cuenta y una suscripción mantienen su vínculo requiere una prueba autenticada específica. Las pruebas públicas de contenido no hacen esa comprobación.
| Componente | Decisión | Comprobación |
|---|---|---|
| Frontend | Contenedor separado en Cloud Run | Carga pública, rutas prerenderizadas y respuesta móvil. |
| API de edición | Servicio independiente en Cloud Run | Salud, CORS y una reescritura completa con el modelo configurado. |
| Autenticación y pagos | Servicio Node separado | Inicio de sesión, perfil autenticado y token de checkout de Paddle. |
| Datos | Supabase conserva identidad y perfiles | La prueba pública de edición no revisa ni publica cuentas o datos personales. |
| Entrada web | Caddy delante de los servicios | HTTPS, redirección de www y encabezados noindex en rutas privadas. |
Por qué separamos tres servicios
Frontend, edición y autenticación tienen ritmos y riesgos distintos. Un cambio visual no debería reiniciar el proceso que humaniza texto; una actualización de Paddle no debería obligar a publicar de nuevo el frontend. La separación también facilita leer registros: un error 5xx en la API ya no se mezcla con una ruta inexistente del sitio.
Comprobar por capas sin confundir sus resultados
El 17 de octubre publicamos una prueba de reescritura con originales, respuestas completas y revisiones del backend identificadas. Esa ejecución llama a la API; no crea una cuenta, no modifica saldos, no inicia un pago y no valida la experiencia por streaming. La comprobación de páginas revisa por separado rutas públicas, metadatos, redirecciones y ads.txt. Ninguna de las dos pruebas permite concluir que todo el producto esté validado.
- Comprobar respuestas 200 del sitio, la API pública y las rutas de salud.
- Revisar que www redirija al dominio canónico y que el certificado cubra ambos nombres.
- Si se evalúan cuentas, hacerlo con una cuenta de prueba identificada; no inferir su funcionamiento de una respuesta pública.
- Ejecutar una solicitud real al modelo, no solo una respuesta simulada.
- Si se evalúan pagos, distinguir configuración de checkout de transacción confirmada; la prueba editorial no ejecuta cobros.
- Conservar los registros pertinentes y no publicar credenciales ni datos de usuarios.
Por qué el archivo ads.txt tiene una ruta independiente
El archivo ads.txt se entrega directamente desde Caddy, en lugar de depender de que el contenedor del frontend arranque. Es un registro público pequeño y estable. Esto permite comprobar su disponibilidad por HTTP y HTTPS, con y sin www. El panel de AdSense lo muestra autorizado el 17 de octubre. Esa autorización verifica el registro del editor; no aprueba el contenido ni la monetización del sitio.
Qué cambiaríamos si empezáramos hoy
- Definir infraestructura y secretos con una receta reproducible antes del primer despliegue público.
- Crear pruebas de limpieza para cada usuario temporal que use el equipo.
- Mantener las rutas editoriales separadas de las pantallas privadas y de herramientas.
- No declarar una migración terminada solo porque las páginas responden: autenticación, cobro y modelo necesitan pruebas reales.