Publicar una app de Google AI Studio amb GitHub i hosting propi

Google AI Studio pot generar una aplicació web amb una interfície React i codi de servidor Node. La previsualització o l’enllaç compartit d’AI Studio et permeten provar-la, però no despleguen aquest codi al teu allotjament. Google ofereix el desplegament a Cloud Run; si vols gestionar el codi a GitHub i publicar-lo amb un altre proveïdor, comprova primer quines parts depenen de Google.

Aquesta guia descriu el camí documentat Google AI Studio → GitHub → Hostbrid Projects. No hem connectat cap compte d’AI Studio ni publicat una aplicació d’un client per certificar una migració automàtica; cada projecte necessita una prova pròpia.

1. Confirma que has creat una aplicació web

En mode Build, Google AI Studio pot crear una aplicació web full-stack o una aplicació nativa per a Android. Aquesta ruta és per a l’aplicació web. Si has triat Android, un allotjament web no crea una aplicació instal·lable ni la publica a Play Store.

Abans de moure res, revisa el codi i confirma que entens les dependències i com s’inicia. A AI Studio, enllaça el projecte amb GitHub des de Settings → GitHub o baixa el codi com a ZIP. La sincronització amb GitHub és bidireccional: els canvis poden anar d’AI Studio al repositori i del repositori a AI Studio. El ZIP és codi per revisar localment; no és una càrrega directa al panell de Projects.

2. Revisa quins serveis necessita l’aplicació

No converteixis una aplicació full-stack en un lloc estàtic només perquè compili. Mira package.json, identifica els scripts d’instal·lació, construcció i inici, i comprova si hi ha rutes de servidor, Firebase, autenticació, emmagatzematge o integracions de Google Workspace.

Projects publica projectes connectats a Git i també ofereix serveis Node o Docker, però la documentació pública no certifica una recepta automàtica per migrar-hi una app full-stack d’AI Studio. Un backend pot requerir desplegar la interfície i el servei per separat, i revisar-ne els recursos i el pla. Abans de comprometre’t amb la migració, confirma com encaixen els processos, les rutes i les variables en l’arquitectura disponible. Això tampoc configura automàticament els comptes externs: si fas servir Firebase, OAuth o una base de dades externa, verifica les credencials, els dominis, les regles i les adreces de retorn des del domini nou.

Si només tens una sortida HTML estàtica, segueix la guia per publicar una web HTML creada amb IA. Si tens un procés Node, consulta també com publicar una aplicació Node.js.

3. Connecta el repositori a Projects

Si la interfície és estàtica o el projecte ja té una configuració de build compatible, connecta GitHub a Hostbrid Projects i selecciona el repositori. Configura com a branca de producció la que vols publicar. Cada push a aquesta branca pot iniciar un desplegament; comprova també que la connexió amb GitHub continuï autoritzada. Si has baixat un ZIP, primer extreu-lo, revisa .gitignore i els fitxers que pujaràs —sobretot .env— i crea un repositori Git; Projects connecta repositoris, no rep el ZIP directament.

Deixa que Projects detecti el projecte i revisa els paràmetres abans del primer desplegament. Si cal, defineix l’ordre d’instal·lació, el de construcció, la carpeta de sortida o la subcarpeta del monorepositori. No copiïs valors genèrics sense revisar els scripts reals. Per a una sortida estàtica, indica la carpeta que realment genera la build. Si hi ha processos de servidor, comprova quin servei els executa i com es connecten amb la interfície; una build estàtica per si sola no publica endpoints Node.

Després de publicar la interfície i configurar per separat els serveis que l’aplicació necessiti, prova la URL HTTPS, obre directament una ruta interna i revisa les peticions del navegador al backend. Que la compilació acabi bé no demostra que OAuth, la base de dades o les crides a Gemini funcionin en producció.

4. Desa la clau Gemini com a secret

AI Studio pot configurar GEMINI_API_KEY com a secret del servidor. No donis per fet que aquesta configuració es trasllada al proveïdor nou. Afegeix la clau a les variables d’entorn de Projects i llegeix-la des del servidor. No la posis al codi React, en una variable VITE_*, en un fitxer de Git ni als registres.

Google indica que, si descarregues una aplicació com a ZIP per allotjar-la en un altre lloc, has de configurar GEMINI_API_KEY a l’entorn d’allotjament. Les crides a l’API Gemini tenen els seus propis límits i possibles costos; canviar d’allotjament no els elimina. Comprova també què passa si Google retorna un error o s’esgota una quota.

Si la clau ja s’ha publicat al JavaScript

Tracta qualsevol clau de servidor que hagi arribat al navegador com a compromesa. Crea una clau de substitució i actualitza el secret del servidor; desplega-la i comprova que funciona, i després desactiva de seguida la clau exposada. Si detectes un abús actiu, desactiva-la immediatament encara que l’aplicació deixi de funcionar fins que despleguis la substitució. Revisa l’activitat, les quotes i la facturació: esborrar un fitxer o un commit no invalida una clau copiada. Elimina-la del codi del frontend i de les variables públiques. Vite inclou al bundle els valors amb prefix VITE_, per tant aquest prefix no serveix per guardar secrets.

Per comprovar la correcció, crea una build nova i revisa els fitxers JavaScript i els mapes de fonts que se serveixen públicament, a més de les peticions de xarxa del navegador. Cerca localment la clau antiga; no la copiïs en cap escàner en línia ni la comparteixis en una captura. Confirma que la interfície crida el teu servidor i que aquest llegeix el secret d’una variable d’entorn de Projects. El backend ha de validar la petició i limitar accés, freqüència i ús; un proxy obert només trasllada l’abús al teu compte. Si la clau es va pujar a Git, retira-la també de l’historial i dels registres, però mantén la rotació com a mesura que la invalida.

5. Prova les integracions i connecta el domini

Prova l’aplicació amb el domini HTTPS temporal abans de canviar el domini final. Verifica l’inici de sessió, les adreces de retorn OAuth, la lectura i escriptura de dades, els permisos, les pujades de fitxers i cada crida a Gemini. Si una integració s’havia connectat automàticament a AI Studio, torna-la a provar al nou entorn en lloc de suposar que conserva la configuració.

Quan les proves passin, connecta el domini i torna a comprovar el certificat HTTPS, les rutes, les APIs i l’autenticació. Si l’aplicació necessita serveis gestionats, xarxa, disc o càrrega sostinguda que no encaixa a Projects, compara els plans i límits actuals abans de migrar-la.

El resultat depèn del repositori i dels serveis que fa servir. GitHub facilita moure i revisar el codi; no copia automàticament secrets, usuaris, dades, quotes d’API ni configuracions OAuth.

Fonts: Google AI Studio Build · Claus de Gemini · Variables d’entorn de Vite · OWASP: gestió de secrets · Guia de Projects de Hostbrid