Self-hosted
Définition
Solution déployée sur votre propre serveur ou cloud privé, plutôt que sur l'infrastructure managée du fournisseur. Donne plus de contrôle et de portabilité, demande plus d'expertise DevOps.
Comment ça marche
Self-hosted signifie déployer un logiciel sur votre propre serveur (VPS, bare metal, cloud privé) plutôt que sur l'infrastructure managée de l'éditeur. Vous installez les binaires ou les containers Docker, configurez la base de données, le reverse proxy, les certificats SSL, les sauvegardes. C'est faisable pour la majorité des solutions open-source : Supabase, n8n, Plausible Analytics, Ghost, Mattermost, Outline, Coolify. Le déploiement passe par Docker Compose, Kubernetes, ou un orchestrateur léger comme Coolify ou Dokploy qui simplifient considérablement le setup. Vous gardez le contrôle complet : version, configuration, données, sécurité.
Les motivations classiques
Quatre raisons principales poussent à auto-héberger. La souveraineté : pour les secteurs régulés (santé, défense, public, banque), les données ne doivent pas quitter le territoire français ou européen, et certains hébergeurs SaaS américains ne tiennent pas. La conformité : pour des certifications spécifiques (HDS, SecNumCloud, ISO 27001), un fournisseur SaaS standard n'est pas qualifié. Le coût : au-delà d'un certain volume, la facture du SaaS dépasse largement celle d'un VPS bien dimensionné. Le contrôle : sur la version, les extensions installées, les paramètres avancés, qu'un SaaS standard ne permet pas de toucher.
Quand l'utiliser
On part en self-hosted quand l'une des quatre motivations s'applique clairement. Pour un SaaS managé qui facture 500€/mois là où un VPS à 30€/mois suffirait, le calcul devient évident à condition d'avoir l'expertise. Pour un projet santé en France où HDS est obligatoire, le self-hosted ou un hébergeur qualifié sont les seules options. Pour un produit B2B qui vend à des grands comptes exigeants sur leur souveraineté, proposer une version self-hosted devient un argument commercial. À l'inverse, sur un MVP ou un produit en croissance sans contrainte particulière, le managé reste plus rentable en temps.
Quand ne pas l'utiliser
On évite le self-hosted quand l'équipe n'a pas de compétences DevOps : la première panne en production, à 2h du matin, sans personne qui sait débugger, coûte plus cher que toutes les économies cumulées. On évite aussi quand le volume reste modeste : pour un MVP avec 50 utilisateurs, payer un Hetzner pour héberger Supabase soi-même n'a aucun sens face au plan gratuit Supabase. Et on évite pour des produits évoluant très vite où chaque mise à jour de l'éditeur apporte de la valeur immédiate : en self-hosted, on traîne souvent plusieurs mois derrière la dernière version.
Les coûts cachés
Le serveur ne coûte que 30 à 100€/mois, mais l'expertise pour le tenir coûte beaucoup plus. Il faut compter le temps DevOps initial (setup, hardening, monitoring, sauvegardes : facilement 5 à 10 jours), les mises à jour de sécurité régulières (patch kernel, version applicative, dépendances), le monitoring continu (alertes, dashboards, astreinte), et la gestion des incidents. Si vous n'avez pas cette expertise en interne, vous payez un freelance ou une agence DevOps : 600 à 1200€/mois en monitoring + maintenance simple, beaucoup plus en cas d'incident sérieux. Le calcul total fait souvent pencher vers le managé.
Les outils qui simplifient
Coolify et Dokploy sont des plateformes self-hosted style Heroku, qui transforment un VPS en plateforme de déploiement avec interface graphique. On y déploie des applications Docker en quelques clics, on gère les certificats SSL via Let's Encrypt automatiquement, on a des sauvegardes intégrées. Pour Supabase self-hosted, le repo officiel fournit un docker-compose prêt à l'emploi. Pour n8n, l'image Docker officielle se déploie en une commande. Ces outils réduisent considérablement le coût d'entrée du self-hosted, sans aller jusqu'à la complexité de Kubernetes. Sur un seul VPS, on peut héberger 10 à 15 services proprement.
Les bonnes pratiques
On utilise des sauvegardes off-site (S3 chiffré, stockage chez un autre hébergeur), testées au moins une fois par mois pour vérifier qu'on peut restaurer. On automatise les mises à jour de sécurité OS (unattended-upgrades sur Debian, dnf-automatic sur Fedora). On surveille avec Uptime Kuma ou un service externe pour détecter les pannes dès qu'elles arrivent. On documente le runbook (comment redémarrer, comment restaurer, qui contacter) en clair, accessible même en pleine nuit. On garde une infrastructure simple : un VPS bien configuré avec sauvegardes solides bat dix services à moitié maîtrisés.