Un web que s’obre a localhost només està disponible a l’ordinador on l’executes. Perquè altres persones hi puguin entrar, has de publicar cada part del projecte en un servei accessible per Internet. Tria l’allotjament segons què s’ha d’executar, no segons l’editor o la IA que ha generat el codi.
Si tens HTML creat amb IA, consulta la guia per publicar HTML i CSS. Per a React i Vite, segueix la guia de desplegament des de Git. Si Codex ha creat el projecte, compara ChatGPT Sites amb la publicació des d’un repositori abans de triar l’allotjament.
1. Identifica què hi ha darrere de la pantalla
Revisa la carpeta del projecte, package.json, la documentació i els scripts. Anota si hi ha:
- Fitxers estàtics: HTML, CSS, imatges i potser JavaScript que descarrega el navegador. Alguns projectes React/Vite o Astro també generen fitxers estàtics amb una compilació.
- Un procés de servidor: una API, pàgines renderitzades a cada petició, autenticació pròpia, tasques en segon pla o un servei Node/Python.
- Serveis externs: una base de dades, emmagatzematge de fitxers, correu, inici de sessió o APIs. Que la pàgina es vegi no vol dir que aquestes integracions estiguin connectades.
Un servidor de desenvolupament com npm run dev serveix per treballar a l’ordinador. No és la versió pública. Comprova l’ordre de compilació i el directori de sortida del framework; Vite, per exemple, sol generar dist, però la configuració ho pot canviar (documentació de Vite).
2. Desa i prepara el projecte
Posa el codi en un repositori Git i conserva’n una còpia abans de canviar-ne la configuració. No publiquis fitxers .env, contrasenyes, claus privades ni dades reals de clients. Busca referències a localhost, camins del teu disc i URL de prova: al web públic, localhost apunta al dispositiu de cada visitant.
Si la carpeta encara no és a Git, afegeix primer a .gitignore regles per a les dependències i els secrets, per exemple:
node_modules/
.env
.env.*
!.env.example
Des de la carpeta del projecte, inicialitza i revisa el repositori abans del primer commit:
git init -b main
git add .
git status --short
git commit -m "Primera versió"
Si git status mostra una clau, un fitxer .env o dades privades, no facis el commit: treu-ho del que has preparat i corregeix .gitignore. Aquesta regla no deixa de seguir fitxers que Git ja tenia registrats. Després crea un repositori buit —privat si el codi és d’un client— i connecta-hi l’URL:
git remote add origin https://github.com/USUARI/REPOSITORI.git
git push -u origin main
Si ja hi ha una carpeta .git, no inicialitzis un repositori niat: comprova la branca i el remot amb git branch --show-current i git remote -v. La guia de GitHub per pujar codi local explica altres variants. Després connecta el repositori a Hostbrid Projects; el manual de Projects explica els permisos i com triar el repositori.
Si el projecte és un monorepo, apunta quina carpeta conté l’aplicació i quins fitxers necessita durant la instal·lació i la compilació. No eliminis una API, una carpeta de servidor o una integració només perquè la portada sembli funcionar.
3. Tria on s’executa cada component
Per a HTML, CSS i altres fitxers estàtics, necessites allotjament que els serveixi i permeti obrir les rutes públiques. Hostbrid Sites cobreix webs gestionats com WordPress; comprova el catàleg i els límits per al projecte concret.
Per a un repositori que necessita compilació i desplegament des de Git, consulta Hostbrid Projects. Projects també executa serveis Docker dins de la quota del pla: Dev publica projectes estàtics, mentre que els serveis permanents requereixen un pla de pagament. Consulta als plans i preus de Projects el nombre de serveis i els recursos disponibles abans de contractar. Una compilació estàtica no executa per si sola una API Node que l’aplicació necessiti.
Valora un VPS si necessites accés root, control del sistema operatiu, configuració de xarxa o processos que no encaixin en els límits del pla Projects. Amb un VPS t’encarregues del sistema, les actualitzacions, la seguretat, les còpies i els desplegaments. Compara les condicions i els preus actuals amb les necessitats reals, no només amb la mida de la carpeta.
4. Configura compilació, variables i dades
Indica l’ordre d’instal·lació, la compilació i la carpeta de sortida que pertoquen al framework. Les variables del frontend poden acabar als fitxers que rep el navegador; no hi posis secrets. Les claus privades han de quedar al servidor i configurar-se com a variables protegides de l’entorn.
Si fas servir una base de dades local, migrar vol dir traslladar-ne l’esquema i les dades amb un procediment adequat i canviar la connexió de producció. Publicar el codi no copia automàticament SQLite ni una altra base del teu portàtil. Consulta com preparar una migració de PostgreSQL abans de connectar dades reals.
Un formulari també necessita una destinació que accepti i processi els enviaments. Mira com comprovar el backend i el lliurament del formulari; el missatge «enviat» a la pantalla no demostra que el correu hagi arribat.
5. Prova la versió pública abans d’anunciar-la
Obre l’URL HTTPS des d’un altre dispositiu i prova la portada i també una ruta interna enganxada directament a la barra. Comprova imatges, estils, errors de consola, enllaços, inici de sessió, formularis i les crides a API que faci el projecte. Si canvies una variable de compilació, torna a compilar: editar-la després no canvia els fitxers ja publicats.
Connecta el domini quan la versió temporal funcioni. Configura els registres DNS que t’indiqui el proveïdor, espera que es propaguin i comprova el certificat HTTPS. Mantén disponible el web anterior fins que hagis verificat el nou i conserva una manera de tornar a la versió prèvia.
Què contractar segons el projecte
HTML o un frontend compilat sense servidor propi: revisa destinacions compatibles amb aquests fitxers i rutes. Un build des de Git o servei Docker dins de la quota: consulta Projects i els seus límits. Accés root, control del sistema o necessitats que superen aquests límits: valora un VPS. Per a WordPress i altres serveis PHP gestionats, consulta Sites. Si no saps on acaba el frontend i comença el backend, explica’ns el framework i els serveis que utilitza, sense enviar secrets.
Publicar fa que el web sigui accessible; no garanteix que Google l’indexi, que aparegui en una posició concreta o que una IA el recomani. Primer comprova que funciona i que el contingut públic respon les preguntes dels visitants.