Com exportar i allotjar pel teu compte una app construïda amb IA

Per allotjar pel teu compte una app construïda amb IA, has de treure el codi (una descàrrega o una sincronització amb un repositori de GitHub que controlis), recrear els seus secrets com a variables d’entorn, moure o recrear la base de dades i desplegar-la en un allotjament que encaixi amb el que és l’app: un allotjament estàtic per a un front end senzill, o una plataforma que executi servidors o contenidors per a qualsevol cosa amb back end. El codi sol ser la part fàcil. Les dades, els secrets i els serveis que el constructor executava discretament per a tu són on està la feina.

Per què exportar

Hi ha bones raons per endur-te el codi, i algunes de menys bones.

Bones raons:

• Propietat i assegurança. Una còpia del codi al teu propi repositori et protegeix si el constructor canvia els preus, les funcions o les condicions.
• Traspàs a desenvolupadors. Un equip d’enginyeria voldrà el codi a Git, amb les seves eines habituals i el seu procés de revisió.
• Requisits específics. Residència de dades, un proveïdor de núvol concret, polítiques de seguretat de l’empresa o una infraestructura que el constructor no ofereix.
• Escala o cost en una mida on executar la teva pròpia infraestructura realment compensa.

Motius menys bons: traslladar una app petita amb pocs usuaris per estalviar una petita quantitat mensual. Allotjar-ho pel teu compte transfereix feina a tu: actualitzacions, còpies de seguretat, monitorització, pedaços de seguretat. Pot ser la decisió correcta; només fes-la de manera conscient.

Un terme mig sensat: segueix construint i allotjant on ets, però sincronitza amb el teu propi repositori de GitHub des de l’inici. Obtens l’assegurança sense la feina operativa. Si Git t’és nou, llegeix què és GitHub.

Què inclou i què no inclou una exportació

Abans de confiar en una exportació, obre-la i comprova-la. Normalment:

Els secrets es deixen fora intencionadament: un arxiu que pots enviar per correu o pujar a un commit mai no hauria de contenir claus vives. Les dependències es deixen fora perquè es reconstrueixen a partir del fitxer de bloqueig.

Pas 1: treu el codi

Dues rutes habituals:

• Descarrega un arxiu del projecte. Ràpid, i bo per a un trasllat puntual o una còpia de seguretat.
• Sincronitza amb GitHub. Millor per a qualsevol cosa contínua: historial complet, fàcil de clonar en qualsevol lloc, i la majoria d’allotjaments despleguen directament des d’un repositori de GitHub a cada push.

De qualsevol manera, clona’l o descomprimeix-lo en un ordinador (o en un entorn de desenvolupament al núvol) i busca un README. Si no n’hi ha cap, demana a la IA del constructor que n’escrigui un abans de marxar:

Escriu un README per executar aquest projecte fora d’aquesta plataforma: la pila tecnològica, les versions del runtime necessàries, les ordres d’instal·lació i de compilació, l’ordre d’inici i el port, cada variable d’entorn que llegeix el codi (noms i propòsit, sense valors) i com s’executen les migracions de la base de dades.

Aquest prompt t’estalvia hores, perquè obliga a escriure les parts implícites de la configuració.

Pas 2: executa-la primer en local

Abans de desplegar-la en cap lloc, demostra que l’app funciona per si sola:

1. Instal·la el runtime que indica el README: Node.js, Python, Java, .NET, en una versió compatible.
2. Instal·la les dependències (npm install, pnpm install, pip install -r requirements.txt, o l’equivalent).
3. Crea un fitxer .env local amb les variables d’entorn, usant claus de prova sempre que sigui possible. Mantén-lo fora de Git. Què són les variables d’entorn i els secrets explica la idea.
4. Connecta’t a una base de dades: un Postgres local o una base de dades de desenvolupament gratuïta d’un proveïdor gestionat.
5. Executa les migracions, després inicia l’app i prova els fluxos principals.

Qualsevol cosa que falli aquí fallarà també en un allotjament, i és molt més fàcil de depurar a la teva pròpia màquina. Sorpreses habituals: una URL codificada de la vista prèvia del constructor, una variable d’entorn que faltava perquè el constructor la injectava automàticament, o un servei (emmagatzematge de fitxers, redimensionat d’imatges) que només existia a la plataforma.

Pas 3: mou les dades

Si l’app té usuaris reals, les dades importen més que el codi.

• Exporta la base de dades. Per a Postgres, pg_dump genera un fitxer que pots restaurar amb pg_restore o psql a la nova base de dades. Demana a la IA del constructor que ho executi si no tens accés directe, i que expliqui què ha produït.
• Mou els fitxers pujats. Si els usuaris han pujat imatges o documents, estan en un emmagatzematge d’objectes separat de la base de dades. Copia’ls al nou emmagatzematge (per exemple, un bucket compatible amb S3) i actualitza les URL guardades si inclouen l’antic domini.
• Planifica el canvi. Per a una app en marxa, el més simple és una finestra de manteniment breu: aturar les escriptures, fer una exportació final, restaurar-la al nou allotjament, canviar el DNS i tornar a obrir. Escriu cada pas abans.
• Prova una restauració en una base de dades de prova abans del trasllat real.

Si Postgres et resulta poc familiar, què és Postgres en cobreix les bases.

Pas 4: tria on allotjar-la

Adapta l’allotjament a la forma de l’app. Els noms següents són exemples de proveïdors coneguts de cada categoria a setembre de 2026, no un rànquing; revisa les funcions i els preus actuals als seus llocs web.

També necessitaràs:

• Una base de dades gestionada: molts allotjaments d’apps ofereixen Postgres, i serveis dedicats com Neon o Supabase el proporcionen per separat. Val la pena que sigui gestionada: les còpies de seguretat i les actualitzacions són feina d’algú altre.
• Emmagatzematge d’objectes per a les pujades, si l’app en té.
• Enviament de correu, pagaments i proveïdors d’IA: normalment només cal definir les mateixes claus d’API al nou allotjament.

Sent justos amb els compromisos: els allotjaments de plataforma (les quatre primeres files) són més ràpids de configurar i mantenir, però tens menys control i els costos poden pujar amb el trànsit. Un servidor virtual sovint és més barat amb una càrrega constant i està totalment sota el teu control, però t’encarregues de les actualitzacions, el TLS, les còpies de seguretat, la monitorització i la recuperació. Si ningú de l’equip vol aquesta feina, tria una plataforma. Per als fonaments de què implica l’allotjament web, consulta què és l’allotjament web.

Pas 5: desplega i fes el canvi

1. Connecta el repositori a l’allotjament, o puja una imatge de contenidor.
2. Defineix les variables d’entorn al tauler de l’allotjament: totes les del teu README, amb els valors reals.
3. Defineix les ordres de compilació i d’inici i el port. Molts allotjaments passen el port en una variable d’entorn PORT; l’app ha d’escoltar-hi i en totes les interfícies (0.0.0.0), no només a localhost.
4. Executa les migracions contra la nova base de dades.
5. Prova-la a l’URL temporal de l’allotjament abans de tocar el DNS.
6. Actualitza els serveis externs que apuntin a l’antiga URL: webhooks de pagaments, URL de redirecció OAuth per al login, enllaços de correu, orígens permesos.
7. Mou el domini actualitzant els registres DNS cap al nou allotjament. Com connectar un domini personalitzat explica els registres.
8. Mantén el desplegament antic en marxa una estona fins que n’estiguis segur, i després retira’l.

El pas 6 és el que més sovint s’oblida: els inicis de sessió i els pagaments que fallen en silenci després d’un trasllat solen tenir la culpa en una URL de callback que encara apunta a l’antic allotjament.

Pas 6: assumeix les operacions

Un cop allotges l’app pel teu compte, les coses que feia el constructor passen a ser teves. Com a mínim: còpies de seguretat automàtiques de la base de dades amb una restauració provada, seguiment d’errors, alertes de disponibilitat, actualitzacions de dependències i una nota de qui té accés a cada compte. Com portar un prototip d’IA a producció repassa aquesta llista amb més detall.

Llista de verificació de l’exportació

• Codi en un repositori propi, amb un README que cobreixi l’execució, la compilació i les variables d’entorn
• L’app s’executa en local des d’un clon net
• Base de dades exportada i restauració provada; fitxers pujats copiats
• Allotjament escollit segons la forma de l’app, més base de dades i emmagatzematge gestionats
• Totes les variables d’entorn definides amb valors reals al nou allotjament
• Webhooks, redireccions OAuth i enllaços de correu actualitzats
• DNS canviat, desplegament antic mantingut una estona i després retirat
• Còpies de seguretat, monitorització i llista d’accessos al seu lloc

Exportar des de Mythex

A Mythex, el codi que construeixes és teu. Amb el pla Pro pots descarregar el projecte com a arxiu des de Configuració del projecte → Exporta, o connectar GitHub i fer push i pull contra el teu propi repositori; els plans gratuïts poden veure el codi només en lectura, però no exportar-lo ni sincronitzar-lo. Els secrets i node_modules queden fora de les exportacions, així que recrea els teus secrets al nou allotjament. La documentació cobreix els passos a exportar i executar en un altre lloc i a GitHub, exportació i importació. També pots seguir allotjant a Mythex i usar la sincronització amb GitHub només com la teva pròpia còpia i via de traspàs; si et mous, despublica l’app de Mythex quan el nou allotjament estigui en marxa.

Preguntes