Alojar una app de Supabase: publica el frontend y conserva el backend

Una aplicación creada con React, Vite o una herramienta de IA puede usar Supabase para autenticación, Postgres, Storage o funciones. Cambiar dónde se sirve el frontend no mueve esos servicios: puedes publicar el repositorio con Projects y conservar Supabase como backend, siempre que actualices las variables y direcciones autorizadas.

Esta receta cubre el frontend de un proyecto Supabase existente. No es una migración de base de datos ni reemplaza políticas, usuarios, archivos o funciones de Supabase. Antes de contratar, revisa los planes y límites de Projects y los costes de cualquier servicio externo que mantengas.

1. Identifica la conexión y las claves

En Supabase, copia la URL del proyecto y una clave publicable desde Connect o API Keys. En un frontend Vite, la documentación oficial de React con Supabase usa VITE_SUPABASE_URL y VITE_SUPABASE_PUBLISHABLE_KEY:

VITE_SUPABASE_URL=https://tu-proyecto.supabase.co
VITE_SUPABASE_PUBLISHABLE_KEY=sb_publishable_...

Estas variables se incorporan al código del navegador y se pueden ver en las herramientas del usuario; no las trates como contraseñas. La guía de claves de Supabase indica que las claves publicables identifican una app pública, mientras que las claves secretas o service_role nunca deben enviarse al frontend y omiten RLS. Si el proyecto aún muestra anon, úsala solo con las políticas adecuadas y planifica la transición a las claves nuevas.

2. Verifica las políticas antes de exponer la app

Una URL y una clave publicable correctas no autorizan por sí solas un acceso seguro. Activa y revisa Row Level Security en todas las tablas accesibles por la Data API; define qué puede hacer cada rol y prueba tanto una sesión autenticada como una petición anónima. Comprueba también los permisos de Storage y los endpoints de Edge Functions. No pongas una clave administrativa en VITE_*, en un archivo del repositorio ni en una variable que el bundler exponga.

3. Añade el dominio y las redirecciones

Conecta el repositorio a Projects, selecciona la rama y declara las variables públicas necesarias antes del build. Vite las sustituye al compilar; si cambian, vuelve a desplegar el proyecto. Conserva .env.local fuera de Git y no copies secretos a los logs.

En Supabase Auth, configura la URL principal del sitio y añade las URL de retorno que realmente usarás: dominio temporal, producción y las rutas de callback requeridas por tu flujo. La configuración de redirect URLs debe coincidir con las URL que genera la app. Para OAuth, comprueba también la URL de callback registrada en el proveedor externo; no es necesariamente la misma que la página a la que vuelve el usuario.

4. Prueba en el dominio temporal antes de cambiar DNS

Abre la app y verifica lectura y escritura permitidas, rechazo de accesos no autorizados, inicio y cierre de sesión, recuperación de contraseña, OAuth, Storage y llamadas a funciones. Comprueba la consola del navegador y la pestaña de red; un build verde no prueba esas integraciones. Revisa también CORS o CSP si el navegador bloquea solicitudes.

Cuando todo funcione, apunta el dominio definitivo a Projects, actualiza la URL de sitio y los redirect allowlists de Supabase, y repite los flujos de autenticación sobre HTTPS. Mantener Supabase significa que sus costes, cuotas y disponibilidad siguen aplicándose por separado. Si quieres trasladar también datos o Auth, planifica y ensaya esa migración como otro trabajo con copia de seguridad y reversión.

Fuentes: quickstart React, claves API, proteger datos, URL de redirección y Projects.