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.ma) 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.ma { 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 point de sécurité numéro un d'un Supabase self-hosted.
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.
