Comment auto-héberger Supabase sur un VPS

Vous utilisez Supabase Cloud depuis quelques mois, et la facture ne cesse de grimper.

Chaque octet supplémentaire de trafic sortant de la base de données ajoute une ligne à la facture. Chaque tranche de 10 000 utilisateurs actifs mensuels vous rapproche d'un dépassement.

L'offre Pro, qui démarrait à 25 $ par mois, tourne désormais plutôt autour de 70 $.

Quelque part entre la page des tarifs et votre facture réelle, l'affaire a cessé de paraître si avantageuse.

L'auto-hébergement est l'alternative évidente, mais évidente, c'est vite dit. Supabase n'est pas un simple binaire que vous déposez sur un serveur. C'est une pile backend complète (une base de données Postgres, un service d'authentification, une API REST, des abonnements en temps réel, du stockage, des fonctions edge et un tableau de bord), le tout interconnecté et exécuté sous la forme d'une petite flotte de conteneurs Docker.

Faire tourner cette flotte sur votre propre serveur coûte environ 23 à 35 $ par mois avec Stack 16 (22,99 $/mois les 3 premiers mois avec l'engagement mensuel, puis 34,99 $/mois) pour un VPS doté d'assez de RAM pour tout garder en mémoire. C'est le prix de deux abonnements de streaming par mois pour un backend qui ne vous facturera pas de supplément lors des pics de trafic.

Qu'est-ce que Supabase et pourquoi l'auto-héberger ?

Supabase est une plateforme open source de Backend as a Service (BaaS) qui regroupe une base de données Postgres, l'authentification, une API REST, des abonnements en temps réel, du stockage et des fonctions edge dans un seul déploiement.

C'est l'alternative à Firebase qui peut tourner sur votre propre infrastructure, si vous le souhaitez. Le dépôt GitHub a dépassé les 100 000 étoiles en mai 2026, et la plateforme fait tourner les backends d'entreprises comme Mozilla, PwC, Johnson & Johnson et 1Password.

La question est de savoir si vous voulez prendre en charge le travail d'exploitation que Supabase Cloud gère pour vous, ou payer quelqu'un d'autre pour le faire. On parle de sauvegardes, de journaux, d'envoi d'e-mails et de mises à jour.

Les gens auto-hébergent Supabase pour trois raisons :

1. Ils veulent des coûts prévisibles, qui n'augmentent pas avec l'utilisation.
2. Ils veulent que leurs données soient hébergées sur une infrastructure qu'ils contrôlent.
3. Ils veulent échapper au piège de la dépendance envers un fournisseur, qui a rendu Firebase si difficile à quitter.

Supabase se montre d'une franchise rafraîchissante sur qui devrait, ou non, opter pour l'auto-hébergement. La documentation officielle sur l'auto-hébergement le dit clairement : Self-hosted Supabase is community-supported. You won’t receive the same level of official support as Supabase Cloud customers.

Autrement dit : si quelque chose plante à 2 h du matin, vous êtes seul.

Ce que Supabase vous offre vraiment, prêt à l'emploi

Si vous pensiez que Supabase n'était qu'un Postgres doté d'une API REST, détrompez-vous. La pile auto-hébergée fait tourner environ 12 conteneurs en parallèle.

Les composants que vous manipulerez le plus souvent sont assez simples :

• Postgres. La base de données au cœur de tout. Supabase utilise une version moderne de PostgreSQL avec des extensions pour l'authentification, le temps réel et la recherche plein texte.
• PostgREST. Génère automatiquement une API REST à partir de votre schéma Postgres. Une table devient un point de terminaison, sans que vous ayez à écrire la moindre ligne de code backend.
• Auth (anciennement GoTrue). Gère les inscriptions, les connexions, les réinitialisations de mot de passe, OAuth et l'émission de JWT.
• Realtime. Transmet les modifications de la base de données aux clients connectés via WebSockets.
• Storage. Stockage objet compatible S3, avec un contrôle d'accès lié à votre base de données.
• Edge Functions. Fonctions serverless basées sur Deno, exécutées au plus près de vos utilisateurs.
• Supabase Studio. Le tableau de bord où vous parcourez les tables, exécutez du SQL et gérez les utilisateurs de l'authentification.

Vous disposez aussi de Kong comme passerelle d'API, d'imgproxy pour le traitement des images, de Supavisor pour le pooling de connexions et de Logflare pour l'analytique. Au total, il s'agit d'une pile backend complète, pas d'une simple application.

Combien coûte l'auto-hébergement de Supabase ?

Auto-héberger Supabase sur un VPS coûte environ 23 à 35 $ par mois avec Stack 16, serveur, stockage et bande passante compris. Le logiciel Supabase lui-même est gratuit.

Ressortez votre dernière facture Supabase Cloud un instant. La ligne qui prend les gens par surprise n'est pas le forfait de base de 25 $. Ce sont le trafic sortant de la base de données et le stockage supplémentaire, que l'offre Pro facture séparément (l'analyse des coûts 2026 de Supascale détaille chaque ligne).

Comparez avec Supabase Cloud :

Le prix de base de l'offre Pro semble comparable, mais l'utilisation réelle le fait vite grimper.

Selon l'analyse de Supascale, la plupart des applications en production de petite à moyenne taille finissent à 100 à 200 $/mois sur l'offre Pro une fois les modules de calcul et les dépassements d'utilisation pris en compte ; à eux seuls, les niveaux de calcul de Supabase vont de 10 $/mois jusqu'à 3 730 $/mois pour l'instance 16XL. Les applications comptant 100 000 à 200 000 utilisateurs actifs mensuels peuvent largement dépasser ce montant, et à 500 000 MAU, la facture peut atteindre 1 000 à 2 000 $/mois.

L'offre gratuite est gratuite… jusqu'à ce que vous essayiez de l'utiliser en production.

Les projets se mettent automatiquement en pause après sept jours d'inactivité : votre environnement de préproduction s'éteint chaque semaine et vos projets perso cessent de fonctionner dès que vous partez en vacances. D'après l'analyse des tarifs 2026 d'UI Bakery, c'est la raison la plus courante pour laquelle on quitte l'offre gratuite plus tôt que prévu.

L'auto-hébergement inverse la logique. Vos coûts dépendent de votre infrastructure, pas de votre utilisation. Gérer 50 000 MAU coûte autant que 500 000, dans la seule limite de ce que votre VPS peut encaisser. Pas de frais de trafic sortant, pas de dépassement de stockage, pas de modules de calcul.

L'auto-hébergement ne se résume pas à la facture du VPS

La facture du VPS n'est pas le seul coût de l'auto-hébergement. Vous paierez aussi d'autres façons :

• Votre temps. Prévoyez une à deux heures par mois pour la maintenance courante : mises à jour de sécurité, récupération des images Docker, vérification des journaux et contrôle des sauvegardes. Comptez davantage si vous ajoutez des fonctionnalités ou montez en charge.
• L'envoi d'e-mails. Supabase Cloud prend en charge pour vous les e-mails d'authentification (réinitialisation de mot de passe, liens magiques, vérification d'adresse e-mail, etc.) sous forme de service géré. Ce n'est pas le cas de la version auto-hébergée. Il vous faudra un fournisseur SMTP comme SendGrid, Mailgun ou AWS SES. Prévoyez de 0 à 30 $/mois selon le volume.
• Le stockage objet pour les fichiers. Par défaut, le service Storage utilise le système de fichiers local, ce qui convient pour les tests, mais devient une bombe à retardement en production. Il vous faudra un stockage objet compatible S3 : AWS S3, Backblaze B2, Wasabi ou tout autre service compatible S3 fera l'affaire. Comptez 5 à 20 $/mois pour une application en production de petite à moyenne taille.
• L'infrastructure de sauvegarde. L'auto-hébergement ne comprend pas de sauvegardes automatiques : vous devrez les mettre en place vous-même. Écrivez un cron job simple pg_dump et stockez le résultat dans un endroit fiable. Ne faites pas l'impasse sur cette étape : vous vous en remercierez plus tard.

Quelle configuration serveur faut-il pour Supabase ?

Supabase est gourmand en mémoire. Avec 12 conteneurs exécutés simultanément, la plupart liés à la base de données, la RAM compte davantage que le processeur. Le minimum pratique est de 4 Go pour une instance de développement dont les services optionnels sont désactivés. Les déploiements en production demandent 8 Go ou plus.

La raison tient au nombre de conteneurs, pas à un service en particulier. Postgres veut des tampons partagés. PostgREST veut un pool de connexions. GoTrue a besoin d'une petite empreinte pour le runtime Go. Realtime maintient des connexions WebSocket ouvertes. Edge Runtime lance des isolats V8.

Pris isolément, chaque service est modeste. Ensemble, ils pèsent vite lourd.

Si vous n'avez jamais provisionné de VPS, commencez par notre guide du VPS pour débutants avant de dimensionner votre serveur.

Chez DreamHost, Stack 16 (4 vCPU, 16 Go de RAM, 250 Go de SSD NVMe, accès root complet) est la plus petite offre qui atteint les 4 cœurs et 8 Go recommandés par Supabase pour un déploiement exécutant tous les services optionnels. Stack 8 atteint la mémoire et l'espace disque recommandés avec 2 vCPU et convient à une petite application ou à un environnement de préproduction.

Quelle taille de VPS faut-il pour Supabase ?

Vous pouvez aussi retirer des services optionnels du fichier Docker Compose pour réduire l'empreinte.

Pas besoin d'abonnements en temps réel ? Supprimez le conteneur Realtime.

Vous n'utilisez pas les Edge Functions ? Retirez Edge Runtime.

L'analytique n'est pas essentielle ? Supprimez Logflare.

Une pile allégée peut tenir plus confortablement sur un VPS de 4 Go.

Le stockage NVMe compte plus que vous ne le pensez. Postgres lit et écrit en permanence, et la latence du SSD influe directement sur la vitesse des requêtes. Les anciens disques SATA ou les disques durs à plateaux vous ralentiront bien avant que la base de données devienne intéressante.

Comment se déroule l'installation de Supabase auto-hébergé ?

Le déploiement complet compte environ cinq étapes et prend une à deux heures si vous êtes à l'aise avec un terminal.

Voici ce que vous devez faire :

1. Provisionnez un VPS sous Ubuntu 22.04 ou plus récent, avec 8 Go de RAM et un accès SSH.
2. Installez Docker et Docker Compose sur le serveur.
3. Clonez le dépôt Supabase et copiez le fichier d'environnement d'exemple : git clone https://github.com/supabase/supabase && cp supabase/docker/.env.example supabase/docker/.env
4. Générez et définissez les secrets. Exécutez le script generate-keys.sh de Supabase pour produire vos JWT_SECRET, ANON_KEY et SERVICE_ROLE_KEY, puis définissez POSTGRES_PASSWORD et les identifiants du tableau de bord dans le fichier .env.
5. Exécutez docker compose up -d depuis le répertoire docker : toute la pile démarre.

Vous saurez que tout fonctionne quand docker compose ps affichera chaque service à l'état running ou healthy, et que curl http://localhost:8000/rest/v1/ renverra une réponse JSON de PostgREST.

Si un conteneur est à l'état restarting ou exited, consultez d'abord ses journaux. Postgres est le coupable habituel, et la cause est généralement une variable d'environnement manquante ou mal formée.

La documentation officielle de Supabase sur l'auto-hébergement avec Docker détaille chaque variable d'environnement.

Kong, la passerelle d'API, se place devant tout le reste et gère le routage. En production, vous placerez généralement devant Kong un proxy inverse (un serveur situé entre Internet et votre application, qui gère le SSL et le routage) comme Caddy ou Nginx, afin de terminer le HTTPS et de restreindre l'accès au tableau de bord.

Enregistrez vos JWT_SECRET, ANON_KEY et SERVICE_ROLE_KEY dans un endroit fiable dès leur génération. Les perdre n'a rien de catastrophique, puisque vous pouvez les régénérer, mais leur rotation fait expirer toutes les sessions utilisateur actives et oblige chaque application cliente à obtenir de nouvelles clés.

Ce qu'il vous faut pour auto-héberger Supabase

• Un VPS sous Ubuntu 22.04+ avec au moins 8 Go de RAM et un accès root/SSH
• Un nom de domaine pointant vers l'adresse IP de votre serveur
• Docker et Docker Compose installés
• Un fournisseur SMTP configuré pour les e-mails d'authentification (SendGrid, Mailgun, AWS SES)
• Un stockage objet compatible S3 pour les envois de fichiers en production (facultatif, mais recommandé)
• Une aisance de base avec le terminal et environ une à deux heures

Comment sécuriser une instance Supabase auto-hébergée ?

La sécurité de Supabase auto-hébergé repose sur trois piliers propres à la plateforme, en plus de l'hygiène habituelle d'un VPS.

Le secret JWT

Chaque jeton d'autorisation émis par Supabase est signé avec votre JWT_SECRET. S'il fuite, des attaquants peuvent forger des jetons pour usurper l'identité de n'importe quel utilisateur.

La documentation de Supabase sur la sécurité des jetons explique le fonctionnement : A shared secret that is in the hands of a malicious actor can be used to impersonate your users [and] give them access to privileged actions or data, and it is difficult to detect or identify when or how a shared secret has been given to a malicious actor.

Traitez le JWT_SECRET comme un mot de passe de base de données de production, car, dans les faits, c'est exactement ce qu'il est. Stockez-le dans un gestionnaire de secrets, pas dans un fichier .env versionné dans Git, et jamais dans votre bundle frontend.

En production, la voie recommandée consiste à utiliser des clés de signature asymétriques (RS256 ou ECC). Elles risquent moins de fuiter par accident qu'un secret partagé, et Supabase prend en charge les deux.

Sécurité au niveau des lignes (RLS)

Le service PostgREST de Supabase expose chaque table de votre base de données sous forme de point de terminaison REST.

Sans politiques Row Level Security sur chaque table, tout utilisateur authentifié peut lire et modifier chaque ligne. C'est de loin l'erreur la plus courante chez les débutants en auto-hébergement.

Activez RLS sur chaque table dès le premier jour, y compris sur celles qui, selon vous, n'en ont pas besoin.

Clé du rôle de service

SERVICE_ROLE_KEY est une clé de super-administrateur qui contourne entièrement la Row-Level Security.

Elle est destinée aux appels entre backends, lorsque vous devez explicitement ignorer les autorisations au niveau utilisateur. Cette clé ne doit jamais apparaître dans du code frontend, dans des dépôts publics ou dans des bundles d'applications clientes. En cas de fuite, c'est toute votre base de données qui est exposée.

Au-delà des aspects propres à Supabase, les règles habituelles de sécurisation d'un serveur s'appliquent. Activez un pare-feu qui n'expose que les ports 22 (SSH), 80 (HTTP) et 443 (HTTPS). Placez tout derrière un proxy inverse en HTTPS. Limitez l'accès à Supabase Studio à des adresses IP connues et maintenez le serveur à jour. Nos conseils de sécurité cloud couvrent la liste de contrôle générale de sécurisation : n'hésitez pas à y jeter un œil.

Dernier point : la rotation du secret JWT invalide immédiatement toutes les sessions utilisateur actives. Prévoyez une fenêtre de maintenance et n'effectuez pas la rotation un vendredi après-midi, sinon vous allez passer un sale quart d'heure.

Supabase auto-hébergé ou Supabase Cloud : quels compromis ?

Supabase auto-hébergé et Supabase Cloud ne sont pas interchangeables. Chacun l'emporte sur des critères différents.

L'auto-hébergement est judicieux quand la prévisibilité des coûts compte plus que le confort d'un service géré, quand vos données doivent se trouver physiquement sur une infrastructure que vous contrôlez, ou quand vous gérez plusieurs projets qui coûteraient chacun plus de 25 $ par mois sur Cloud.

Cloud l'emporte quand vos ressources d'exploitation sont limitées et que les sauvegardes automatisées et une disponibilité garantie par un SLA sont non négociables. C'est aussi un bon choix quand votre équipe est petite et que le calcul du coût total de possession penche réellement en faveur de l'hébergement géré.

Il existe aussi un juste milieu.

Des outils comme Coolify, Dokploy et Railway peuvent déployer et gérer Supabase sur votre VPS, en prenant en charge les mises à jour, les sauvegardes et une partie de l'observabilité, sans passer par une configuration Docker Compose entièrement manuelle.

En clair, vous profitez de l'essentiel des économies de l'auto-hébergement avec moins de charge d'exploitation. Aucun de ces outils n'égale la finition du tableau de bord de Cloud, mais tous coûtent moins cher que Cloud à grande échelle.

Faut-il vraiment auto-héberger Supabase ?

Auto-héberger Supabase est moins une décision financière qu'une décision opérationnelle.

Le VPS ne coûte pas cher. Ce à quoi vous vous engagez vraiment, c'est à prendre en charge les sauvegardes, les journaux et toute la tuyauterie des e-mails d'authentification. Pour la plupart des petites équipes, ce compromis n'a de sens que lorsque les tarifs de Cloud commencent à faire mal ou lorsque la résidence des données passe du statut de simple bonus à celui d'exigence.

Si vous n'êtes pas prêt pour une configuration entièrement manuelle, des outils comme Coolify et Dokploy offrent un compromis. Ils gèrent la pile sur votre VPS avec moins de charge que Docker Compose seul, et pour moins cher que Cloud une fois que vous montez en charge.

Le premier mois d'auto-hébergement est le plus difficile. Vous ajusterez des limites de ressources dont vous ignoriez l'existence, découvrirez des pannes que personne n'a documentées et rédigerez le guide d'exploitation que vous auriez aimé recevoir.

Du deuxième au douzième mois, tout se calme. Vous récupérez les mises à jour avec Docker Compose, lancez chaque nuit un pg_dump vers S3, et votre facture reste stable.

Le meilleur moyen de savoir dans quel camp vous êtes : lancez un Stack 4 (8,99 $/mois pendant les 3 premiers mois avec l'engagement mensuel), faites tourner une instance Supabase hors production pendant une semaine et laissez l'expérience trancher pour vous.

Les chiffres vous diront le reste.

Questions fréquentes sur l'auto-hébergement de Supabase