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 | MariaDB (≤ 1.8), PostgreSQL (2.0+) |
| RAM minimum | 4 Go | 2 Go |
| RAM production recommandée | 8 Go | 4 Go |
| Nombre de conteneurs | ~13 | ~19 |
| Port principal | 8000 (Envoy depuis 0.8.0, Kong avant) | 80 / 443 (Traefik) |
| Port admin | 3000 (Studio) | 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. Ouvrez le port 8000 (API gateway) et le port 3000 (Studio) dans votre pare-feu. 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, entrez danssupabase/dockeret copiez.env.exampleen.env. Définissez au minimumPOSTGRES_PASSWORD,JWT_SECRET(32 caractères aléatoires),ANON_KEYetSERVICE_ROLE_KEY(deux JWT signés avec votre secret).Étape 3 — Lancer la stack
Exécutez
docker compose up -d. Le démarrage complet prend 60 à 120 secondes. 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 via
http://votre-ip:3000. Testez un appel API simple aveccurl http://votre-ip:8000/rest/v1/ -H "apikey: VOTRE_ANON_KEY". Une réponse JSON vide{}confirme que PostgREST répond correctement via le gateway.
Déployer Appwrite sur un VPS
Étape 1 — Prérequis serveur
Appwrite est plus léger au démarrage : 2 Go de RAM suffisent pour tester, mais 4 Go sont recommandés en production. Ses ~19 conteneurs 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 --volume /var/run/docker.sock:/var/run/docker.sock --volume "$(pwd)"/appwrite:/usr/src/code/appwrite:rw --entrypoint="install" appwrite/appwrite:latest. L'assistant vous demande le domaine, le port HTTP/HTTPS, et génère undocker-compose.ymladapté à votre environnement.Étape 3 — Attendre les migrations de base de données
Au premier démarrage, Appwrite exécute ses migrations. Ce processus prend entre 2 et 5 minutes et se traduit par des erreurs 503 temporaires — c'est attendu. Suivez la progression avec
docker compose logs -f appwrite.Étape 4 — Créer le compte administrateur
Une fois les migrations terminées, accédez à
http://votre-domaine/console. Créez votre premier compte administrateur, puis 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 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) signale que le reset de mot de passe et les invitations par e-mail sont cassés dans les déploiements Appwrite 2.0 self-hosted. Le correctif est attendu en 2.0.1 ; en attendant, 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.0 : les variables _APP_LOGGING_PROVIDER et _APP_LOGGING_CONFIG_REALTIME ont été supprimées en 2.1.0 et remplacées par un système de logging unifié. Retirez-les de votre .env avant la mise à jour sous peine d'erreurs de démarrage.
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 PostgREST soit complètement initialisé, 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 : erreur 503 au premier démarrage — attendez les migrations
Si la console Appwrite affiche une erreur 503 ou reste inaccessible dans les premières minutes, ne redémarrez pas les conteneurs. Appwrite exécute automatiquement ses migrations de base de données au premier démarrage, un processus qui dure entre 2 et 5 minutes. Suivez la progression en temps réel avec docker compose logs -f appwrite et attendez le message Migrations completed avant d'accéder à l'interface. Redémarrer les conteneurs pendant cette phase corrompra la base de données et nécessitera une réinstallation complète.
Supabase : 502 Bad Gateway depuis Kong 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 pendant les 30 à 60 premières 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 2 minutes, inspectez les logs avec docker compose logs supabase-rest ou docker compose logs kong selon votre version.
Appwrite 2.0 : migration depuis 1.x — procédure et breaking changes
Appwrite 2.0 a été publié le 7 septembre 2026 (source : https://appwrite.io/changelog/entry/2026-09-07). C'est une mise à jour majeure qui migre le moteur de persistance de MariaDB vers PostgreSQL de façon irréversible — un rollback vers 1.x n'est pas possible après la migration.
Chemin de migration obligatoire. Vous devez d'abord passer à la version 1.9.6 avant de mettre à jour vers 2.0. Il est impossible de sauter cette étape intermédiaire. Procédure recommandée :
1. Sauvegardez l'intégralité de vos volumes Docker : docker compose down puis cp -r /chemin/appwrite /chemin/appwrite.backup.
2. Montez d'abord en 1.9.6 : modifiez l'image dans votre docker-compose.yml pour pointer vers appwrite/appwrite:1.9.6, puis lancez docker compose pull && docker compose up -d.
3. Attendez la fin des migrations 1.9.6 (docker compose logs -f appwrite | grep -i migrat).
4. Mettez à jour vers 2.0 : changez l'image vers appwrite/appwrite:2.0, puis relancez docker compose pull && docker compose up -d.
5. Les migrations PostgreSQL s'exécutent automatiquement au premier démarrage de 2.0 — ne coupez pas les conteneurs pendant ce processus.
Breaking changes à surveiller. L'issue #13547 signale que le reset de mot de passe et les invitations par e-mail sont cassés 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, les variables _APP_LOGGING_PROVIDER et _APP_LOGGING_CONFIG_REALTIME sont supprimées en 2.1.0 — retirez-les de votre .env dès maintenant pour anticiper. La migration est irréversible : une fois sur 2.0, seule une restauration complète depuis la sauvegarde permet de revenir en arrière.
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). 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 silencieusement 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.
- Après docker compose pull && docker compose up -d, vérifiez que docker compose ps ne liste plus de service kong et qu'un service supabase-rest-proxy (Envoy) est présent et healthy.
Les variables d'environnement liées à Kong (KONG_HTTP_PORT, KONG_HTTPS_PORT, KONG_*) présentes dans votre .env sont désormais ignorées mais n'empêchent pas le démarrage — vous pouvez les retirer pour nettoyer 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, Appwrite offre plus de marge (requis 2 Go, recommandé 4 Go) contre Supabase qui consomme ses 4 Go minimum dès le démarrage.
En 2026, les deux plateformes sont en pleine mutation. Appwrite 2.0 unifie sa base sur PostgreSQL — 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, 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 30-60 s que tous les services soient
healthy. Si persistant :docker compose restart supabase-rest-proxy(0.8.0+) oudocker compose restart kong(< 0.8.0). - Supabase — Realtime
could not connect to the database: PostgREST 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 — 503 au démarrage : migrations en cours (2-5 min). Ne pas redémarrer les conteneurs.
- 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 du projet.
- Appwrite 2.0 — migration bloquée : vous devez passer par 1.9.6 avant 2.0. Sauter cette étape intermédiaire rend la migration impossible. Restaurez votre backup et recommencez.
- Appwrite 2.0 — reset password / invitations cassés : issue #13547 confirmée en self-hosted. Tester ces flux avant la mise en production et attendre le correctif 2.0.1.
- Appwrite 2.1.0 — variables supprimées : retirer
_APP_LOGGING_PROVIDERet_APP_LOGGING_CONFIG_REALTIMEdu.envavant la mise à jour pour éviter des erreurs de 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 sa légèreté relative, la richesse de ses runtimes de fonctions et la qualité de ses SDK mobiles — parfait pour les applications cross-platform et les équipes polyglotes.
En septembre 2026, les deux plateformes traversent des mises à jour structurantes : Appwrite 2.0 adopte PostgreSQL de façon irréversible, Supabase 0.8.0 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.
