Antes de alojar una web IA o Lovable: inventario del repositorio

Tener el código en Git no responde todavía a una pregunta comercial básica: ¿qué necesitas mantener funcionando? Una web puede entregar archivos estáticos, ejecutar un servidor o depender de servicios externos aunque su portada parezca sencilla.

Prepara un inventario del repositorio antes de elegir plan. El resultado útil es una lista de componentes, responsables y pruebas pendientes. Esta guía usa una herramienta original MIT, con 12 tests locales comprobados en Node 22.23.3. Sus casos son manifiestos sintéticos, no exportaciones reales de Lovable ni aplicaciones construidas.

Si el repositorio procede de Lovable y quieres alojarlo fuera de su plataforma, la guía para migrar una app de Lovable explica qué partes pueden seguir en Lovable Cloud y cuáles requieren una migración aparte.

Empieza por el proyecto concreto

Según la documentación de Lovable, los proyectos creados desde el 13 de mayo de 2026 usan TanStack Start con código servidor; los anteriores usan React y Vite con salida estática.

No decidas por el nombre «React» ni por una fecha aislada. Registra commit, rama y subcarpeta; revisa package.json, lockfile, configuración y entradas del servidor. En un monorepo, el manifiesto raíz puede describir herramientas de trabajo en lugar de la aplicación que vas a publicar. Confirma qué directorio contiene esa aplicación.

Para conservar una copia bajo tu control, consulta Git sync de Lovable. Tener una copia del código no acredita que auth, datos o archivos externos estén incluidos y operativos.

Ejecuta un inventario acotado

Usa Node 22.23.3, la versión del ensayo, y conserva la licencia. La herramienta no tiene dependencias externas ni lockfile; no necesitas npm ci. Los manifiestos de prueba contienen versiones y comandos de marcador: no instales sus dependencias ni ejecutes sus scripts.

git clone https://github.com/ocentelles/hostbrid-example-inventory.git
cd hostbrid-example-inventory
git checkout 150c8d09ea2fe0b511dbeac5cdd89e182d7f9b47
node --version
node --test test.mjs
node inventory.mjs fixtures/static
node inventory.mjs fixtures/external
node inventory.mjs fixtures/server
node inventory.mjs fixtures/ambiguous

node --version debe mostrar v22.23.3; el test debe terminar con 12 aprobados. Los cuatro casos anteriores muestran candidatos static, static con señal de cliente externo, server e indeterminate. Un quinto caso de JSON malformado da error y salida no cero; es una prueba negativa, no una aplicación para instalar.

Sobre una copia estable, propia y confiable de tu proyecto:

node inventory.mjs /path/to/own/repository

Sustituye la ruta de ejemplo por la tuya. El CLI lee package.json de la raíz hasta 256 KiB y comprueba presencia de una lista de nombres de configuración. No recorre carpetas, no ejecuta scripts, no lee .env ni contenido de código/configuración, y no contacta ni sube datos a servicios.

Lee el resultado como una hipótesis

Este es un extracto de campos del caso sintético estático:

{
  "candidate": "static",
  "scripts_executed": false,
  "build_verified": false,
  "env_files_read": false,
  "source_contents_read": false
}

static o server son candidatos por marcadores. build_verified:false deja explícita la prueba que falta. indeterminate es una respuesta útil cuando no hay evidencia suficiente: no fuerces una venta estática para eliminar la duda.

Un Dockerfile presente no demuestra qué corre dentro. Vite puede participar en una aplicación servidor; Next puede exportar archivos estáticos pese al marcador conservador de servidor. Un adaptador Astro, configuración renombrada o paquetes cargados dinámicamente pueden escapar a este análisis. La herramienta no lee comandos para clasificarlos ni inspecciona subproyectos.

Separa tres capas antes de elegir alojamiento

Un marcador de cliente Supabase no prueba backend migrado. Un frontend estático puede seguir llamando a un backend externo: el coste y la operación de ese servicio siguen en el inventario. La guía oficial de alojamiento externo distingue el traslado de frontend y backend; mover PostgreSQL por sí solo no mueve auth, storage, realtime o Edge Functions.

Para identificar Cloud gestionado o Supabase propio, abre los ajustes Cloud: el icono aparece en ambos casos. Lovable Cloud no aparece en tu panel personal de Supabase. Sigue la identificación oficial del backend. El CLI no consulta esos ajustes ni identifica la cuenta propietaria; no hace falta compartir tokens o logs.

Si conservas el backend, prueba orígenes y callbacks, sesiones, accesos autorizados, objetos privados y funciones desde el nuevo entorno. Si planteas trasladarlo, añade backup, restauración, comparación y rollback; conserva el origen hasta comprobar el ensayo. Estas son tareas pendientes, no recorridos demostrados por el CLI.

El informe no es una auditoría de secretos

La herramienta omite versiones, comandos, rutas del proyecto y contenidos en su salida; aun así parsea el manifiesto en memoria y ciertos nombres impresos pueden contener información. Revisa el informe antes de compartirlo. No pegues .env, tokens, dumps de clientes o logs completos en una consulta de alojamiento.

No certifica ausencia de secretos, vulnerabilidades o dependencias. Tampoco es un entorno aislado frente a un filesystem hostil. Las claves de Supabase requieren distinguir publicables y secretas: una clave privilegiada no pertenece al navegador. Ese control necesita una revisión adicional del código y del artefacto real.

Convierte el inventario en una decisión

Projects estático es candidato cuando hayas probado una salida estática. Si hace falta proceso permanente, revisa servicio Projects, plan con servicios incluidos y cuota libre, runtime y límites. Un VPS es una opción si necesitas controlar el sistema y asumir actualizaciones, red, observabilidad y copias. No hay compatibilidad TanStack, migración automática o Docker gratuito demostrados por este inventario.

Revisa costes por componente: alojamiento, backend conservado, correo, IA, dominio y operación. Después del diagnóstico, sigue la receta React estática, la comprobación de servidor Node o el diagnóstico de formularios según lo que realmente necesite tu aplicación. Son pasos distintos; un fixture no sustituye sus pruebas.