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 se déploie en une poignée de commandes Docker. Résultat, à grande échelle, certaines équipes divisent leur facture par 3.
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
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.
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.
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 coeur) | 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.
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. Chaque service a son rythme de version, et une mise à jour mal coordonnée peut casser la compatibilité entre PostgREST, GoTrue et le schéma. Il faut tester les montées de version sur un environnement de préproduction avant de toucher à la production.
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 |
L'accompagnement ONDEV pour votre Supabase self-hosted
Chez ONDEV, nous concevons des applications 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.
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.
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 ?
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.
