Pourquoi auto-héberger Supabase sur un VPS
Supabase n'est pas une boîte noire : c'est un ensemble de services open source (PostgreSQL, GoTrue pour l'auth, PostgREST pour l'API, Realtime, Storage, Kong en gateway) orchestrés ensemble. La version cloud facture par projet et par utilisateur actif, et met en pause les projets gratuits inactifs. En self-hostant sur un VPS, vous obtenez un backend-as-a-service complet sans ces limites, avec un accès direct à votre PostgreSQL pour les migrations, les extensions (pgvector, PostGIS) et le tuning. C'est idéal pour une agence qui héberge plusieurs apps clientes, un SaaS en démarrage qui veut maîtriser ses coûts, ou tout projet exigeant la souveraineté des données. Vous gérez vous-même les mises à jour et la sauvegarde, en échange d'une liberté totale.
Les bénéfices concrets d'un Supabase auto-hébergé
- Backend complet : base Postgres, Auth, Storage, Realtime et API REST/GraphQL en une stack.
- Accès direct au PostgreSQL sous-jacent : migrations SQL, extensions et politiques RLS sans limite.
- Pas de mise en pause ni de facturation par utilisateur actif mensuel.
- Studio inclus : interface d'administration web pour gérer tables, auth et buckets.
- Extensions IA via
pgvectorpour le RAG et la recherche sémantique, activées librement. - Multi-projets sur un même VPS : pratique pour une agence ou un studio de développement.
Prérequis matériels et logiciels
Supabase self-hosted lance une dizaine de conteneurs (Postgres, Kong, GoTrue, PostgREST, Realtime, Storage, Studio, Meta, Imgproxy...), c'est donc une stack plus gourmande qu'une simple base. Comptez un minimum de 2 vCPU et 4 Go de RAM pour un environnement de test, et plutôt 4 vCPU avec 8 Go de RAM et 80 Go de SSD pour de la production. Côté logiciel : Ubuntu 22.04/24.04 LTS, Docker et Docker Compose v2, un nom de domaine pointant vers le VPS (ex : api.monsaas.com) pour exposer la gateway en HTTPS, et un reverse proxy comme Caddy, Traefik ou Nginx pour gérer le SSL. Prévoyez aussi de générer des secrets robustes (JWT_SECRET, clés anon et service_role).
Déployer Supabase self-hosted avec Docker
Cloner le dépôt officiel et préparer l'environnement
Récupérez le dossier docker du dépôt Supabase, copiez .env.example en .env, puis générez des secrets uniques : POSTGRES_PASSWORD, JWT_SECRET, et les clés ANON_KEY / SERVICE_ROLE_KEY dérivées du JWT. Ne déployez jamais avec les valeurs d'exemple.
Configurer les URLs et le mot de passe Studio
Dans .env, définissez SITE_URL, API_EXTERNAL_URL et SUPABASE_PUBLIC_URL avec votre domaine, et protégez Supabase Studio avec DASHBOARD_USERNAME et DASHBOARD_PASSWORD : le Studio donne un accès admin total à votre projet.
Lancer la stack
Démarrez avec docker compose up -d, puis suivez le démarrage des services via docker compose ps. La première initialisation de Postgres et l'application des migrations internes prennent une à deux minutes ; vérifiez l'absence d'erreurs dans docker compose logs.
Placer un reverse proxy avec SSL
Mettez Caddy ou Traefik devant Kong (le port 8000 de la gateway) pour exposer votre API en HTTPS. Caddy obtient et renouvelle automatiquement les certificats Let's Encrypt : un simple bloc monsaas.com { reverse_proxy localhost:8000 } suffit. N'exposez jamais Postgres (5432) publiquement.
Activer les politiques RLS
Connectez-vous au Studio, créez vos tables, puis activez Row Level Security sur chacune et définissez vos policies. Sans RLS, votre clé anon expose toutes vos données : c'est le réglage à faire avant d'exposer quoi que ce soit.
Sauvegarder Postgres et le Storage
Planifiez un pg_dump quotidien de la base et archivez le volume de Storage (buckets de fichiers) vers un stockage externe. Testez la restauration complète sur un VPS de staging avant de compter dessus en production.
Supabase vs Appwrite : quel BaaS self-hosted choisir ?
| Critère | Supabase | Appwrite |
|---|---|---|
| Base de données | PostgreSQL natif, SQL complet | MariaDB en interne, API document/collection |
| Modèle de données | Relationnel, RLS Postgres | Documents et collections, permissions par règle |
| API auto-générée | REST (PostgREST) + GraphQL | REST, GraphQL et SDK multiples |
| Authentification | GoTrue, OAuth, magic links | Auth intégrée, OAuth, équipes, JWT |
| Empreinte ressources | Plus lourde (~10 conteneurs) | Modérée, stack plus compacte |
| Recherche vectorielle / IA | Native via pgvector | Non native, à externaliser |
| Idéal pour | Apps relationnelles, RAG, SQL avancé | Apps mobiles/web orientées documents |
| Courbe d'apprentissage | Confortable si vous connaissez SQL | Rapide pour les développeurs front/mobile |
Mettez à jour Supabase avec prudence : les images étant versionnées dans le docker-compose.yml, faites toujours un pg_dump complet et un snapshot du VPS avant un docker compose pull && docker compose up -d. Certaines montées de version touchent au schéma interne des services. Pour la production, isolez Postgres sur un volume dédié à fort IOPS et activez pgvector dès le départ si vous prévoyez de la recherche sémantique : l'ajouter plus tard impose une migration de schéma.
Déployez à partir de la stack officielle de Supabase, pas d'un compose fait maison
Il est tentant d'écrire un docker-compose minimal avec seulement les quelques services dont vous avez besoin. En pratique, cela casse : l'image supabase/postgres exécute son propre script de migration (migrate.sh) qui provisionne les rôles de base (supabase_admin, authenticator, supabase_auth_admin...) et l'intégralité du schéma d'authentification, et elle attend la présence des fichiers SQL d'initialisation de Supabase montés comme fichiers, avec expansion des variables à l'exécution. Un compose inline autonome ne peut pas reproduire cela (Docker Compose interpole les variables à l'intérieur des configurations inline, laissant le schéma d'authentification à moitié migré et GoTrue échouer avec 'must be owner of function auth.uid()'). L'approche robuste — celle qu'utilise ServOrbit — consiste à déployer les fichiers Docker officiels de Supabase, figés sur une version précise, et à laisser son migrate.sh faire l'amorçage exactement comme le prévoit l'upstream.
CVE-2026-31813 : faille OIDC dans GoTrue — mettez à jour
En juillet 2026, une vulnérabilité a été divulguée dans GoTrue (le service d'authentification de Supabase) sous la référence CVE-2026-31813. La faille se situe dans la validation du claim iss lors de l'authentification OIDC : un token JWT signé par un fournisseur d'identité tiers (Google, GitHub, Azure) mais avec un iss différent de celui configuré dans GoTrue était accepté dans certaines conditions de configuration.
En pratique, un attaquant qui contrôle un fournisseur OIDC enregistré dans l'application cliente peut émettre des tokens valides pour des utilisateurs arbitraires de votre instance Supabase. La portée réelle dépend de la configuration : seules les instances avec au moins un fournisseur OAuth tiers activé (Social Auth) sont concernées. Les instances qui utilisent uniquement l'authentification email/mot de passe ou les magic links ne sont pas exposées.
Le correctif est inclus dans gotrue v2.170.0, lui-même intégré à supabase/supabase v1.67.0. Pour vérifier votre version : docker compose exec auth gotrue version. Si votre version de gotrue est antérieure à 2.170.0, mettez à jour immédiatement.
Mettre à jour GoTrue pour corriger CVE-2026-31813
Identifier la version en cours
Depuis le répertoire de votre stack Supabase : docker compose exec auth gotrue version. Si la sortie indique une version < 2.170.0, votre instance est exposée au CVE-2026-31813. Notez également la version globale de la stack : grep 'SUPABASE_VERSION' .env (si vous l'avez épinglée) ou docker compose images | grep supabase.
Sauvegarder avant la mise à jour
Avant toute mise à jour, sauvegardez la base : docker compose exec db pg_dumpall -U postgres > /tmp/supabase-backup-$(date +%F).sql. La mise à jour de GoTrue n'implique pas de migration de schéma PostgreSQL, mais une sauvegarde préalable reste la règle avant tout changement de version en production.
Mettre à jour vers supabase/supabase v1.67.0+
Dans votre docker-compose.yml, mettez à jour le tag de l'image supabase/gotrue vers v2.170.0 ou plus récent, ou si vous suivez la stack globale, tirez la dernière version compatible : docker compose pull && docker compose up -d auth. La mise à jour de GoTrue seul ne nécessite pas de redémarrer les autres services. Vérifiez avec docker compose exec auth gotrue version que la nouvelle version est active.
Vérifier l'authentification OIDC
Après la mise à jour, testez un flux d'authentification complet avec chaque fournisseur OIDC configuré (Google, GitHub, etc.) : connexion, déconnexion, reconnexion. Vérifiez dans les logs GoTrue (docker compose logs auth) qu'aucun message d'erreur relatif à la validation iss n'apparaît en conditions normales d'utilisation.
Désactiver temporairement le Social Auth si vous ne pouvez pas mettre à jour immédiatement
Si une mise à jour immédiate n'est pas possible (fenêtre de maintenance requise), vous pouvez réduire la surface d'exposition en désactivant temporairement les fournisseurs OAuth tiers dans le Studio Supabase : Authentication → Providers, puis désactivez chaque fournisseur Social. L'authentification email/mot de passe reste fonctionnelle. Ce contournement est temporaire : il ne corrige pas la faille, il réduit seulement la surface d'attaque pendant que vous préparez la mise à jour.
