Allotjar una app de Supabase: publica el frontend i conserva el backend

Una aplicació feta amb React, Vite o una eina d’IA pot fer servir Supabase per a l’autenticació, Postgres, Storage o funcions. Canviar on se serveix el frontend no trasllada aquests serveis: pots desplegar el repositori amb Projects i mantenir Supabase com a backend si actualitzes les variables i les URL permeses.

Aquesta guia cobreix el frontend d’un projecte Supabase existent. No és una migració de base de dades ni substitueix les polítiques, els usuaris, els fitxers o les funcions de Supabase. Abans de contractar, revisa els plans i límits de Projects i els costos dels serveis externs que mantinguis.

1. Identifica l’URL del projecte i les claus

A Supabase, copia l’URL del projecte i una clau publicable des de Connect o API Keys. En un frontend Vite, la guia oficial de React amb Supabase fa servir VITE_SUPABASE_URL i VITE_SUPABASE_PUBLISHABLE_KEY:

VITE_SUPABASE_URL=https://el-teu-projecte.supabase.co
VITE_SUPABASE_PUBLISHABLE_KEY=sb_publishable_...

Aquestes variables queden incloses al codi del navegador i els usuaris les poden veure; no són contrasenyes. La guia de claus d’API diu que les claus publicables identifiquen una app pública, mentre que les claus secretes o service_role no s’han d’enviar mai al frontend i ometen RLS. Si encara veus la clau antiga anon, fes-la servir només amb polítiques adequades i planifica la transició a les noves.

2. Comprova les polítiques abans d’exposar l’app

Una URL i una clau publicable correctes no autoritzen per si soles un accés segur. Activa i revisa Row Level Security a totes les taules accessibles des de la Data API; defineix què pot fer cada rol i prova tant peticions autenticades com anònimes. Comprova també els permisos de Storage i els endpoints d’Edge Functions. No posis una clau administrativa a VITE_*, en un fitxer del repositori ni en una variable exposada pel bundler.

3. Afegeix el domini i les redireccions

Connecta el repositori a Projects, selecciona la branca i declara les variables públiques abans de la build. Vite les substitueix quan compila; si canvien, torna a desplegar. Mantén .env.local fora de Git i no copiïs secrets als registres.

A Supabase Auth, configura la URL principal del lloc i afegeix les URL de retorn que faràs servir: domini temporal, producció i les rutes de callback que requereixi el flux. La configuració d’URL de redirecció ha de coincidir amb les URL que genera l’app. Per a OAuth, comprova també la URL de callback registrada al proveïdor extern; pot ser diferent de la pàgina on torna l’usuari.

4. Prova el domini temporal abans de canviar el DNS

Obre l’app i verifica les lectures i escriptures permeses, el rebuig dels accessos no autoritzats, l’inici i tancament de sessió, la recuperació de contrasenya, OAuth, Storage i les crides a funcions. Revisa la consola del navegador i la pestanya de xarxa; una build correcta no prova que aquestes integracions funcionin. Comprova CORS o CSP si el navegador bloqueja peticions.

Quan tot funcioni, apunta el domini final a Projects, actualitza la URL del lloc i les URL permeses de Supabase, i repeteix els fluxos d’autenticació amb HTTPS. Si conserves Supabase, els seus costos, límits i disponibilitat continuen aplicant-se per separat. Si també vols traslladar dades o Auth, planifica-ho i assaja-ho com un altre projecte, amb còpia de seguretat i reversió.

Fonts: quickstart de React, claus d’API, protegir dades, URL de redirecció i Projects.