Vos données clients hébergées chez vous plutôt que dans un datacenter à l'autre bout du monde : c'est possible.
Supabase Cloud est parfait pour démarrer, mais au-delà d'un certain volume la facture grimpe et vos données quittent votre infrastructure. Le self-hosting résout les deux problèmes : Supabase est 100% open source, et une instance Supabase self-hosted se déploie en une poignée de commandes Docker. Résultat : vos données restent chez vous et, à grande échelle, la facture devient fixe et prévisible.
Dans cet article, vous allez découvrir :
- •Pourquoi héberger Supabase soi-même renforce la souveraineté de vos données et votre conformité RGPD
- •Comment lancer la stack complète avec Docker Compose en moins de 30 minutes
- •Les 4 contraintes de maintenance que personne ne vous explique avant de vous lancer
- •La grille de décision cloud vs self-hosted pour trancher sans regret
- •La checklist en 7 points à valider avant de passer votre Supabase self-hosted en production
Supabase est distribué sous licence Apache 2.0 : vous pouvez l'héberger où vous voulez, sans limite d'usage et sans royalties.
Pourquoi héberger Supabase soi-même
Le self-hosting n'est pas un caprice de puriste. C'est une décision stratégique qui répond à trois besoins concrets : la souveraineté, la conformité et le coût.
Souveraineté des données
Quand vous utilisez Supabase Cloud, vos données vivent sur une infrastructure gérée par un tiers. En self-hosting, la base PostgreSQL, les fichiers Storage et les logs restent sur votre serveur, dans le pays et le datacenter de votre choix.
Pour un secteur régulé (santé, finance, secteur public), c'est souvent non négociable. Vous gardez la main sur qui accède physiquement à la machine et sur la localisation exacte des données.
Conformité RGPD
Héberger en Europe, sur un serveur que vous contrôlez, simplifie radicalement votre analyse RGPD. Pas de transfert hors UE à justifier, pas de sous-traitant supplémentaire à cartographier dans votre registre des traitements.
Vous maîtrisez le chiffrement au repos, la durée de rétention et les procédures de suppression. C'est un argument fort face à un DPO ou lors d'un audit.
Contrôle des coûts à grande échelle
Supabase Cloud facture la base active, le stockage, la bande passante et les Edge Functions. Tant que vous êtes petit, c'est imbattable. Mais quand le trafic explose, le modèle par usage peut devenir cher.
En self-hosting, vous payez un serveur à prix fixe. Un VPS costaud ou une machine dédiée coûte quelques dizaines à quelques centaines d'euros par mois, quel que soit le nombre de requêtes. Pour comprendre où bascule l'équilibre, notre article sur les prix et tarifs de Supabase détaille chaque poste de facturation du cloud. Si c'est surtout la base PostgreSQL que vous voulez externaliser à prix serré, notre comparatif Supabase vs Neon éclaire une troisième voie.
Pour tout comprendre de la plateforme avant de vous lancer, consultez aussi notre guide complet sur Supabase.
Comment héberger Supabase avec Docker
Supabase n'est pas un logiciel unique : c'est un ensemble de services open source orchestrés ensemble. La méthode officielle de self-hosting repose sur Docker Compose, qui lance tous ces services d'un coup.
Prérequis : quel serveur pour Supabase self-hosted
Avant de lancer la moindre commande, il faut une machine correctement dimensionnée. PostgreSQL, Kong, Realtime et Storage tournent en parallèle et consomment de la mémoire dès le démarrage.
| Usage | RAM | CPU | Disque |
|---|---|---|---|
| Test et développement | 4 Go | 2 vCPU | 40 Go SSD |
| Petite production | 8 Go | 4 vCPU | 80 Go SSD |
| Production avec trafic | 16 Go et plus | 4 à 8 vCPU | 160 Go SSD et plus, sauvegardes externes |
Les services à lancer
Voici les briques que compose Supabase et leur rôle. Comprendre ce découpage est essentiel pour diagnostiquer un problème plus tard.
| Service | Rôle | Image Docker |
|---|---|---|
| PostgreSQL | Base de données (le cœur) | supabase/postgres |
| Auth (GoTrue) | Authentification et gestion des utilisateurs | supabase/gotrue |
| PostgREST | API REST auto-générée depuis le schéma SQL | postgrest/postgrest |
| Realtime | Websockets et écoute des changements en temps réel | supabase/realtime |
| Storage | Stockage de fichiers avec règles d'accès | supabase/storage-api |
| Kong | Passerelle API qui route et sécurise le trafic | kong |
| Studio | Interface d'administration graphique | supabase/studio |
| Edge Functions | Exécution de fonctions Deno | supabase/edge-runtime |
| Supavisor | Pooler de connexions PostgreSQL | supabase/supavisor |
Docker Compose en pratique
Le démarrage tient en quelques commandes. Vous clonez le dépôt officiel, copiez le fichier d'environnement, puis lancez la stack.
git clone --depth 1 https://github.com/supabase/supabase
cd supabase/docker
cp .env.example .env
docker compose up -dUne fois la stack lancée, le Studio est accessible sur le port configuré et l'API passe par Kong. Avant toute mise en production, trois réglages sont impératifs :
- •Remplacer tous les secrets par défaut du fichier
.env(mots de passe Postgres, clés JWT, identifiants du dashboard) - •Placer un reverse proxy (Nginx, Caddy, Traefik) devant Kong pour gérer le HTTPS
- •Restreindre l'accès au Studio (VPN, authentification, filtrage IP)
La logique de sécurité applicative reste la même que sur le cloud. Vos règles d'accès aux données s'appuient toujours sur le Row Level Security de Supabase, à activer sur chaque table sensible.
GoTrue en self-hosting : les réglages Auth qui changent
GoTrue est le service d'authentification de Supabase. Sur le cloud, il est préconfiguré ; en self-hosting, quatre points sont à votre charge dans le fichier .env :
- •SMTP : sans serveur mail configuré, aucun e-mail de confirmation, de magic link ou de réinitialisation de mot de passe ne part. Renseignez un fournisseur transactionnel (Brevo, Postmark, Resend) et vérifiez l'expéditeur.
- •SITE_URL et redirections autorisées : l'URL publique de votre application doit être déclarée, sinon les liens de confirmation renvoient vers localhost.
- •JWT_SECRET : il signe tous les tokens. Il doit être régénéré (au moins 32 caractères) et partagé à l'identique avec PostgREST et Realtime, faute de quoi l'API refuse les requêtes authentifiées. Les clés anon et service_role doivent ensuite être générées à partir de ce nouveau secret.
- •Fournisseurs OAuth : chaque connexion Google, GitHub ou Apple doit être déclarée avec ses identifiants et son URL de callback pointant vers votre domaine.
La logique côté application ne change pas : notre guide Supabase Auth reste valable, seules les variables d'environnement diffèrent.
L'alternative Coolify pour éviter le Docker Compose brut
Si vous ne voulez pas maintenir le fichier Compose à la main, Coolify (open source) propose Supabase en un clic sur votre propre VPS : il génère les secrets, place un reverse proxy HTTPS (Traefik par défaut) devant la stack et gère les redémarrages. Vous gardez la souveraineté des données, avec une couche d'exploitation plus confortable.
Le revers : une dépendance à un outil supplémentaire à mettre à jour, et une personnalisation plus limitée que le Compose officiel. Pour une équipe sans DevOps, c'est souvent le bon compromis ; pour une production exigeante, le Compose officiel reste la référence.
Les contraintes du self-hosting à anticiper
Héberger soi-même, c'est reprendre à sa charge tout ce que Supabase Cloud gère silencieusement pour vous. Voici les quatre chantiers à ne jamais négliger.
Maintenance et supervision
Un serveur qui héberge une base de production doit être surveillé : espace disque, mémoire, charge CPU, disponibilité des conteneurs. Il faut mettre en place du monitoring (uptime, alertes) et savoir intervenir quand un service tombe.
Sauvegardes
Sur le cloud, les backups sont automatiques. En self-hosting, c'est à vous de les configurer. Un pg_dump planifié ne suffit pas toujours : pour un vrai plan de reprise, il faut du Point-in-time Recovery et un stockage des sauvegardes hors du serveur principal. Une sauvegarde qui vit sur la même machine que la base ne protège de rien.
Mises à jour
Les images Supabase évoluent vite et chaque service a son propre rythme de version. Une montée de version mal coordonnée peut casser la compatibilité entre PostgREST, GoTrue et votre schéma. La procédure sûre tient en cinq étapes :
- 1.Sauvegarder la base (
pg_dump) et le volume Storage, puis vérifier que la restauration fonctionne - 2.Lire les notes de version du dépôt
supabase/supabasepour repérer les changements de variables d'environnement - 3.Récupérer le nouveau fichier Compose et comparer votre
.envavec le.env.examplemis à jour - 4.Appliquer la mise à jour sur un environnement de préproduction identique, puis lancer vos tests d'authentification et d'API
- 5.Déployer en production avec
docker compose pullpuisdocker compose up -d, en surveillant les logs des conteneurs pendant les premières minutes
Une mise à jour par trimestre, planifiée et testée, vaut mieux qu'un docker compose pull improvisé un vendredi soir.
Sécurité
Vous devenez responsable du durcissement du serveur : pare-feu, HTTPS, rotation des secrets, mises à jour de l'OS, isolation réseau des conteneurs. Un Supabase self-hosted mal sécurisé, exposé directement sur Internet avec les secrets par défaut, est une porte ouverte.
La règle d'or : ne mettez jamais un Supabase self-hosted en production sans reverse proxy HTTPS, secrets régénérés et sauvegardes externalisées testées.
Cloud vs self-hosted : la grille de décision
La vraie question n'est pas laquelle des deux options est la meilleure, mais laquelle correspond à votre contexte. Ce tableau résume les arbitrages.
| Critère | Supabase Cloud | Self-hosted |
|---|---|---|
| Mise en route | Immédiate | Quelques heures à quelques jours |
| Souveraineté des données | Datacenters au choix | Totale, chez vous |
| Coût à petite échelle | Gratuit puis faible | Coût serveur fixe + temps humain |
| Coût à grande échelle | Peut devenir élevé | Maîtrisé et prévisible |
| Maintenance | Gérée par Supabase | Entièrement à votre charge |
| Sauvegardes | Automatiques | À configurer et externaliser |
| Point-in-time Recovery | Inclus (plans payants) | À mettre en place soi-même |
| Support | Équipe Supabase | Communauté ou prestataire |
Checklist avant de mettre Supabase self-hosted en production
- •Tous les secrets du
.envrégénérés (mot de passe Postgres, JWT_SECRET, clés anon et service_role, identifiants du Studio) - •Reverse proxy HTTPS devant Kong, avec renouvellement automatique du certificat
- •Studio inaccessible depuis Internet (VPN, filtrage IP ou authentification forte)
- •Row Level Security activée sur chaque table exposée via l'API
- •Sauvegardes quotidiennes externalisées sur un autre hébergeur ou un stockage objet, avec un test de restauration réalisé
- •Monitoring en place : disponibilité, espace disque, mémoire, alertes sur les conteneurs arrêtés
- •Procédure de mise à jour écrite et testée sur une préproduction
Si un seul de ces points manque, vous n'êtes pas encore prêt pour la production.
L'accompagnement ONDEV pour votre Supabase self-hosted
Chez ONDEV, notre activité de développement d'applications web sur-mesure s'appuie sur Next.js et Supabase, en cloud comme en self-hosting. Nous savons donc quand chaque option a du sens, et surtout comment sécuriser un déploiement auto-hébergé.
Concrètement, nous prenons en charge le déploiement Docker complet, le durcissement du serveur, la mise en place des sauvegardes automatisées et externalisées, le monitoring et la stratégie de mises à jour. Vous gardez la souveraineté, sans porter seul la charge d'exploitation.
Vous avez déjà un Supabase auto-hébergé qui tourne ? Un audit de code et d'architecture vérifie les secrets, les sauvegardes, les policies RLS et la stratégie de mise à jour, avant qu'un incident ne le fasse pour vous.
C'est le savoir-faire que nous appliquons sur des produits réels comme Wiloq, notre application SaaS de vestiaire numérique, un produit en production sur Next.js et Supabase avec plus de 12 fonctionnalités et 3 interfaces. Nous connaissons aussi les contraintes du self-hosting en entreprise : l'application technique auto-hébergée que nous avons livrée à SNEF sur Next.js et PostgreSQL fait gagner 1 h 30 tous les deux jours à chaque chef de chantier, avec un déploiement en self-hosting qui garantit la souveraineté des données.
Vous hésitez entre cloud et self-hosting pour votre projet ? Notre agence Supabase vous aide à trancher et à déployer la bonne architecture dès le départ.
FAQ : héberger Supabase soi-même
Supabase est-il vraiment gratuit en self-hosting ?
Quel serveur faut-il pour héberger Supabase ?
Qu'est-ce que GoTrue dans Supabase et faut-il le configurer en self-hosting ?
Peut-on installer Supabase self-hosted avec Coolify plutôt qu'avec Docker Compose ?
Comment mettre à jour un Supabase self-hosted sans casser la production ?
Supabase self-hosted offre-t-il les mêmes fonctionnalités que Supabase Cloud ?
Peut-on migrer de Supabase Cloud vers un serveur self-hosted ?
Le self-hosting garantit-il la conformité RGPD ?
Conclusion : la souveraineté a un prix, ONDEV le rend accessible
Héberger Supabase soi-même, c'est reprendre le contrôle total de vos données et de vos coûts, au prix d'une charge d'exploitation réelle : maintenance, sauvegardes, mises à jour et sécurité. Le cloud reste idéal pour démarrer vite ; le self-hosting brille dès que la souveraineté ou l'échelle entrent en jeu.
Le bon choix dépend de votre contexte, et une erreur d'architecture au départ coûte cher à corriger. Vous voulez un déploiement Supabase self-hosted fiable, sécurisé et conforme, sans y passer vos nuits ? Discutons de votre projet avec ONDEV : nous concevons et exploitons la bonne stack pour vous.
