Humaniza AI empezó en septiembre de 2025 y su primera infraestructura creció más rápido que su documentación. El frontend estaba en Vercel, el backend había pasado por Google Cloud y las cuentas y cobros dependían de Supabase y Paddle. Cuando el despliegue dejó de estar disponible, el reto no era subir otra copia: era reconstruir el servicio sin crear usuarios duplicados, romper suscripciones ni volver a depender de una sola pieza difícil de diagnosticar.
Qué había que conservar
La regla principal fue tratar los datos externos como sistemas existentes, no como componentes que debían recrearse. Supabase siguió siendo la fuente de identidad y perfiles; Paddle siguió siendo la fuente de productos, transacciones y suscripciones. La migración solo cambió dónde se ejecutaba la aplicación. Así evitamos que una cuenta activa pareciera nueva o que un pago válido perdiera su vínculo con el usuario.
| 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 | Conservar el proyecto de Supabase | Conteo de cuentas y relación entre autenticación y perfiles. |
| 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.
La migración se validó desde afuera
Que Cloud Run marque una revisión como activa no demuestra que el producto funcione. Probamos las mismas rutas que usa una persona: abrir el dominio con HTTPS, crear una sesión temporal, consultar el perfil, ejecutar una reescritura y solicitar la configuración de checkout. Después eliminamos la cuenta de prueba y comprobamos que no quedaran perfiles de humo en la base.
- 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.
- Crear un usuario temporal y confirmar que autenticación y perfil representen la misma cuenta.
- Ejecutar una solicitud real al modelo, no solo una respuesta simulada.
- Abrir la ruta autenticada de Paddle sin iniciar un cobro.
- Eliminar los artefactos de prueba y volver a contar registros.
El error que más información dejó
En una revisión encontramos más filas de perfil que cuentas autenticadas. Tres pertenecían a pruebas técnicas y se retiraron; otras filas antiguas carecían de identificador. El sitio podía seguir funcionando, pero esa diferencia demostraba que una luz verde de infraestructura no equivale a integridad de datos. Desde entonces separamos el conteo canónico de cuentas de las tablas auxiliares.
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.