Qu'est-ce qu'un BaaS et pourquoi l'auto-héberger ?
Un Backend-as-a-Service (BaaS) regroupe dans un seul produit tout ce qu'une application moderne exige côté serveur : base de données, authentification, stockage de fichiers, fonctions serverless et communication temps réel. Firebase a popularisé ce modèle, mais sa nature propriétaire pose des problèmes de coût, de conformité RGPD et de vendor lock-in.
Auto-héberger un BaaS open source sur votre propre VPS vous donne un contrôle total sur vos données, élimine les frais par requête et vous permet de respecter les exigences de localisation des données. La contrepartie est la gestion de l'infrastructure : mises à jour, sauvegardes, monitoring et dimensionnement du serveur vous incombent. Supabase et Appwrite sont les deux solutions les plus matures dans cet espace.
Comparatif Supabase vs Appwrite — 12 critères
Faites défiler le tableau
| Critère | Supabase | Appwrite |
|---|---|---|
| Base de données | PostgreSQL | PostgreSQL par défaut depuis 2.0 (MariaDB et MongoDB disponibles) |
| RAM minimum | 4 Go | 4 Go (+ 2 Go de swap) |
| RAM production recommandée | 8 Go et plus | Non publiée (4 Go minimum) |
| Nombre de conteneurs | ~11 (13 avec Logflare et Vector) | ~18 |
| Port principal | 8000 (Envoy depuis 0.8.0, Kong avant) | 80 / 443 (Traefik) |
| Port admin | 8000 (Studio via le gateway, auth basique) | 80 / console (Traefik) |
| Services inclus | Auth, PostgREST, Realtime, Storage, Edge Functions, Studio | Auth, Databases, Storage, Functions, Messaging, Realtime |
| Auth providers | 15+ | 30+ |
| Functions runtime | Deno uniquement | 30+ runtimes (Node, Python, PHP, Go, Dart, Ruby, Bun…) |
| SDK clients | JS, Python, Swift, Kotlin, Flutter, C# | JS, iOS, Android, Flutter, React Native, Web |
| Temps réel | WebSocket via service Realtime | WebSocket via Appwrite Realtime |
| Licence | Apache 2.0 | BSD 3-Clause |
Déployer Supabase sur un VPS
Étape 1 — Prérequis serveur
Provisionnez un VPS avec au minimum 4 Go de RAM (8 Go recommandés en production), Docker et Docker Compose installés. N'exposez pas en HTTP sur Internet le port 8000 du gateway, qui sert l'API et le Studio : placez devant un reverse proxy HTTPS (Caddy ou Nginx) sur le port 443 et publiez le gateway sur la boucle locale (
API_GW_HTTP_PORT=127.0.0.1:8000dans.env), car Docker contourne les règles ufw. Le pooler Supavisor publie aussi les ports 5432 et 6543 : sans besoin de connexion externe, préfixez-les par127.0.0.1:dansdocker-compose.yml. Un disque SSD de 40 Go minimum est conseillé pour PostgreSQL.Étape 2 — Cloner le dépôt et configurer l'environnement
Clonez le dépôt avec
git clone --depth 1 https://github.com/supabase/supabase, copiez le contenu desupabase/dockerdans un dossier de projet et copiez.env.exampleen.env. Ne démarrez jamais avec les valeurs d'exemple : générez secrets et clés avecsh utils/generate-keys.shpuissh utils/add-new-auth-keys.sh, et vérifiez au minimumPOSTGRES_PASSWORD,JWT_SECRET(32 caractères au moins),ANON_KEYetSERVICE_ROLE_KEY(deux JWT signés avec votre secret),DASHBOARD_PASSWORD(accès au Studio) et les URL publiques (SUPABASE_PUBLIC_URL,API_EXTERNAL_URL,SITE_URL).Étape 3 — Lancer la stack
Exécutez
docker compose up -d(oush run.sh start, équivalent dedocker compose up -d --wait). Avec Supabase 0.8.0+, c'est Envoy (et non plus Kong) qui sert le port 8000. Vérifiez l'état avecdocker compose pset attendez que tous les conteneurs soienthealthy.Étape 4 — Vérifier l'installation
Accédez au Studio par le gateway,
http://votre-ip:8000(ou votre domaine HTTPS derrière le reverse proxy), avec l'identifiantDASHBOARD_USERNAMEet le mot de passeDASHBOARD_PASSWORD. Testez un appel API simple aveccurl http://votre-ip:8000/functions/v1/hello -H "apikey: VOTRE_PUBLISHABLE_KEY": la réponse de la fonction d'exemple confirme que le gateway route correctement les requêtes.
Déployer Appwrite sur un VPS
Étape 1 — Prérequis serveur
Appwrite demande au minimum 2 cœurs, 4 Go de RAM et 2 Go de swap. Ses ~18 conteneurs (configuration par défaut) incluent Traefik comme reverse proxy. Les ports 80 et 443 doivent être ouverts.
Étape 2 — Lancer l'installateur interactif
Exécutez
docker run -it --rm --publish 20080:20080 --volume /var/run/docker.sock:/var/run/docker.sock --volume "$(pwd)"/appwrite:/usr/src/code/appwrite:rw --entrypoint="install" appwrite/appwrite:2.7.1en épinglant la version publiée plutôt quelatest. L'assistant s'ouvre dans le navigateur sur le port 20080 : il vous demande le domaine, génère les clés et undocker-compose.ymladapté, et crée le compte administrateur. Refermez le port 20080 une fois l'installation terminée.Étape 3 — Attendre la fin du démarrage
Au premier démarrage, les conteneurs peuvent mettre quelques minutes à être opérationnels, et la console peut répondre par une erreur en attendant. Suivez la progression avec
docker compose psetdocker compose logs -f appwrite. Les migrations, elles, ne concernent que la mise à jour d'une instance existante et se lancent à la main avecdocker compose exec appwrite migrate.Étape 4 — Se connecter à la console
Une fois l'installation terminée, ouvrez votre domaine (ou l'IP du serveur) dans le navigateur, connectez-vous à la console avec le compte administrateur créé par l'assistant, puis créez votre premier projet.
Authentification — comparatif des providers et configuration OAuth
Les deux plateformes gèrent l'authentification par e-mail/mot de passe et par numéro de téléphone (SMS OTP). Appwrite prend en charge plus de 30 providers OAuth2 contre 15+ pour Supabase.
Supabase utilise Supabase Auth (ex-GoTrue) comme service d'authentification, un démon léger écrit en Go. Appwrite intègre son propre service Auth configurable depuis la console web par projet, avec une granularité fine par provider.
Point de vigilance post-2.0 : l'issue #13547 (https://github.com/appwrite/appwrite/issues/13547), ouverte en septembre 2026, signalait que le reset de mot de passe et les invitations par e-mail ne fonctionnaient pas sur des déploiements Appwrite 2.0 self-hosted. Elle a été close sans version corrective nommée, l'équipe n'ayant pas reproduit le problème : testez impérativement ces flux après la migration avant de mettre votre instance en production.
Fonctions serverless — Deno vs 30+ runtimes
Supabase Edge Functions s'exécutent exclusivement sous Deno — le runtime JavaScript/TypeScript moderne de Ryan Dahl. Deno offre une sécurité par défaut (permissions explicites), une compatibilité TypeScript native et un écosystème de modules en pleine croissance.
Appwrite Functions supportent plus de 30 runtimes : Node.js, Python, PHP, Ruby, Go, Dart, .NET, Java, Kotlin, Swift, Bun et plus encore. Chaque runtime est un conteneur Docker isolé. Cette flexibilité est un avantage majeur pour les équipes polyglotes.
Note Appwrite 2.1.0 : les variables _APP_LOGGING_PROVIDER et _APP_LOGGING_CONFIG_REALTIME ne sont plus lues, et la journalisation des erreurs passe par la seule variable _APP_LOGGING_CONFIG, qui n'accepte plus qu'un DSN Sentry : un DSN LogOwl, Raygun ou AppSignal est rejeté au démarrage. Retirez les anciennes variables de votre .env et vérifiez ce DSN avant la mise à jour.
Temps réel et stockage de fichiers
Temps réel. Les deux plateformes utilisent des WebSockets. Supabase expose les changements PostgreSQL en temps réel via son service Realtime, qui souscrit aux notifications de la base de données (logical replication). Appwrite Realtime couvre les événements sur les documents, les fichiers et les équipes — il est moins lié à la base de données sous-jacente et donc plus portable.
Un point d'attention avec Supabase : le service Realtime démarre parfois avant que PostgreSQL soit complètement prêt, ce qui génère l'erreur could not connect to the database. Le redémarrage du conteneur realtime résout généralement ce problème.
Stockage. Supabase Storage s'appuie sur une API compatible S3 et permet de définir des politiques d'accès RLS directement depuis PostgreSQL. Appwrite Storage propose un système de permissions par équipe et par utilisateur, plus simple à configurer.
Appwrite : console inaccessible au premier démarrage — laissez-lui le temps
Si la console Appwrite affiche une erreur ou reste inaccessible dans les premières minutes, ne redémarrez pas les conteneurs à l'aveugle : le premier démarrage peut prendre quelques minutes. Suivez la progression en temps réel avec docker compose ps et docker compose logs -f appwrite, et attendez que tous les conteneurs tournent sans erreur avant d'accéder à l'interface. Lors d'une mise à jour, en revanche, rien ne migre tout seul : après avoir sauvegardé vos données, lancez docker compose exec appwrite migrate et laissez la commande aller à son terme sans couper les conteneurs.
Supabase : 502 Bad Gateway du gateway au démarrage — comportement normal
Le gateway API de Supabase (Kong jusqu'à 0.7.x, Envoy depuis 0.8.0) peut renvoyer des erreurs 502 dans les premières dizaines de secondes après docker compose up -d. Ce comportement est normal et transitoire : le gateway attend que PostgREST, GoTrue et les autres services soient prêts. Patientez jusqu'à ce que docker compose ps affiche tous les conteneurs en état healthy. Si les 502 persistent au-delà de quelques minutes, inspectez les logs avec docker compose logs rest et docker compose logs api-gw (service nommé kong avant 0.8.0).
Appwrite 2.0 : migration depuis 1.x — procédure et breaking changes
Appwrite 2.0 a été annoncé pour l'auto-hébergement le 7 septembre 2026 (source : https://appwrite.io/changelog/entry/2026-09-07). C'est une mise à jour majeure : PostgreSQL devient la base par défaut des nouvelles installations, MariaDB et MongoDB restant proposés. Une instance existante sur MariaDB reste sur MariaDB après la mise à jour : la 2.0 ne convertit pas vos données vers PostgreSQL.
Chemin de migration obligatoire. Une instance antérieure à 1.9.6 doit d'abord être montée en 1.9.6 (depuis 1.8.x, en passant par 1.9.5 et sa migration) ; à partir de 1.9.6, la mise à jour vers la dernière 2.x est directe. Procédure officielle :
1. Sauvegardez l'intégralité de vos données : docker compose down, puis copiez le dossier appwrite (docker-compose.yml, .env) et les volumes Docker nommés qui portent la base et les fichiers.
2. Si besoin, montez d'abord en 1.9.6 : depuis le dossier parent de appwrite, relancez la commande d'installation avec --entrypoint="upgrade" et l'image appwrite/appwrite:1.9.6.
3. Depuis le dossier appwrite, exécutez la migration : docker compose exec appwrite migrate.
4. Mettez à jour vers 2.x : relancez la commande upgrade avec l'image de la dernière version publiée (appwrite/appwrite:2.7.1 en novembre 2026).
5. Relancez docker compose exec appwrite migrate — ne coupez pas les conteneurs pendant ce processus — puis vérifiez avec docker ps | grep appwrite/appwrite que tous les conteneurs tournent dans la même version.
Breaking changes à surveiller. L'issue #13547, close en septembre 2026 sans correctif nommé, signalait que le reset de mot de passe et les invitations par e-mail ne fonctionnaient pas dans Appwrite 2.0 self-hosted. Testez impérativement ces flux dans un environnement de préproduction avant de migrer votre instance principale. Par ailleurs, en 2.1.0, les variables _APP_LOGGING_PROVIDER et _APP_LOGGING_CONFIG_REALTIME ne sont plus lues et _APP_LOGGING_CONFIG n'accepte plus qu'un DSN Sentry — retirez les premières et vérifiez la seconde avant la mise à jour. Aucune procédure de retour arrière n'est documentée : seule une restauration complète depuis la sauvegarde permet de revenir à 1.x.
Supabase 0.8.0 : Kong vers Envoy — impact et migration TLS
Supabase docker-compose 0.8.0, publié le 11 août 2026 (source : https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md), adopte Envoy comme gateway API par défaut (Kong reste disponible en opt-in, avec sh run.sh config add kong). Ce changement architectural est transparent pour la plupart des déploiements, mais il emporte un breaking change TLS : le listener TLS sur le port 8443 disparaît.
Ce qui change concrètement. Si votre reverse proxy (Nginx, Traefik, Caddy) ou vos scripts de santé faisaient des requêtes HTTPS directes vers https://votre-ip:8443, ces appels échoueront après la mise à jour. Envoy ne ré-expose pas ce port. La terminaison TLS doit désormais être assurée exclusivement par votre reverse proxy frontal.
Migration. Avant de mettre à jour vers 0.8.0, auditez vos configurations :
- Recherchez toute référence au port 8443 dans vos scripts de déploiement, vos sondes de santé (healthcheck), et vos règles de pare-feu.
- Supprimez ou remplacez ces références par des appels vers le port 8000 en HTTP depuis le réseau interne, avec la terminaison TLS confiée au reverse proxy.
- Mettez à jour par la procédure officielle (sh update.sh, puis sh run.sh pull && sh run.sh recreate) : un simple docker compose pull ne suffit pas, car le docker-compose.yml lui-même change. Vérifiez ensuite que docker compose ps montre le service api-gw (conteneur supabase-envoy), qui remplace le service kong, en état healthy.
Côté .env, KONG_HTTP_PORT reste lu comme valeur de repli de la nouvelle variable API_GW_HTTP_PORT, et KONG_HTTPS_PORT ne sert plus qu'à l'option Kong : vous pouvez passer à API_GW_HTTP_PORT pour clarifier votre configuration.
Guide de choix — Supabase ou Appwrite pour votre projet ?
Le choix entre les deux dépend principalement de votre type d'application et des compétences de votre équipe.
Choisissez Supabase si : votre application est web-first, votre équipe connaît PostgreSQL, vous migrez depuis Firebase et voulez conserver une base relationnelle robuste, ou vous avez besoin d'une API REST auto-générée depuis votre schéma de base de données (PostgREST).
Choisissez Appwrite si : vous développez une application mobile (iOS/Android) avec des besoins cross-platform, votre équipe travaille dans plusieurs langages et veut choisir le runtime de ses fonctions, ou vous préférez une interface d'administration plus accessible sans connaissances SQL approfondies.
Sur un VPS avec 4 Go de RAM, vous êtes au minimum documenté des deux plateformes (4 Go pour Supabase, 4 Go plus 2 Go de swap pour Appwrite) ; Supabase recommande 8 Go ou plus en production.
En 2026, les deux plateformes sont en pleine mutation. Appwrite 2.0 fait de PostgreSQL sa base par défaut pour les nouvelles installations — ce qui réduit l'avantage historique de Supabase sur ce point — tandis que Supabase modernise son gateway avec Envoy. Si vous planifiez une nouvelle installation, les deux sont équivalentes sur la question de la base de données. Si vous migrez une installation existante (qui reste sur MariaDB côté Appwrite), prévoyez une fenêtre de maintenance et testez les flux critiques (auth, e-mails, fonctions) avant toute mise à jour majeure.
Erreurs fréquentes et solutions — les deux plateformes
- Supabase — 502 Bad Gateway (gateway) : attendre que tous les services soient
healthy. Si persistant :docker compose restart api-gw(0.8.0+) oudocker compose restart kong(< 0.8.0). - Supabase — Realtime
could not connect to the database: PostgreSQL n'était pas prêt. Solution :docker compose restart realtime. - Supabase — JWT invalide : vérifier que
ANON_KEYetSERVICE_ROLE_KEYsont signés avec le mêmeJWT_SECRETque dans.env. - Supabase 0.8.0 — port 8443 inaccessible : le listener TLS Kong a disparu avec Envoy. Supprimer les appels directs vers le port 8443 et confier la terminaison TLS au reverse proxy frontal.
- Appwrite — console inaccessible au démarrage : le premier démarrage peut prendre quelques minutes. Vérifier
docker compose pset les logs avant de redémarrer quoi que ce soit. - Appwrite —
docker compose down -v: DANGER — cette commande supprime tous les volumes Docker, y compris les données. Ne jamais l'exécuter en production. - Appwrite — timeout des fonctions : le cold start d'un runtime non utilisé peut dépasser le timeout par défaut. Augmenter la limite dans les réglages de la fonction (Settings > Timeout, 900 s au maximum).
- Appwrite 2.x — migration bloquée : une instance antérieure à 1.9.6 doit d'abord passer par 1.9.6, avec
docker compose exec appwrite migrateà chaque étape. Sauter cette étape intermédiaire expose à une migration en échec : restaurez votre backup et recommencez. - Appwrite 2.0 — reset password / invitations : issue #13547 signalée en self-hosted, close sans correctif nommé. Tester ces flux avant la mise en production.
- Appwrite 2.1.0 — variables abandonnées :
_APP_LOGGING_PROVIDERet_APP_LOGGING_CONFIG_REALTIMEne sont plus lues ; les retirer du.env, et ne garder dans_APP_LOGGING_CONFIGqu'un DSN Sentry, seul accepté au démarrage.
Conclusion : deux excellents BaaS, deux philosophies différentes
Supabase et Appwrite sont tous deux des choix solides pour auto-héberger un BaaS open source sur votre VPS. Supabase brille par sa profondeur PostgreSQL, son API auto-générée et son Studio élaboré — idéal pour les développeurs backend qui veulent la puissance d'une base relationnelle avec une couche API sans effort. Appwrite se distingue par la richesse de ses runtimes de fonctions et la qualité de ses SDK mobiles — parfait pour les applications cross-platform et les équipes polyglotes.
Les deux plateformes ont connu en 2026 des mises à jour structurantes : Appwrite 2.0 (septembre 2026) fait de PostgreSQL la base par défaut des nouvelles installations, Supabase 0.8.0 (août 2026) bascule de Kong vers Envoy. Planifiez vos migrations avec une sauvegarde complète, un environnement de test et une validation des flux critiques — en particulier l'authentification par e-mail pour Appwrite 2.0. Dans les deux cas, un VPS dédié avec au minimum 99 DH/mois, Docker bien configuré et des sauvegardes automatisées de vos volumes est la base d'un déploiement serein.
