Auto-héberger Supabase : un backend complet (base, auth, API, stockage) sur votre VPS

Supabase réunit dans une même plateforme les briques essentielles d’un backend moderne : base PostgreSQL, authentification, API REST générée automatiquement, stockage de fichiers et synchronisation en temps réel. Pour une équipe qui développe une application web, mobile ou un SaaS, cette approche évite d’assembler plusieurs services indépendants. Elle constitue aussi une alternative open source à Firebase, avec PostgreSQL comme socle.

L’auto-hébergement permet de conserver la maîtrise de l’infrastructure et de la localisation des données. Sur un futur VPS TalCloud hébergé en France, il pourra s’inscrire dans une démarche de souveraineté et de conformité RGPD, avec stockage NVMe, protection Anti-DDoS Netrix et support humain. Cette liberté implique toutefois davantage de responsabilités : sécurité, sauvegardes, mises à jour et supervision restent à votre charge.

Une stack complète, mais relativement lourde

Supabase self-hosted n’est pas une application monolithique. Son déploiement officiel repose sur Docker Compose et lance plusieurs conteneurs interdépendants. Il faut donc prévoir davantage de mémoire et de capacité CPU que pour une simple instance PostgreSQL.

La consommation exacte dépend du trafic, des volumes de données, de Realtime et des traitements exécutés. Pour un environnement de production, choisissez un VPS disposant d’une marge de RAM suffisante. Évitez de dimensionner le serveur au plus juste, car PostgreSQL, Studio, Kong et les autres composants doivent fonctionner simultanément.

Une autre précaution est impérative : le fichier .env.example contient des valeurs prévues pour servir d’exemple. Tous les secrets par défaut doivent être remplacés avant d’exposer le service. Conserver les valeurs d’origine, notamment POSTGRES_PASSWORD, JWT_SECRET, ANON_KEY, SERVICE_ROLE_KEY ou les identifiants du dashboard, créerait une faille critique.

Enfin, l’édition auto-hébergée ne fournit pas toutes les commodités du service cloud managé. Les sauvegardes automatiques, leur externalisation, la restauration, la haute disponibilité, les alertes et certaines intégrations doivent être organisées par vos soins.

Les composants de Supabase

La plateforme assemble plusieurs services spécialisés :

• PostgreSQL stocke les données relationnelles, les fonctions SQL, les extensions et les règles de sécurité.
• PostgREST transforme automatiquement les tables, vues et fonctions autorisées en API REST.
• GoTrue gère les comptes, les sessions, les jetons JWT et les méthodes d’authentification.
• Realtime diffuse les changements PostgreSQL et permet des interactions en temps réel.
• Storage fournit une API de stockage de fichiers organisée autour de buckets.
• Kong joue le rôle de passerelle API et distribue les requêtes vers les différents services.
• Studio fournit une interface graphique pour administrer la base, les utilisateurs et certains paramètres.

Kong doit constituer le point d’entrée applicatif public. PostgreSQL et les services internes ne doivent pas être directement accessibles depuis Internet.

Prérequis du VPS

Avant l’installation, préparez les éléments suivants :

• Un VPS Linux récent avec plusieurs gigaoctets de RAM et une marge adaptée à la charge.
• Docker Engine et le module Docker Compose (voir installer Docker sur un VPS).
• Git pour récupérer le dépôt officiel.
• Un nom de domaine ou un sous-domaine, par exemple supabase.example.fr.
• Un enregistrement DNS pointant vers l’adresse IP du VPS.
• Un reverse proxy capable de gérer HTTPS devant Kong.
• Un pare-feu limitant les ports publics à SSH, HTTP et HTTPS.

Le stockage NVMe est particulièrement utile à PostgreSQL, mais ses performances ne remplacent pas une stratégie de sauvegarde. Vérifiez également l’espace disponible pour les volumes Docker, la base, les journaux et les fichiers envoyés dans Storage.

Installer Supabase avec Docker Compose

Connectez-vous au VPS avec un compte administrateur, puis récupérez le dépôt officiel :

git clone --depth 1 https://github.com/supabase/supabase
cd supabase/docker
cp .env.example .env

N’exécutez pas encore la stack. Ouvrez d’abord .env et remplacez toutes les valeurs sensibles.

Vous pouvez générer un mot de passe PostgreSQL robuste avec OpenSSL :

openssl rand -base64 36

Générez séparément un secret JWT long et aléatoire :

openssl rand -hex 32

Utilisez des valeurs différentes pour POSTGRES_PASSWORD, JWT_SECRET et DASHBOARD_PASSWORD. Remplacez aussi DASHBOARD_USERNAME par un identifiant non trivial.

Les variables ANON_KEY et SERVICE_ROLE_KEY ne sont pas de simples chaînes aléatoires. Ce sont des JWT signés avec JWT_SECRET. Il faut les régénérer avec un outil JWT compatible HS256 en utilisant respectivement les rôles anon et service_role. Vérifiez aussi les dates d’émission et d’expiration des jetons générés. Si vous modifiez ultérieurement JWT_SECRET, vous devrez produire de nouvelles clés et invalider les anciens jetons.

Conservez les secrets dans un gestionnaire de mots de passe ou un coffre adapté. Ne publiez jamais le fichier .env dans Git.

Une fois la configuration vérifiée, téléchargez les images et démarrez les services :

docker compose pull
docker compose up -d

Contrôlez ensuite leur état :

docker compose ps
docker compose logs --tail 100

Attendez que PostgreSQL et les services dépendants soient prêts avant de conclure à une erreur. Si un conteneur redémarre en boucle, inspectez ses journaux et vérifiez en priorité les secrets, les URL configurées et les dépendances.

Premier accès à Supabase Studio

Studio est l’interface d’administration de Supabase. Dans la configuration Docker officielle, son accès passe par Kong et doit être protégé avec les identifiants DASHBOARD_USERNAME et DASHBOARD_PASSWORD.

N’utilisez jamais les identifiants d’exemple. Choisissez un mot de passe unique et, si possible, ajoutez une restriction réseau, un VPN ou une liste d’adresses IP autorisées au niveau du reverse proxy.

Depuis Studio, vous pouvez parcourir le schéma PostgreSQL, créer des tables, exécuter des requêtes SQL et gérer les utilisateurs. L’interface facilite l’administration courante, mais elle ne remplace ni les migrations versionnées ni une procédure de déploiement reproductible.

Créer une table et utiliser l’API automatique

Supposons une table projects contenant un identifiant, un nom, un propriétaire et une date de création. Dès qu’elle se trouve dans un schéma exposé, PostgREST peut générer des routes permettant de lire ou modifier ses lignes.

Cette commodité exige une configuration de sécurité immédiate. Activez Row Level Security, ou RLS, sur chaque table accessible par l’API. Sans RLS et sans politiques adaptées, une table exposée à la clé anon peut devenir publiquement lisible ou modifiable.

Une politique classique autorise un utilisateur connecté à consulter uniquement les projets dont la colonne owner_id correspond à son identifiant d’authentification. D’autres politiques peuvent distinguer lecture, création, modification et suppression.

Supabase utilise principalement deux clés :

• ANON_KEY est destinée aux clients publics. Elle représente le rôle anon, puis les politiques RLS tiennent compte de l’utilisateur connecté.
• SERVICE_ROLE_KEY contourne les politiques RLS pour les opérations privilégiées.

La clé service_role ne doit jamais apparaître dans une application web, mobile, un dépôt public ou une variable exposée au navigateur. Elle doit rester exclusivement dans un backend de confiance.

Configurer l’authentification avec GoTrue

GoTrue prend en charge l’inscription, la connexion, les sessions et les jetons JWT. L’authentification par email et mot de passe peut servir de point de départ. Des fournisseurs OAuth peuvent également être activés, mais chacun demande des identifiants, des URL de redirection et une configuration spécifique.

L’envoi des emails de confirmation, de récupération de mot de passe ou d’invitation nécessite un serveur SMTP. Sans cette configuration, les parcours reposant sur l’email ne fonctionneront pas correctement en production.

Configurez notamment l’URL publique de l’application, les URL de redirection autorisées, l’expéditeur et les paramètres SMTP. Testez ensuite le cycle complet : inscription, confirmation, connexion, renouvellement de session et récupération du mot de passe.

Publier Supabase en HTTPS

Placez un reverse proxy comme Nginx, Caddy ou Traefik devant Kong. Le proxy doit terminer la connexion TLS et transmettre les requêtes vers le port interne de la passerelle.

Exposez uniquement les ports nécessaires :

• 80 pour la redirection vers HTTPS.
• 443 pour l’API, l’authentification, Storage, Realtime et éventuellement Studio.
• 22 pour SSH, idéalement limité par adresse IP ou protégé par une politique stricte.

Ne publiez pas le port PostgreSQL sur Internet. Si un accès distant est indispensable pour l’administration, utilisez un tunnel SSH ou un réseau privé. Ajoutez également des limites de requêtes, des délais adaptés et les en-têtes nécessaires aux connexions WebSocket de Realtime.

Renforcer la sécurité

Avant toute mise en production, appliquez au minimum ces contrôles :

• Remplacer tous les secrets fournis dans .env.example.
• Générer correctement les JWT anon et service_role.
• Activer RLS et définir des politiques explicites sur chaque table exposée.
• Ne jamais transmettre SERVICE_ROLE_KEY à un client.
• Garder PostgreSQL et les services internes hors d’Internet grâce au pare-feu.
• Protéger Studio avec des identifiants robustes et une restriction réseau.
• Activer HTTPS avec un certificat valide.
• Maintenir Docker, le système et les images Supabase à jour.
• Vérifier les règles du pare-feu et les permissions des volumes.

La protection Anti-DDoS Netrix de TalCloud complète cette défense au niveau réseau, mais elle ne corrige pas une politique RLS absente, une clé divulguée ou un dashboard mal protégé.

Sauvegarder PostgreSQL et les fichiers

Une sauvegarde Supabase doit couvrir au moins deux ensembles : PostgreSQL et les objets de Storage.

Pour la base, automatisez des exports avec pg_dump depuis un environnement autorisé :

pg_dump -Fc -h 127.0.0.1 -U postgres -d postgres -f supabase.dump

Adaptez l’hôte à votre réseau Docker et évitez d’exposer PostgreSQL uniquement pour lancer cette commande. Vous pouvez aussi exécuter pg_dump dans le conteneur concerné. Notre guide sur PostgreSQL détaille ces commandes.

Sauvegardez séparément les volumes contenant les fichiers de Storage. Externalisez les copies vers un autre serveur ou un stockage objet indépendant. Une sauvegarde conservée uniquement sur le VPS disparaîtra avec lui en cas d’incident majeur.

Chiffrez les archives, appliquez une politique de rétention et testez régulièrement une restauration complète. Notre guide sur la stratégie de sauvegarde d’un serveur complète cette approche. Une sauvegarde non restaurée n’est pas encore une garantie de reprise.

Mettre à jour et superviser la stack

Avant une mise à jour, consultez les changements de configuration, sauvegardez les données et testez la nouvelle version sur un environnement distinct. Évitez un simple téléchargement aveugle des dernières images en production.

La supervision doit couvrir l’état des conteneurs, la RAM, le CPU, l’espace disque, les connexions PostgreSQL, les erreurs HTTP et les journaux d’authentification. Configurez des alertes avant la saturation du disque, car PostgreSQL et Storage peuvent consommer rapidement l’espace disponible.

Supabase auto-hébergé offre ainsi un backend puissant, souverain et adaptable pour une application ou un SaaS. En contrepartie, son exploitation demande une vraie discipline : secrets uniques, RLS systématique, exposition réseau minimale, sauvegardes testées et mises à jour maîtrisées.