Héberger une app Supabase : déployer le frontend et garder le backend

Une application créée avec React, Vite ou un outil d’IA peut utiliser Supabase pour l’authentification, Postgres, Storage ou des fonctions. Changer l’hébergement du frontend ne déplace pas ces services : vous pouvez déployer le dépôt avec Projects et garder Supabase comme backend, à condition de mettre à jour les variables et les URL autorisées.

Ce guide porte sur le frontend d’un projet Supabase existant. Il ne s’agit pas d’une migration de base de données et il ne remplace ni les règles, ni les utilisateurs, ni les fichiers, ni les fonctions Supabase. Avant de commander, consultez les forfaits et limites de Projects et les coûts des services externes conservés.

1. Repérer l’URL du projet et les clés

Dans Supabase, copiez l’URL du projet et une clé publique depuis Connect ou API Keys. Pour un frontend Vite, le guide officiel React avec Supabase utilise VITE_SUPABASE_URL et VITE_SUPABASE_PUBLISHABLE_KEY :

VITE_SUPABASE_URL=https://votre-projet.supabase.co
VITE_SUPABASE_PUBLISHABLE_KEY=sb_publishable_...

Ces valeurs sont intégrées au code du navigateur et visibles par les utilisateurs ; ce ne sont pas des mots de passe. Le guide des clés API Supabase précise que les clés publiques identifient une app publique, tandis que les clés secrètes ou service_role ne doivent jamais être envoyées au frontend et contournent RLS. Si votre projet affiche encore une clé anon, utilisez-la uniquement avec des règles adaptées et préparez la migration vers les nouvelles clés.

2. Vérifier les règles avant d’exposer l’app

Une URL et une clé publique correctes ne suffisent pas à autoriser un accès sûr. Activez et vérifiez Row Level Security sur toutes les tables accessibles via la Data API ; définissez les droits de chaque rôle et testez les requêtes authentifiées et anonymes. Vérifiez également les permissions Storage et les endpoints Edge Functions. Ne placez pas de clé admin dans VITE_*, un fichier du dépôt ou une variable exposée par le bundler.

3. Ajouter le domaine et les redirections

Connectez le dépôt à Projects, choisissez la branche et déclarez les variables publiques nécessaires avant le build. Vite les remplace à la compilation ; redéployez-les si elles changent. Gardez .env.local hors de Git et ne copiez pas de secrets dans les journaux.

Dans Supabase Auth, configurez l’URL principale du site et ajoutez les URL de retour réellement utilisées : domaine temporaire, production et routes callback requises par le flux. La configuration des URL de redirection doit correspondre aux URL générées par l’app. Pour OAuth, vérifiez aussi l’URL callback enregistrée auprès du fournisseur externe ; elle peut différer de la page où l’utilisateur revient.

4. Tester le domaine temporaire avant de changer le DNS

Ouvrez l’app et vérifiez les lectures et écritures autorisées, le rejet des accès non autorisés, la connexion et la déconnexion, la récupération du mot de passe, OAuth, Storage et les appels de fonctions. Consultez la console du navigateur et l’onglet Réseau ; un build réussi ne prouve pas que ces intégrations fonctionnent. Vérifiez CORS ou CSP si le navigateur bloque les requêtes.

Quand tout fonctionne, pointez le domaine final vers Projects, mettez à jour l’URL du site et la liste de redirection Supabase, puis refaites les tests d’authentification en HTTPS. Garder Supabase signifie que ses coûts, quotas et disponibilité continuent de s’appliquer séparément. Pour transférer aussi les données ou Auth, préparez et répétez cette migration à part, avec sauvegarde et retour arrière.

Sources : guide React, clés API, sécuriser les données, URL de redirection et Projects.