25 applications à auto-héberger en 2026

Ce que vous allez mettre en place

Il ne s’agit pas d’une seule application, mais d’une sélection. C’est le point de départ de tout le reste sur ce site : vingt-cinq applications qui valent réellement la peine d’être exécutées sur votre propre VPS en 2026, regroupées selon leur fonction. Pour chacune, vous trouverez le service qu’elle remplace, une estimation réaliste de la RAM et de l’espace disque nécessaires, ainsi que le seul point qui vous posera problème si vous le négligez. Les liens renvoient au guide complet, étape par étape, lorsqu’il existe.

J’héberge des VPS depuis quinze ans et j’exécute la plupart de ces applications sur mes propres serveurs. Les chiffres de ressources ci-dessous correspondent donc à l’utilisation réelle de l’application avec une petite charge de travail, et non au « minimum » indiqué sur une page marketing. Considérez-les comme un budget, puis prévoyez une marge.

Prérequis et réalité

Toutes les applications présentées ici s’exécutent sur un VPS KVM Ubuntu 24.04 fraîchement installé, avec un accès root ou sudo. La même liste fonctionne tout aussi bien sur une machine installée chez vous. Si vous comparez un abonnement mensuel avec l’achat définitif de la RAM, Proxmox chez vous ou sur un VPS loué détaille le calcul du matériel et de l’électricité. Presque toutes sont distribuées sous forme de conteneurs Docker. Installez donc Docker une seule fois pour être prêt à utiliser toute la liste :

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker "$USER"
newgrp docker
docker run --rm hello-world

Si les commandes docker échouent avec permission denied while trying to connect to the Docker daemon socket, vous avez ignoré l’étape d’ajout au groupe ou vous n’avez pas ouvert de nouveau shell. Déconnectez-vous, puis reconnectez-vous. Si docker compose renvoie docker: 'compose' is not a docker command, vous utilisez l’ancien binaire standalone. Le script ci-dessus installe le plugin Compose moderne, que vous appelez avec docker compose (avec un espace, pas un trait d’union).

Trois réalités déterminent tout ce qui suit. Premièrement, la RAM est la contrainte, pas le disque ni le CPU. Un VPS de 1 GB ne fait fonctionner qu’une petite application, et rien de plus. 4 GB est le meilleur compromis pour une machine destinée à « auto-héberger quelques services ». 2 GB est un entre-deux difficile : un débutant ajoute un troisième service, subit un kill silencieux pour manque de mémoire, puis ne comprend jamais pourquoi le conteneur vient de disparaître ; sudo dmesg affiche la ligne Out of memory: Killed process que le daemon a absorbée. Deuxièmement, tout service public a besoin d’un nom et d’un certificat. Une adresse IP seule convient pour les tests, mais échoue dès qu’une application mobile ou un navigateur doit lui faire confiance. Troisièmement, deux ports déterminent la moitié de vos possibilités : 80 et 443 doivent être accessibles depuis Internet pour le TLS automatique, et la plupart des fournisseurs bloquent le port sortant 25. C’est pourquoi la messagerie figure dans la liste « à ne pas faire » à la fin.

Fichiers et photos

• Nextcloud remplace Google Drive, Dropbox et Google Calendar dans une seule suite. Prévoyez 1–2 GB de RAM, auxquels s’ajoute l’espace occupé par vos fichiers. Le piège : SQLite convient pour une démonstration, mais devient un mauvais choix en production. Installez Nextcloud avec PostgreSQL dès le premier démarrage, car migrer la base de données une fois les données présentes est le moyen le plus courant de rendre une instance Nextcloud inutilisable. Le guide complet Nextcloud sur un VPS avec Docker, TLS et sauvegardes effectue correctement cette installation dès le départ.
• Immich remplace Google Photos, y compris l’application mobile qui envoie automatiquement les photos de votre appareil, ainsi que la recherche par visage et par objet. Prévoyez 6 GB de RAM : la documentation d’Immich indique qu’il s’agit du minimum. 8 GB offrent une marge confortable. Le conteneur de machine learning est le plus gourmand. Prévoyez également un espace disque égal à celui de votre photothèque, plus environ vingt pour cent pour les miniatures. Le piège : Immich continue de publier des changements incompatibles entre les versions. Ne récupérez donc jamais latest sans vérifier ; verrouillez une version et lisez les notes de version avant chaque mise à niveau. Le guide photothèque Immich auto-hébergée présente la procédure de mise à niveau sûre. Si votre serveur dispose de moins de 6 GB de RAM, le guide PhotoPrism et Immich côte à côte compare les deux solutions selon leur consommation réelle de mémoire, leurs applications mobiles et les commandes de sauvegarde nécessaires avant de leur confier une photothèque.
• Seafile remplace Dropbox avec le moteur de synchronisation le plus rapide des trois. Prévoyez environ 1 GB de RAM. Le piège : Seafile stocke vos fichiers sous forme de blocs adressés par contenu, et non comme des fichiers ordinaires sur le disque. Vous ne pouvez donc pas parcourir les données avec ls et vous devez effectuer les sauvegardes avec les outils propres à Seafile, plutôt qu’en copiant un dossier.

Mots de passe

• Vaultwarden remplace l’offre payante de Bitwarden, LastPass et 1Password par un petit serveur Rust qui utilise le protocole Bitwarden. Toutes les applications officielles Bitwarden et les extensions de navigateur fonctionnent donc immédiatement. Prévoyez 100–200 MB de RAM et presque aucun espace disque. Le point critique est le suivant : ce serveur contient tous vos mots de passe. TLS et les sauvegardes ne sont donc pas facultatifs. Ils constituent l’objectif principal du déploiement. Définissez le ADMIN_TOKEN sous la forme d’un hash Argon2, car un token en clair dans votre fichier Compose revient à laisser une clé maîtresse en clair. Le guide gestionnaire de mots de passe Vaultwarden est le meilleur premier projet d’auto-hébergement possible.

Médias

• Jellyfin remplace Plex et, pour votre propre bibliothèque, Netflix. Il est entièrement open source, ne nécessite aucun compte et ne facture pas le streaming à distance. Prévoyez 1–2 GB de RAM au repos, mais le CPU peut fortement monter en charge pendant un transcodage. Le point important : le transcodage logiciel d’un flux 4K peut saturer un petit VPS. Activez l’accélération matérielle ou conservez vos fichiers dans un format que vos clients peuvent lire directement (Direct Play). Le serveur se contente alors de transférer les données. Le guide serveur multimédia Jellyfin sur un VPS explique les différences. Une fois Jellyfin opérationnel, Halcyon transforme cette même bibliothèque en vidéoclub des années 90 que l’on parcourt dans le navigateur. C’est l’astuce la plus absurde et la plus efficace que je connaisse pour inciter un foyer à parcourir les rayons au lieu de tout faire défiler.

• Navidrome remplace Spotify pour votre propre musique et diffuse les morceaux vers toute application compatible avec Subsonic. Prévoyez 150–300 MB de RAM. Il est écrit en Go et consomme très peu de ressources. Le point important : le premier scan de la bibliothèque lit les tags de chaque fichier et peut durer une heure pour une grande collection. De mauvais tags ID3 produisent une mauvaise expérience de navigation.

• Audiobookshelf remplace Audible et votre application de podcasts. Il conserve la position de lecture entre les appareils. Prévoyez 200–500 MB de RAM. Le point important : il attend une arborescence stricte avec un dossier par livre. Un dossier d’import désordonné produit une bibliothèque incomplète, dont certains éléments ne sont pas détectés. La corriger ensuite est fastidieux.

Automatisation et IA

• n8n remplace Zapier et Make par un éditeur visuel de workflows que vous contrôlez, sans facturation par tâche. Prévoyez 400 MB à 1 GB de RAM. Le point à connaître : n8n chiffre les identifiants enregistrés avec une clé qu’il génère au premier démarrage. Si vous perdez cette clé ou si vous oubliez de définir N8N_ENCRYPTION_KEY et le laissez la régénérer, tous les identifiants enregistrés deviennent illisibles et vous devez tous les saisir à nouveau. Le guide n8n auto-hébergé avec HTTPS fixe la clé et place un certificat valide devant les URL des webhooks.
• Ollama remplace un abonnement ChatGPT pour l’inférence locale et privée de LLM. Prévoyez les ressources selon le modèle : un modèle 7–8B nécessite environ 8 GB de RAM, et chaque modèle occupe 4–8 GB sur le disque. Le point à connaître : sur un VPS sans GPU, l’inférence fonctionne, mais elle est lente. Comptez en mots par seconde, et non sur les réponses instantanées d’une API hébergée. Ajustez vos attentes ou louez une machine équipée d’un GPU. Le guide exécuter Ollama pour auto-héberger un LLM fournit des chiffres réalistes.

Communication

• Rocket.Chat remplace Slack pour une équipe, avec des fils de discussion, des appels et des intégrations. Prévoyez au moins 2 GB de RAM, car il utilise MongoDB, qui est le composant le plus gourmand en ressources. Le point important : chaque version de Rocket.Chat impose une version majeure précise de MongoDB. Ignorer une version lors d’une mise à niveau peut bloquer votre base de données. Effectuez les mises à niveau une étape à la fois. Le guide Rocket.Chat avec Docker Compose présente les différentes versions à suivre.
• Matrix (Synapse) remplace Slack et Discord par un réseau fédéré et chiffré de bout en bout, dont vous gérez le homeserver. Prévoyez 1 à 2 GB de RAM, avec une consommation qui augmente lorsque vous rejoignez de grands salons publics. Le point important : la consommation mémoire de Synapse augmente fortement dans les grands salons fédérés. Synapse doit utiliser PostgreSQL. SQLite, utilisé par défaut, convient uniquement à un test avec un seul utilisateur et atteint rapidement ses limites dès que la fédération est activée. Si Synapse est trop gourmand, les serveurs plus légers Conduit ou Dendrite utilisent le même protocole.

Réseau et accès

• WireGuard remplace un VPN commercial et vous fournit un tunnel privé vers votre propre IP et vos autres services. Prévoyez presque aucune ressource : moins de 50 MB, et la cryptographie s’exécute dans le kernel. Le point bloquant : avec une virtualisation basée sur des conteneurs (OpenVZ, certains environnements LXC), le module échoue avec RTNETLINK answers: Operation not supported ; vous devez utiliser KVM. Le guide VPN WireGuard auto-hébergé est la référence. L’associer à des services liés au tunnel permet de les garder entièrement hors de l’Internet public. Si vous préférez éviter de modifier manuellement la configuration d’un peer pour chaque nouvel appareil, exécuter un routeur de sous-réseau Tailscale sur le VPS annonce à la place toute cette plage privée au reste de vos machines, après validation de la route et configuration de la redirection IP pour qu’elle persiste après un redémarrage.
• Traefik remplace les virtual hosts nginx écrits manuellement et le renouvellement manuel des certificats. Il détecte vos conteneurs grâce à leurs labels Docker et récupère automatiquement les certificats Let’s Encrypt. Prévoyez environ 100 MB de RAM. Le point bloquant : le modèle de configuration basé sur les labels est réellement déroutant au début, et un seul label incorrect suffit à laisser une application sans routage, sans erreur évidente. Le guide proxy reverse Traefik pour plusieurs applications Docker est conçu précisément pour exécuter plusieurs applications de cette page derrière un même point d’entrée.
• AdGuard Home remplace un boîtier Pi-hole et le filtrage DNS payant. Il bloque les publicités et les trackers pour tous les appareils de votre réseau, au niveau DNS. Prévoyez 100–150 MB de RAM. Le point bloquant : il veut utiliser le port 53, qui entre en conflit avec systemd-resolved sur Ubuntu. Il ne démarre pas avec listen udp 0.0.0.0:53: bind: address already in use tant que vous n’avez pas libéré le port.

Supervision

• Uptime Kuma remplace Pingdom, UptimeRobot et StatusPage avec un tableau de bord clair et des alertes vers presque n’importe quel canal. Prévoyez 150–300 MB de RAM. Le piège, que beaucoup oublient : supervisez votre serveur de production depuis un autre serveur. Une instance Uptime Kuma exécutée sur le serveur qu’elle surveille ne peut pas vous avertir lorsque ce serveur tombe. Le guide supervision avec Uptime Kuma explique comment l’exécuter sur un serveur externe.
• Zabbix remplace Datadog et les suites de supervision d’entreprise, avec des métriques détaillées collectées par agent, des triggers et un historique. Prévoyez 2 GB de RAM ou plus, ainsi que sa propre base de données. Le piège : Zabbix est puissant et réellement lourd à mettre en place. Il est disproportionné pour surveiller trois conteneurs, mais adapté à un parc de serveurs. Commencez avec Uptime Kuma, puis passez au serveur de supervision Zabbix lorsque vous aurez réellement une infrastructure à surveiller.

Prometheus et Grafana ne figurent pas dans cette liste par choix : ce sont d’excellents outils pour superviser un parc, mais ils sont plus lourds à exécuter et à configurer qu’un stack personnel de deux ou trois serveurs ne le justifie. À cette échelle, Uptime Kuma et Zabbix répondent aux mêmes besoins avec moins d’éléments à maintenir.

Tableaux de bord et panneaux de contrôle

Ces solutions changent complètement le modèle : au lieu d’exécuter manuellement des fichiers Compose, un panneau gère les applications à votre place.

• Cloudron remplace le souhait « si seulement l’installation pouvait se faire en un clic » par un app store soigné, TLS automatique et sauvegardes intégrées. Prévoyez au minimum 2 GB de RAM, ou 4 GB pour être à l’aise. Le point à connaître : Cloudron impose ses choix et veut gérer l’ensemble du serveur. La version gratuite est limitée à deux applications ; au-delà, le produit est payant.
• CasaOS remplace un tableau de bord de homelab désordonné par une grille d’applications conviviale, gratuite et légère. Prévoyez environ 150 à 300 MB pour CasaOS lui-même. Le point à connaître : CasaOS est conçu pour un réseau domestique de confiance et n’est pas renforcé pour l’Internet public. Ne l’exposez pas directement ; accédez-y via WireGuard.
• Coolify remplace Heroku, Vercel et Netlify sur votre propre serveur, avec les déploiements par git push, les bases de données et les environnements de preview. Prévoyez au minimum 2 GB de RAM. Le point à connaître : il s’agit d’un projet plus récent qui évolue rapidement. Épinglez donc les versions et lisez les notes de version avant toute mise à niveau. La comparaison entre Cloudron, CasaOS et Coolify indique laquelle de ces trois solutions convient à chaque profil.

Outils de développement et de productivité

• Gitea (ou Forgejo) remplace GitHub pour les dépôts privés, les issues et la CI. Prévoyez 200–500 MB de RAM. Le point important : Forgejo est le fork de Gitea piloté par la communauté et celui que beaucoup recommandent désormais ; les deux sont excellents, mais choisissez-en un et sauvegardez ensemble les dépôts et la base de données. Une sauvegarde des dépôts sans la base de données supprime toutes les issues et les pull requests.
• Paperless-ngx remplace une armoire de classement et les scanners de documents payants. Il applique l’OCR à tous les documents afin de les rendre interrogeables. Prévoyez environ 1 GB de RAM, avec des pics d’utilisation du CPU pendant l’OCR. Le point important : la qualité des résultats OCR dépend directement de celle de vos scans, et le retraitement d’une archive volumineuse est lent. Réglez la configuration avant d’importer en masse dix ans de documents papier.
• Actual Budget remplace YNAB et Mint par une gestion budgétaire par enveloppes, rapide, locale et privée. Prévoyez environ 150 MB de RAM. Le point important : la synchronisation automatique avec les banques est un module complémentaire distinct qui nécessite sa propre configuration. Par défaut, vous importez donc les transactions manuellement.
• FreshRSS remplace Feedly et le défunt Google Reader. C’est un lecteur de flux rapide et privé, avec des applications mobiles. Prévoyez environ 150 MB de RAM. Le point important : configurez l’actualisation des flux avec cron. Sinon, les flux ne sont mis à jour que lorsque vous ouvrez la page.
• BookStack remplace Notion et Confluence pour la documentation. Le contenu est organisé en étagères, livres et pages. Prévoyez environ 500 MB de RAM avec PHP et MySQL. Le point important : il structure le contenu à sa manière au lieu de proposer des notes en texte libre. Certaines personnes apprécient cette approche, tandis que d’autres la trouvent rigide. Testez-le avant d’y migrer l’ensemble de votre wiki.
• Home Assistant remplace SmartThings et une douzaine d’applications de fabricants en centralisant votre maison connectée localement. Prévoyez environ 1 GB de RAM. Le point important : une grande partie de ses fonctions nécessite un accès au réseau local de vos appareils. Il s’exécute donc plus naturellement sur du matériel installé chez vous que sur un VPS distant. Si nécessaire, exécutez le dashboard à distance et établissez un bridge vers votre réseau local.

Une installation représentative

Pour concrétiser, voici la structure complète d’un auto-hébergement : un fichier Compose, un certificat valide et une sauvegarde. Il s’agit d’Uptime Kuma, mais toutes les applications de la liste suivent le même modèle.

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    volumes:
      - ./data:/app/data
    ports:
      - "127.0.0.1:3001:3001"
    restart: unless-stopped

docker compose up -d
docker compose logs -f

Notez le 127.0.0.1: : l’application écoute uniquement sur localhost, et un reverse proxy comme Traefik ou nginx gère la terminaison TLS en amont. Lier directement à 0.0.0.0:3001 est une manière de publier accidentellement un panneau d’administration non chiffré sur l’ensemble d’Internet.

Ce qu’il ne faut pas encore auto-héberger

• La messagerie électronique. C’est le cas le plus évident. Le port sortant 25 est bloqué par la plupart des fournisseurs de VPS. Vous verrez Connection timed out provenant de telnet aspmx.l.google.com 25, et il n’y a rien à corriger : c’est une règle appliquée par le fournisseur. Même si le port 25 est ouvert, une adresse IP récente sans réputation, enregistrement PTR, SPF, DKIM ni DMARC fera aboutir vos messages dans les spams ou entraînera leur rejet pur et simple. La gestion de la délivrabilité demande un travail réel et continu, pas un week-end. Si vous voulez malgré tout vous lancer, consultez le guide de la messagerie auto-hébergée avec Mailcow en connaissance de cause et prévoyez de surveiller la délivrabilité pendant plusieurs mois.
• Tout ce que vous ne pouvez pas sauvegarder et restaurer de manière fiable. Si vous n’avez jamais effectué de test de restauration, vous n’avez pas de sauvegarde, mais un simple espoir. Ne confiez pas des données irremplaçables, l’unique copie de vos photos ou vos comptes à un service tant que sa restauration n’a pas été validée.
• Votre unique copie d’une dépendance critique. Un serveur DNS auto-hébergé qui, lorsqu’il tombe en panne, coupe l’accès de tout votre réseau à Internet est un mauvais premier projet. Conservez un serveur DNS amont de secours.
• Les systèmes de sécurité en temps réel. Les alarmes domestiques, les alertes médicales et tout système pour lequel cinq minutes d’indisponibilité posent un problème réel ne doivent pas être hébergés sur une machine de loisir que vous mettez à niveau le dimanche soir.

Comment choisir votre première application et les 2 règles non négociables

Choisissez l’application qui vous évite de payer une facture qui vous agace ou qui répond à une vraie préoccupation de confidentialité. En pratique, les meilleurs premiers déploiements sont Vaultwarden et Uptime Kuma : ils sont légers, immédiatement utiles et tolèrent les erreurs de configuration. Faites fonctionner l’une d’elles de bout en bout — installation, certificat, sauvegarde et test de restauration — avant d’en ajouter une deuxième. La compétence que vous développez est l’exploitation, pas le clic sur le bouton d’installation.

Deux points sont non négociables pour chacune des applications ci-dessus, sans aucune exception :

1. TLS pour tout service public. Un service en clair accessible directement par adresse IP est une démonstration, pas un déploiement. Placez un certificat valide devant le service avec Certbot et Let's Encrypt avec nginx, ou laissez Traefik le gérer automatiquement. Renforcez ensuite le point d’entrée avec Fail2ban pour SSH sur Ubuntu 24.04.
2. Des sauvegardes que vous avez réellement restaurées. Automatisez chaque nuit un dump de la base de données et du volume de données, envoyez-les hors du serveur, puis restaurez-les une fois par mois sur un VPS temporaire pour vérifier qu’elles fonctionnent. Le jour où votre disque tombe en panne n’est pas le bon moment pour découvrir que la sauvegarde était vide.

Si ces 2 points sont correctement traités, l’auto-hébergement devient agréable. Si vous les ignorez, le délai avant l’incident est déjà lancé.

Les options vont du pratique à l’absurde : d’un serveur Minecraft familial sur un VPS à, si les récits édifiants vous intéressent, au datacenter le moins efficace au monde.

FAQ

Que devriez-vous auto-héberger en premier ?

Vaultwarden. Un gestionnaire de mots de passe vous est utile chaque jour, remplace un abonnement et vous oblige à apprendre tout le processus : Docker, un reverse proxy, TLS et les sauvegardes. L’application est suffisamment simple pour être reconstruite en dix minutes si vous la cassez. Uptime Kuma est un excellent deuxième choix : vous découvrez ainsi les interruptions avant vos utilisateurs.

De quelles ressources VPS avez-vous réellement besoin ?

Pour une petite application, 1 GB de RAM suffit. Pour un serveur confortable capable d’exécuter plusieurs services, prévoyez 4 GB. Avec 2 GB, les conteneurs sont souvent arrêtés silencieusement par manque de mémoire, sans que vous compreniez pourquoi. La RAM est presque toujours la limite. Ajoutez suffisamment de disque selon les données que vous prévoyez de stocker. Immich, Ollama et toute application utilisant une grosse base de données auront généralement besoin du plus de RAM et d’espace disque.

Que ne devriez-vous pas auto-héberger ?

La messagerie électronique, en premier lieu. Le port sortant 25 est bloqué par la plupart des fournisseurs, et assurer la délivrabilité est un combat permanent. Évitez ensuite tout ce que vous ne pouvez pas sauvegarder et restaurer de manière fiable, ainsi que tout point unique de défaillance dont l’interruption causerait un préjudice réel, comme un serveur DNS sans solution de secours ou un système de sécurité domestique. Tout le reste de cette liste peut raisonnablement être auto-hébergé.

Docker est-il nécessaire pour tout cela ?

Non, mais il est préférable de l’utiliser. Chaque application de cette liste dispose d’une image Docker. Docker fournit des installations et des suppressions propres, facilite le verrouillage des versions et permet de déplacer facilement les services vers un nouvel hôte. Quelques applications, comme WireGuard et Zabbix, peuvent aussi être installées nativement avec apt si vous le préférez. Une fois que vous connaissez un fichier Compose, vous les connaissez tous. C’est pourquoi toute la liste devient accessible.

Comment sécuriser l’ensemble ?

Quatre habitudes couvrent l’essentiel : placez TLS devant tous les services ; sécurisez SSH avec une authentification par clé uniquement et Fail2ban qui bloque les tentatives par force brute ; n’exposez publiquement que les ports dont vous avez réellement besoin et accédez au reste via votre VPN WireGuard ; mettez régulièrement les logiciels à jour et lisez les notes de version afin qu’une mise à niveau ne vous prenne jamais au dépourvu. Les sauvegardes constituent la cinquième habitude. Elles permettent de restaurer le système lorsqu’une erreur échappe aux quatre premières mesures.