Auto-héberger des applications sur un VPS : architecture, consommation RAM et par où commencer
Guide de décision pour l'auto-hébergement d'applications sur un VPS avec Docker. Données réelles de consommation mémoire pour plus de 10 applications, combinaisons pour VPS 4 Go et 8 Go, et un cadre pour choisir votre première application.
Vous avez un VPS. Peut-être que vous venez de l'obtenir, ou peut-être que vous y faites déjà tourner quelques services et que vous voulez aller plus loin. Dans tous les cas, la question est la même : qu'est-ce que je peux y faire tourner, et est-ce que ça rentre ?
Ce guide y répond. Il couvre l'architecture d'une pile applicative auto-hébergée, fournit des chiffres réels de consommation mémoire mesurés sur un VPS 4 vCPU/8 Go, et propose une matrice de décision pour choisir votre première (ou prochaine) application. Prérequis : Ce guide suppose que Docker et un reverse proxy sont déjà en place. Si ce n'est pas le cas, commencez par Docker en production sur un VPS : ce qui casse et comment corriger pour installer Docker, Docker Compose et Caddy ou Traefik sur Debian 12 ou Ubuntu 24.04. Pour les fondamentaux de Docker Compose, consultez [-> docker-compose-multi-service-vps].
Pourquoi auto-héberger sur un VPS plutôt que sur un homelab ?
Un VPS vous donne un hébergement toujours disponible avec une adresse IPv4 publique, sans CGNAT, sans facture d'électricité et sans matériel à entretenir. Les snapshots gérés par le fournisseur assurent la reprise après sinistre. Un VPS 4 vCPU/8 Go fait tourner confortablement 5 à 8 applications Docker pour quelques euros par mois. Votre connexion internet tombe ; votre VPS, non.
| Facteur | VPS | Homelab |
|---|---|---|
| IP publique | Incluse, statique | Souvent derrière un CGNAT. Nécessite des contournements avec des tunnels. |
| Disponibilité | SLA 99,9 %+, alimentation redondante | Dépend de votre FAI et du réseau électrique |
| Bande passante | Symétrique, généralement 1 Gbps+ | Asymétrique. L'upload est le goulot d'étranglement. |
| Maintenance matérielle | Problème du fournisseur | Votre problème. Pannes de disques, bruit de ventilateurs, chaleur. |
| Électricité | Incluse dans le prix | 20-60 EUR/an pour un petit serveur allumé 24h/24 |
| Snapshots/sauvegardes | Un clic, gérés par le fournisseur | Vous construisez et testez le pipeline de sauvegarde vous-même |
| Coût initial | À partir de ~4 EUR/mois | 200-500+ EUR pour un Mini PC ou NAS |
| Accès physique | Aucun. SSH uniquement. | Accès complet. Utile pour les périphériques USB, les baies ZFS. |
Un homelab a du sens si vous avez besoin de stockage local (baies ZFS, NAS), de matériel USB (clés Zigbee, dongles SDR) ou si vous voulez apprendre l'administration bare-metal. Pour tout le reste, un VPS est plus simple et moins cher pour démarrer.
La plupart des FAI résidentiels utilisent désormais le Carrier-Grade NAT, ce qui signifie que vous partagez une IP publique avec des dizaines d'autres abonnés. Impossible de faire du port-forwarding. Impossible de recevoir des connexions entrantes. Vos applications auto-hébergées sont invisibles sur internet. Des solutions de contournement existent (Cloudflare Tunnels, relais WireGuard via un VPS), mais elles ajoutent de la complexité et une dépendance à un service externe. Un VPS élimine le problème : vous avez une IPv4 publique dédiée, vous contrôlez le DNS, et le trafic entrant fonctionne directement.
Si vous voulez les deux, utilisez un VPS comme point d'entrée public et un tunnel WireGuard vers votre homelab pour les services privés.
À quoi ressemble une pile applicative auto-hébergée ?
Une pile auto-hébergée sur VPS suit une architecture en couches : un reverse proxy se place en frontal, routant le trafic HTTPS vers les conteneurs applicatifs. Chaque application se connecte à sa propre base de données (ou utilise SQLite intégré). Une couche de sauvegarde effectue des snapshots selon un calendrier défini.
Internet
│
▼
┌─────────────────────────────┐
│ Reverse Proxy (Caddy) │ Port 443 ← only public port
│ TLS termination + routing │
└──────┬──────┬──────┬────────┘
│ │ │
▼ ▼ ▼
┌─────┐ ┌─────┐ ┌─────┐
│App 1│ │App 2│ │App 3│ Docker containers
└──┬──┘ └──┬──┘ └──┬──┘
│ │ │
▼ ▼ ▼
┌─────┐ ┌─────┐ ┌─────┐
│ DB │ │ DB │ │SQLite│ PostgreSQL, Redis, or embedded
└─────┘ └─────┘ └─────┘
│
▼
┌─────────────────┐
│ Backup Layer │ Restic, borgmatic, or provider snapshots
│ (scheduled) │
└─────────────────┘
Décisions clés :
- Reverse proxy : Caddy provisionne automatiquement les certificats TLS sans configuration. Traefik s'intègre avec les labels Docker pour l'auto-découverte. Les deux fonctionnent. Caddy est plus simple pour les débutants.
- Base de données : De nombreuses applications légères (Vaultwarden, Uptime Kuma, Beszel) utilisent SQLite intégré. Pas besoin d'un conteneur de base de données séparé. Les applications plus lourdes (Immich, Plausible, Gitea) nécessitent PostgreSQL.
- Sauvegarde : Les snapshots du fournisseur couvrent le disque entier. Pour les sauvegardes au niveau applicatif, utilisez Restic ou borgmatic vers une cible externe (stockage compatible S3 ou un second VPS).
- Réseau : Tous les conteneurs applicatifs se trouvent sur un réseau Docker interne. Seul le reverse proxy expose les ports 80 et 443. Les applications ne se lient jamais directement aux interfaces publiques.
Cette architecture est détaillée dans Docker en production sur un VPS : ce qui casse et comment corriger.
Combien de RAM les applications auto-hébergées consomment-elles réellement ?
Moins que vous ne le pensez. La plupart des applications auto-hébergées populaires consomment moins de 200 Mo au repos. Les exceptions sont les applications avec des fonctionnalités de machine learning (Immich) ou des moteurs d'analytique intégrés (Plausible avec ClickHouse).
Les chiffres ci-dessous sont la mémoire RSS au repos/en utilisation légère mesurée via docker stats sur un VPS Virtua Cloud 4 vCPU/8 Go sous Debian 12. Les valeurs de pointe représentent les pics typiques en utilisation active (upload de photos, OCR de documents, exécution de workflows).
| Application | Ce qu'elle remplace | RAM au repos | RAM en pointe | Stockage/mois | Base de données |
|---|---|---|---|---|---|
| Vaultwarden | Bitwarden, 1Password | ~25 Mo | ~50 Mo | Minimal | SQLite |
| Uptime Kuma | UptimeRobot, Pingdom | ~100 Mo | ~170 Mo | Minimal | SQLite |
| Beszel | Datadog (basique) | ~50 Mo | ~80 Mo | Minimal | Intégrée |
| Gitea | GitHub (dépôts privés) | ~150 Mo | ~300 Mo | ~50 Mo/dépôt | PostgreSQL ou SQLite |
| n8n | Zapier, Make | ~100 Mo | ~500 Mo+ | Variable selon les workflows | PostgreSQL |
| Paperless-ngx | Classeur à documents | ~300 Mo | ~1 Go | ~5 Mo/document | PostgreSQL + Redis |
| Nextcloud | Google Drive, Dropbox | ~250 Mo | ~512 Mo | Variable selon les fichiers | PostgreSQL + Redis |
| Coolify | Vercel, Railway | ~500 Mo | ~1,2 Go | Variable selon les déploiements | PostgreSQL (inclus) |
| Plausible | Google Analytics | ~400 Mo | ~1,5 Go | ~100 Mo/1M pages vues | PostgreSQL + ClickHouse |
| Immich | Google Photos | ~800 Mo | ~2,5 Go | ~3 Go/1000 photos | PostgreSQL + Redis |
Quelques précisions sur ces chiffres :
- Immich avec le machine learning (détection de visages/objets) activé a besoin de 4 à 6 Go au total. Les chiffres ci-dessus correspondent au ML activé mais au repos. Lors d'un import massif de photos, comptez 3-4 Go. Vous pouvez désactiver le ML pour descendre à ~400 Mo, mais vous perdez la recherche intelligente et la reconnaissance faciale.
- Plausible : la RAM dépend du volume de trafic. ClickHouse adore la mémoire. Pour un site avec moins de 100 000 pages vues/mois, les chiffres ci-dessus tiennent. Les sites à fort trafic ont besoin de plus.
- n8n au repos est léger, mais les workflows complexes avec de gros payloads JSON ou des intégrations IA provoquent des pics importants. Les workflows d'agents IA peuvent consommer 200 Mo+ par exécution.
- Paperless-ngx a des pics lors de l'OCR. Définissez
PAPERLESS_WEBSERVER_WORKERS=1dans Docker pour économiser ~150 Mo si vous êtes le seul utilisateur.
Quelle application auto-héberger en premier sur mon VPS ?
Commencez par Vaultwarden. Elle utilise 25 Mo de RAM, se déploie en moins de 10 minutes, remplace un gestionnaire de mots de passe payant que vous utilisez tous les jours, et vous oblige à configurer le TLS correctement. Cette configuration TLS (reverse proxy + DNS + certificats) est le socle dont chaque autre application auto-hébergée a besoin. Une application, trois gains : vie privée, économies et infrastructure réutilisable.
| Application | Impact vie privée | Complexité d'installation | SaaS remplacé | RAM min. |
|---|---|---|---|---|
| Vaultwarden | Très élevé (mots de passe) | Faible (10 min) | Bitwarden/1Password | 128 Mo |
| Immich | Élevé (photos personnelles) | Moyen (30 min) | Google Photos | 2 Go (4 Go avec ML) |
| Paperless-ngx | Élevé (documents, pièces d'identité) | Moyen (20 min) | Classeur + apps de scan | 512 Mo |
| Plausible | Moyen (analytique visiteurs) | Moyen-élevé (25 min) | Google Analytics | 1 Go |
| Uptime Kuma + Beszel | Faible (monitoring infra) | Faible (10 min) | UptimeRobot + Datadog | 256 Mo |
| Gitea | Moyen (code source) | Faible (15 min) | Dépôts privés GitHub | 256 Mo |
| n8n | Moyen (données de workflows) | Moyen (20 min) | Zapier, Make | 512 Mo |
| Coolify | Faible (outil de déploiement) | Moyen (20 min) | Vercel, Railway | 1 Go |
L'impact sur la vie privée est la raison la plus forte d'auto-héberger. Vos mots de passe, vos photos et vos documents scannés sont les données les plus sensibles que vous manipulez au quotidien. Les héberger sur le serveur de quelqu'un d'autre revient à faire confiance à sa sécurité, sa juridiction et sa pérennité. Sur votre propre VPS en Europe, ces données restent sous votre contrôle et sous le RGPD.
Pour les tutoriels de chaque application, suivez les liens en fin de guide.
Que puis-je faire tourner sur un VPS 4 Go vs 8 Go ?
Un VPS 4 Go fait tourner une bonne pile personnelle. Un VPS 8 Go gère tout ce dont un développeur solo ou une petite équipe a besoin. Les chiffres ci-dessous tiennent compte du reverse proxy (~30 Mo), de l'overhead Docker et du système d'exploitation lui-même (~300-400 Mo utilisés).
VPS 4 Go (~3,2 Go disponibles pour les apps)
| Combinaison | RAM totale au repos | Marge |
|---|---|---|
| Vaultwarden + Uptime Kuma + Beszel + Gitea | ~325 Mo | ~2,9 Go |
| Vaultwarden + Paperless-ngx + Uptime Kuma | ~425 Mo | ~2,8 Go |
| Vaultwarden + n8n + Beszel + Gitea | ~325 Mo | ~2,9 Go |
| Vaultwarden + Nextcloud + Uptime Kuma | ~375 Mo | ~2,8 Go |
Ces combinaisons laissent une marge confortable pour les pics d'utilisation. Même quand Paperless-ngx monte à 1 Go pendant l'OCR, il reste de la place. Évitez Immich avec ML ou Plausible sur 4 Go, sauf si c'est la seule application.
VPS 8 Go (~7 Go disponibles pour les apps)
| Combinaison | RAM totale au repos | Marge |
|---|---|---|
| Vaultwarden + Immich + Uptime Kuma + Beszel | ~975 Mo | ~6 Go |
| Vaultwarden + Plausible + Gitea + Paperless-ngx + Beszel | ~925 Mo | ~6 Go |
| Vaultwarden + Coolify + Uptime Kuma + n8n | ~725 Mo | ~6,3 Go |
| Toutes les légères (Vaultwarden + Gitea + Uptime Kuma + Beszel + n8n + Paperless-ngx) | ~725 Mo | ~6,3 Go |
Sur 8 Go, vous pouvez confortablement faire tourner Immich avec ML aux côtés de trois ou quatre applications légères. Vous pouvez aussi faire tourner Plausible avec ClickHouse sans vous soucier de la pression mémoire. C'est le sweet spot pour une configuration d'auto-hébergement personnel.
La RAM au repos est ce sur quoi vous planifiez, mais les pics sont ce qui fait planter votre serveur. Paperless-ngx connaît des pics pendant l'OCR. Immich monte en flèche pendant l'import de photos avec la classification ML. n8n a des pics lors de l'exécution de workflows avec de gros payloads. La colonne marge ci-dessus est votre filet de sécurité. Si la marge descend sous 1 Go, vous risquez que l'OOM killer de Linux termine un conteneur au pire moment. Gardez au moins 1,5 Go de marge pour toute pile incluant Immich ou Plausible.
Pour un VPS Virtua Cloud avec 4 vCPU et 8 Go de RAM sur stockage NVMe, consultez les offres en cours. La localisation Francfort place vos données dans l'UE sous le droit allemand de protection des données.
Quelles applications auto-hébergées nécessitent un hébergement européen ?
Toute application qui stocke des données personnelles bénéficie d'un hébergement européen sous le RGPD. Mais certaines applications manipulent des données qui rendent la question juridictionnelle urgente.
Priorité haute pour l'hébergement UE :
- Vaultwarden stocke chacun de vos mots de passe. Une fuite ici est catastrophique. L'hébergement européen signifie que les obligations de notification de violation du RGPD s'appliquent.
- Immich contient des photos personnelles, souvent avec les visages de membres de la famille. Les données de reconnaissance faciale sont des données biométriques au sens de l'article 9 du RGPD. Catégorie spéciale. Protections supplémentaires.
- Paperless-ngx stocke des pièces d'identité scannées, des documents fiscaux, des contrats. Parmi les données personnelles les plus sensibles que vous possédez.
Priorité moyenne :
- Plausible collecte des données analytiques sur les visiteurs. L'outil est privacy-first par conception (pas de cookies, pas de données personnelles), mais les données appartiennent quand même à vos visiteurs.
- Gitea peut contenir du code source propriétaire. Pas des données personnelles au sens strict, mais de la propriété intellectuelle que vous voulez contrôler.
- n8n : les workflows traitent souvent des données provenant de multiples services. La couche d'automatisation voit tout.
Priorité basse :
- Uptime Kuma / Beszel stockent des données de monitoring. Pas de données personnelles sauf si vous surveillez des endpoints qui en contiennent.
- Coolify est un outil de déploiement. Il manipule votre code mais ne stocke pas de données utilisateur final.
Si vous êtes une entreprise européenne ou si vous traitez des données de citoyens de l'UE, héberger ces applications sur un VPS en Allemagne (ou dans un autre pays de l'UE) simplifie votre mise en conformité RGPD. Vous contrôlez les données. Vous savez où elles sont. Vous choisissez qui y a accès.
Comment garder mes applications auto-hébergées sécurisées et à jour ?
Auto-héberger signifie que vous êtes l'administrateur système. C'est le prix à payer pour le contrôle. Voici les pratiques non négociables :
Le pare-feu d'abord. Avant de déployer une application, configurez ufw pour n'autoriser que SSH (port 22) et HTTPS (port 443). Bloquez tout le reste. C'est couvert dans Docker en production sur un VPS : ce qui casse et comment corriger.
TLS partout. Votre reverse proxy (Caddy ou Traefik) gère la terminaison TLS. Chaque application obtient du HTTPS. Sans exception. Caddy provisionne automatiquement les certificats Let's Encrypt.
Mises à jour. Vérifiez les mises à jour des images conteneur chaque semaine. Téléchargez les nouvelles images, recréez les conteneurs :
docker compose pull
docker compose up -d
Pour les mises à jour de sécurité critiques (Vaultwarden, toute application exposée sur internet), abonnez-vous aux releases GitHub du projet ou au flux RSS. Releases Vaultwarden et Releases Immich en sont de bons exemples.
Sauvegardes. Testez-les. Une sauvegarde que vous n'avez jamais restaurée n'est pas une sauvegarde. Utilisez les snapshots du fournisseur pour la restauration complète du disque et Restic ou borgmatic pour les sauvegardes applicatives hors site. Planifiez-les avec cron ou un timer systemd. Vérifiez-les chaque mois.
Gestion des secrets. Ne codez jamais les mots de passe en dur dans docker-compose.yml. Utilisez un fichier .env avec chmod 600 :
openssl rand -base64 32 > /dev/null # example: generate a strong password
# docker-compose.yml
services:
app:
env_file: .env
# .env (chmod 600, owned by root)
DB_PASSWORD=<generated-password>
SECRET_KEY=<generated-key>
Monitoring. Faites tourner Uptime Kuma pour les vérifications d'endpoints externes et Beszel pour les métriques au niveau conteneur (CPU, RAM, disque par conteneur). Les deux sont légers et vous donnent de la visibilité avant que les problèmes ne deviennent des pannes. Voir Auto-héberger Uptime Kuma et Beszel sur un VPS avec Docker Compose.
Les conteneurs Docker envoient leurs logs sur stdout par défaut :
docker compose logs -f --tail=50 <service-name>
Pour les services système (le reverse proxy s'il tourne en natif, SSH, pare-feu), utilisez journalctl :
journalctl -u caddy -f
Quand quelque chose casse, les logs sont votre premier réflexe. Pas Stack Overflow. Pas Reddit. Les logs.
Et maintenant ?
Chaque application de la matrice de décision ci-dessus dispose d'un tutoriel dédié avec les configurations Docker Compose complètes, la mise en place du reverse proxy, les sauvegardes et le durcissement :
| Application | Tutoriel |
|---|---|
| Vaultwarden (mots de passe) | Auto-héberger Vaultwarden sur un VPS avec Docker Compose |
| Immich (photos) | Auto-héberger Immich sur un VPS avec Docker Compose |
| Plausible (analytique) | Auto-héberger Plausible Analytics sur un VPS avec Docker Compose |
| Uptime Kuma + Beszel (monitoring) | Auto-héberger Uptime Kuma et Beszel sur un VPS avec Docker Compose |
| Coolify vs Dokploy (PaaS) | Coolify vs Dokploy : quel PaaS auto-hébergé pour votre VPS ? |
| Paperless-ngx (documents) | Auto-héberger Paperless-ngx sur un VPS avec Docker Compose |
| Gitea (hébergement Git) | Auto-héberger Gitea sur un VPS avec Docker Compose |
Si vous n'avez pas encore configuré Docker et un reverse proxy, commencez ici : Docker en production sur un VPS : ce qui casse et comment corriger. Ce guide couvre Debian 12 et Ubuntu 24.04, installe Docker avec Compose, configure Caddy comme reverse proxy avec TLS automatique, met en place un pare-feu et crée un utilisateur de déploiement non-root. Tout ce qui est présenté dans ce guide s'appuie sur cette fondation.