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
| 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 (Kong API Gateway) | 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 Kong) 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
git clone --depth 1 https://github.com/supabase/supabase
cd supabase/docker
cp .env.example .envOuvrez .env et définissez au minimum POSTGRES_PASSWORD, JWT_SECRET (32 caractères aléatoires), ANON_KEY et SERVICE_ROLE_KEY (deux JWT signés avec votre secret).
Étape 3 — Lancer la stack
docker compose up -dLe démarrage complet prend 60 à 120 secondes. Kong peut renvoyer des 502 pendant les 30 à 60 premières secondes — c'est normal. Vérifiez l'état avec docker compose ps et attendez que tous les conteneurs soient healthy.
Étape 4 — Vérifier l'installation
Accédez au Studio via http://votre-ip:3000. Testez un appel API simple :
curl http://votre-ip:8000/rest/v1/ \
-H "apikey: VOTRE_ANON_KEY"Une réponse JSON vide {} confirme que PostgREST répond correctement via Kong.
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
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:latestL'assistant vous demande le domaine, le port HTTP/HTTPS, et génère un docker-compose.yml adapté à votre environnement.
Étape 3 — Attendre les migrations de base de données
Au premier démarrage, Appwrite exécute ses migrations MariaDB. Ce processus prend entre 2 et 5 minutes et se traduit par des erreurs 503 temporaires sur la console web — 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.
Pour les applications mobiles nécessitant des deep links OAuth, Appwrite offre une intégration native de qualité grâce à ses SDK iOS et Android dédiés.
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.
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 MariaDB 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
Kong, le gateway API de Supabase, peut renvoyer des erreurs 502 pendant les 30 à 60 premières secondes après docker compose up -d. Kong attend que PostgREST, GoTrue et les autres services soient prêts. Ce comportement est normal et transitoire. 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 Kong avec docker compose logs kong.
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.
Erreurs fréquentes et solutions — les deux plateformes
- Supabase — 502 Bad Gateway (Kong) : attendre 30-60 s que tous les services soient
healthy. Si persistant :docker compose restart kong. - 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. - 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. Utiliserdocker compose downsans-v. - 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.
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.
Dans les deux cas, un VPS dédié avec au minimum 4 Go de RAM, Docker bien configuré et des sauvegardes automatisées de vos volumes est la base d'un déploiement serein. ServOrbit propose des VPS Cloud dimensionnés pour ce type de charge, avec des snapshots quotidiens inclus.
