Abans d’allotjar una web IA o Lovable: inventari del repositori

Tenir el codi a Git encara no respon una pregunta de compra: què has de mantenir en funcionament? Una web pot servir fitxers estàtics, executar un servidor o dependre de serveis externs encara que la portada sembli senzilla.

Fes un inventari del repositori abans de triar pla. El resultat útil és una llista de components, responsables i proves pendents. Aquesta guia utilitza una eina original MIT, amb 12 tests locals verificats amb Node 22.23.3. Els casos són manifestos sintètics, no exportacions reals de Lovable ni aplicacions construïdes.

Si el repositori prové de Lovable i el vols allotjar fora de la plataforma, la guia per allotjar una app de Lovable en un altre proveïdor explica què pot continuar a Lovable Cloud i què requereix una migració a part.

Comença pel projecte concret

Segons la documentació de Lovable, els projectes creats des del 13 de maig de 2026 fan servir TanStack Start amb codi servidor; els anteriors, React i Vite amb sortida estàtica.

No decideixis pel nom «React» o només per una data. Registra commit, branca i subcarpeta; revisa package.json, lockfile, configuració i entrades servidor. En un monorepo, el manifest arrel pot descriure eines de desenvolupament en lloc de l’aplicació que publicaràs. Identifica’n el directori.

Per conservar una còpia del codi sota el teu control, consulta Git sync de Lovable. Una còpia del codi no acredita que autenticació, dades o fitxers externs estiguin inclosos i funcionin.

Executa un inventari acotat

Fes servir Node 22.23.3, la versió provada, i conserva la llicència. L’eina no té dependències externes ni lockfile; no cal npm ci. Els manifestos de prova contenen versions i ordres de marcador: no n’instal·lis les dependències ni n’executis els 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 ha de mostrar v22.23.3; els tests han d’acabar amb 12 aprovats. Aquests quatre casos produeixen candidats static, static amb indici de client extern, server i indeterminate. Un cinquè cas JSON malformat dona error i sortida no zero: prova negativa, no aplicació per instal·lar.

Sobre una còpia estable, pròpia i de confiança del teu repositori:

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

Substitueix la ruta d’exemple per la teva. El CLI llegeix package.json de l’arrel fins a 256 KiB i comprova la presència d’una llista de noms de configuració admesos. No recorre carpetes, no executa scripts, no llegeix .env ni contingut de codi/configuració, ni contacta serveis ni puja dades.

Llegeix el resultat com una hipòtesi

Extracte de camps del cas estàtic sintètic:

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

static i server són candidats per marcadors. build_verified:false explicita la prova que falta. indeterminate és una resposta útil quan no hi ha prou informació: no forcis una compra estàtica per amagar el dubte.

Un Dockerfile no demostra què s’executa dins. Vite pot participar en una aplicació servidor; Next pot exportar fitxers estàtics malgrat l’indici conservador de servidor. Un adaptador Astro, configuració reanomenada o paquets carregats dinàmicament poden escapar de l’anàlisi. L’eina no llegeix ordres per classificar-les ni inspecciona subprojectes.

Separa tres capes abans de triar allotjament

Un marcador de client Supabase no prova un backend migrat. Un frontend estàtic pot continuar cridant un backend extern: cost i operació d’aquell servei segueixen a l’inventari. La guia oficial d’allotjament extern separa frontend i backend; moure PostgreSQL sol no mou autenticació, storage, realtime o Edge Functions.

Per identificar Cloud gestionat o Supabase propi, obre els ajustos Cloud: la icona apareix en tots dos casos. Lovable Cloud no apareix al teu tauler personal de Supabase. Segueix la identificació oficial del backend. El CLI no consulta aquests ajustos ni identifica el compte propietari; no cal compartir tokens o registres.

Si conserves el backend, prova orígens i callbacks, sessions, accessos autoritzats, objectes privats i funcions des del nou entorn. Si planteges traslladar-lo, afegeix còpia, restauració, comparació i retorn enrere; conserva l’origen fins a comprovar l’assaig. Són tasques pendents, no recorreguts demostrats pel CLI.

L’informe no és una auditoria de secrets

La sortida omet versions, ordres, rutes del projecte i continguts; tot i això el manifest es processa en memòria i alguns noms impresos poden contenir informació. Revisa l’informe abans de compartir-lo. No enganxis .env, tokens, exportacions de clients o registres complets en una consulta d’allotjament.

L’eina no certifica absència de secrets, vulnerabilitats o dependències. Tampoc aïlla un sistema de fitxers hostil. Les claus de Supabase distingeixen publicables i secretes: una clau privilegiada no pertany al navegador. Cal una revisió addicional del codi i de l’artefacte real.

Converteix l’inventari en una decisió

L’allotjament estàtic a Projects és una opció quan hagis provat la sortida estàtica. Si cal procés permanent, revisa serveis Projects, pla amb serveis inclosos i quota lliure, runtime i límits. Un VPS pot encaixar si necessites controlar el sistema i assumir actualitzacions, xarxa, seguiment i còpies. Aquest inventari no demostra compatibilitat TanStack, migració automàtica o serveis Docker gratuïts.

Revisa costos per component: allotjament, backend conservat, correu, IA, domini i operació. Després del diagnòstic, segueix la recepta React estàtica, la comprovació de servidor Node o el diagnòstic de formularis segons les necessitats reals. Són passos diferents; un cas sintètic no substitueix les seves proves.