Español
English
Català
Françaisv0 permet publicar a Vercel amb un clic. Si vols executar l’app generada en un altre proveïdor, identifica primer què necessita el repositori: un servidor web estàtic, un servidor Node.js, una base de dades o integracions externes. L’URL de Vercel i el repositori Git són parts diferents; canviar l’allotjament no trasllada automàticament tots els serveis connectats.
Les FAQ actuals de v0 indiquen que pots exportar el codi i desplegar-lo en un altre proveïdor. La integració amb GitHub explica com el repositori connectat es converteix en la font de veritat. Aquesta guia tracta la feina d’allotjament que ve després d’obtenir accés al codi.
1. Aconsegueix el projecte complet i executa’l en local
Connecta el projecte de v0 al seu repositori de GitHub o importa el codi al repositori que mantindràs. Comprova quina branca conté la versió més recent i clona-la. Obre package.json i revisa els scripts reals, el gestor de paquets i l’estructura del monorepositori abans de triar les ordres de build. No copiïs només els components visuals si l’app també depèn de rutes, Server Actions o controladors d’API.
Executa el projecte en local amb el fitxer de bloqueig de dependències i els scripts documentats. Comprova que pots reproduir la pàgina i les crides al backend fora de la previsualització de v0. La previsualització és útil per construir, però no demostra que el nou allotjament tingui les mateixes variables, connexions a la base de dades o ajustos de desplegament.
2. Comprova si l’app necessita el servidor de Next.js
Les FAQ actuals de v0 descriuen les apps generades amb Next.js, React, TypeScript, Tailwind i shadcn/ui. Si el projecte utilitza rutes renderitzades al servidor, Route Handlers, Server Actions, galetes durant la petició o consultes a la base de dades des del servidor, necessita un runtime Node.js. Copiar fitxers estàtics a un directori web no executarà aquestes funcions. Les crides del navegador a una API externa també poden funcionar amb allotjament estàtic si el servei permet aquest origen i l’accés a les dades es pot exposar de manera segura.
Per allotjar Next.js pel teu compte, la guia oficial d’autoallotjament explica com executar el servidor de producció i recomana posar-hi un proxy invers al davant. Comprova els scripts build i start del projecte. La seqüència habitual és npm run build i després l’ordre d’inici de producció del repositori; fes servir els scripts que realment hi hagi.
Alguns projectes es poden exportar com a fitxers estàtics, però només si les funcions admeten aquest mode. Revisa next.config.* per si hi ha output: 'export', executa el build i serveix-ne el resultat en local. La guia vigent d’exportació estàtica de Next.js enumera les funcions que necessiten servidor i els límits de la sortida estàtica.
Els Projects d’Hostbrid permeten desplegar des d’un repositori com a servei Node o Docker. Abans de contractar, compara el runtime, els recursos i el pla disponibles amb les necessitats de l’app. El fet d’utilitzar Next.js no confirma per si sol que totes les integracions o ajustos encaixin en qualsevol configuració.
3. Configura les variables i conserva els serveis de dades
Fes una llista de les variables que fa servir l’aplicació a v0 i al projecte de Vercel que hi està vinculat. Afegeix al nou runtime els valors de producció necessaris; no copiïs .env.local a un repositori públic. Next.js incorpora al JavaScript del navegador les variables amb el prefix NEXT_PUBLIC_, de manera que qualsevol visitant les podrà veure. Les contrasenyes de base de dades, els tokens privats i les claus de signatura han de quedar al servidor.
Traslladar el frontend Next.js no migra una base de dades de Supabase o Neon, els usuaris d’autenticació, l’emmagatzematge de fitxers, el proveïdor de correu, els pagaments ni un compte d’API d’IA. Pots conservar aquests serveis i actualitzar els orígens permesos, les URL de retorn i els webhooks per al domini nou. Si també canvies el backend, prepara la migració a part i inclou les dades, els permisos, els fitxers i una opció per tornar enrere.
4. Prova-ho en una URL temporal abans de canviar el DNS
Desplega primer una versió de prova. Verifica una pàgina amb renderització al servidor, les API, els formularis, l’inici i el tancament de sessió, les lectures i escriptures a la base de dades, les càrregues de fitxers, els webhooks o callbacks de pagament i les tasques programades que faci servir l’app. Revisa els registres del servidor i els errors de xarxa del navegador. Si el projecte utilitza next/image, comprova’l també: el servidor Next.js i un servidor de fitxers estàtics no optimitzen les imatges de la mateixa manera.
Quan la versió nova superi les comprovacions, canvia el DNS i verifica HTTPS, redireccions, URL de redirecció d’autenticació, crides a l’API i enllaços de correu al domini real. Mantén disponible el desplegament anterior i el servei de dades fins que la versió nova sigui estable. Que carregui la pàgina principal no demostra que la migració s’hagi acabat.
Si vols allotjar una app creada amb v0 a Hostbrid, compara les necessitats del repositori amb Projects i els preus actuals. Tu controles el desplegament de l’aplicació i també t’ocupes dels secrets, les dades, les còpies i les actualitzacions.