Que self-héberger en 2026 : 25 applications

Ce que vous allez construire

Pas une seule application, une liste courte. Ceci est le point central de tout le reste du site : vingt-cinq applications qui valent vraiment la peine d'être installées sur votre propre VPS en 2026, classées par la tâche qu'elles accomplissent. Pour chacune, vous obtenez le service qu'elle remplace, un chiffre honnête de RAM et de disque, et la seule chose qui vous posera problème si vous la négligez. Les liens pointent vers le guide complet, étape par étape, lorsqu'il existe.

J'exploite un hébergeur VPS depuis quinze ans, et je fais tourner la plupart de ces applications sur mes propres machines. Les chiffres de ressources ci-dessous sont donc ce que l'application consomme réellement sous une petite charge de travail concrète, pas le « minimum » d'une page marketing. Lisez-les comme un budget, puis ajoutez de la marge.

Prérequis et la réalité honnête

Chaque application ici tourne sur un VPS KVM neuf sous Ubuntu 24.04 avec root ou sudo. Presque toutes sont livrées sous forme de conteneurs Docker, alors installez Docker une seule fois et vous êtes prêt pour 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 sauté l'étape du groupe ou vous n'avez pas ouvert un nouveau shell : déconnectez-vous puis reconnectez-vous. Si docker compose renvoie docker: 'compose' is not a docker command, vous avez l'ancien binaire autonome ; le script ci-dessus installe le plugin Compose moderne, que vous appelez avec docker compose (un espace, pas un tiret).

Trois réalités déterminent la forme de tout ce qui suit. Premièrement, la RAM est la contrainte, pas le disque ni le CPU. Un VPS de 1 Go fait tourner une petite application et rien de plus. 4 Go est le vrai point idéal pour une machine « self-héberger quelques services ». 2 Go est le milieu inconfortable où un débutant empile un troisième service, subit un arrêt silencieux pour manque de mémoire (Out-Of-Memory) et ne comprend jamais pourquoi le conteneur a simplement disparu : sudo dmesg montre la ligne Out of memory: Killed process que le démon a avalée. Deuxièmement, tout ce qui est public a besoin d'un nom et d'un certificat : une simple adresse IP fonctionne pour les tests et échoue dès que vous voulez qu'une application mobile ou un navigateur lui fasse confiance. Troisièmement, deux ports décident de la moitié de vos options : les ports 80 et 443 doivent atteindre la machine pour le TLS automatique, et le port sortant 25 est bloqué par la plupart des hébergeurs, ce qui explique pourquoi l'e-mail figure dans la liste des « à ne pas faire » à la fin.

Fichiers et photos

• Nextcloud remplace Google Drive, Dropbox et Google Calendar en une seule suite. Prévoyez 1 à 2 Go de RAM plus le poids de vos fichiers. Le seul piège : SQLite convient pour une démo et devient un traquenard en production ; installez-le sur PostgreSQL dès le premier démarrage, car migrer la base de données une fois vos données à l'intérieur est la façon la plus courante de ruiner un Nextcloud. Le guide complet Nextcloud sur un VPS avec Docker, TLS et sauvegardes le met en place correctement du premier coup.
• Immich remplace Google Photos, jusqu'à l'application mobile qui téléverse automatiquement votre pellicule et la recherche par visages et objets. Prévoyez 6 Go de RAM : la documentation d'Immich appelle cela le minimum, 8 Go est confortable, et le conteneur d'apprentissage automatique est la partie gourmande, et un disque égal à votre bibliothèque plus environ vingt pour cent pour les miniatures. Le piège : Immich livre encore des changements incompatibles entre les versions, alors ne récupérez jamais latest à l'aveugle ; épinglez une version et lisez les notes de version avant chaque mise à niveau. Le guide bibliothèque photo Immich auto-hébergée couvre le chemin de mise à niveau sûr.
• Seafile remplace Dropbox avec le moteur de synchronisation le plus rapide des trois. Prévoyez environ 1 Go de RAM. Le piège : Seafile stocke vos fichiers sous forme de blocs adressés par contenu, pas comme de simples fichiers sur le disque, vous ne pouvez donc pas parcourir les données avec ls et vous devez sauvegarder via les propres outils de Seafile, pas en copiant un dossier.

Mots de passe

• Vaultwarden remplace l'offre payante de Bitwarden, LastPass et 1Password par un minuscule serveur écrit en Rust qui parle le protocole Bitwarden, de sorte que chaque application et extension de navigateur officielle Bitwarden fonctionne directement. Prévoyez 100 à 200 Mo de RAM et presque pas de disque. Le piège : cette machine détient chacun de vos mots de passe, donc le TLS et les sauvegardes ne sont pas facultatifs ici, ils sont tout l'intérêt, et définissez le ADMIN_TOKEN sous forme de hachage Argon2, car un jeton en clair dans votre fichier compose est une clé maîtresse posée en clair. Le guide gestionnaire de mots de passe Vaultwarden est le meilleur premier auto-hébergement possible.

Médias

• Jellyfin remplace Plex et, pour votre propre bibliothèque, Netflix : entièrement ouvert, sans compte, sans diffusion à distance payante. Prévoyez 1 à 2 Go de RAM au repos, mais le CPU grimpe fort au transcodage. Le piège : transcoder par logiciel un flux 4K fera fondre un petit VPS ; soit vous donnez à la machine une accélération matérielle, soit vous gardez vos fichiers dans un format que vos clients peuvent lire directement (Direct Play), pour que le serveur ne fasse que pousser des octets. Le guide serveur multimédia Jellyfin sur un VPS explique ce qui est quoi.
• Navidrome remplace Spotify pour votre propre musique, en diffusant vers toute application compatible Subsonic. Prévoyez 150 à 300 Mo de RAM : c'est écrit en Go et cela se remarque à peine. Le piège : la première analyse de la bibliothèque lit les tags de chaque fichier et peut prendre une heure sur une grosse collection, et de mauvais tags ID3 en entrée donnent une mauvaise expérience de navigation en sortie.
• Audiobookshelf remplace Audible et votre application de podcasts, en conservant la position de lecture d'un appareil à l'autre. Prévoyez 200 à 500 Mo de RAM. Le piège : il attend une organisation stricte d'un dossier par livre, et un dossier d'import en désordre produit une bibliothèque en désordre, à moitié détectée, pénible à corriger après coup.

Automatisation et IA

• n8n remplace Zapier et Make par un constructeur de flux de travail visuel que vous possédez, sans facturation à la tâche. Prévoyez 400 Mo à 1 Go de RAM. Le piège : n8n chiffre les identifiants stockés avec une clé qu'il génère au premier lancement, et si vous perdez cette clé, ou oubliez de définir N8N_ENCRYPTION_KEY et le laissez la régénérer, chaque identifiant enregistré devient illisible et vous les ressaisissez tous. Le guide n8n auto-hébergé avec HTTPS épingle la clé et place un vrai certificat devant les URL de webhook.
• Ollama remplace un abonnement ChatGPT pour de l'inférence LLM (grand modèle de langage) locale et privée. Prévoyez selon le modèle : un modèle de 7 à 8 milliards de paramètres veut environ 8 Go de RAM, et chaque modèle pèse 4 à 8 Go sur le disque. Le piège : sur un VPS uniquement CPU, l'inférence est honnête mais lente, pensez en mots par seconde, pas aux réponses instantanées d'une API hébergée, alors ajustez vos attentes ou louez une machine avec GPU. Le guide faire tourner Ollama pour auto-héberger un LLM donne des chiffres réalistes.

Communication

• Rocket.Chat remplace Slack pour une équipe, avec fils de discussion, appels et intégrations. Prévoyez 2 Go de RAM et plus, car il tourne sur MongoDB et c'est le locataire lourd. Le piège : Rocket.Chat fixe une version majeure précise de MongoDB par release, et sauter une version pendant une mise à niveau est la façon de laisser votre base de données en rade ; mettez à niveau une étape à la fois. Le guide Rocket.Chat avec Docker Compose parcourt l'échelle des versions.
• Matrix (Synapse) remplace Slack et Discord par un réseau fédéré, chiffré de bout en bout, où vous possédez votre propre serveur d'accueil (homeserver). Prévoyez 1 à 2 Go de RAM qui augmente à mesure que vous rejoignez de grands salons publics. Le piège : la consommation mémoire de Synapse enfle sur les gros salons fédérés, et il doit tourner sur PostgreSQL : le SQLite par défaut ne marche que pour un test mono-utilisateur et s'effondre dès que vous fédérez. Si Synapse vous semble lourd, les serveurs plus légers Conduit ou Dendrite parlent le même protocole.

Réseau et accès

• WireGuard remplace un VPN commercial, en vous donnant un tunnel privé vers votre propre IP et vos autres services. Prévoyez presque rien : moins de 50 Mo, et la cryptographie tourne dans le noyau. Le piège : sur une virtualisation par conteneurs (OpenVZ, certains LXC), le module échoue avec RTNETLINK answers: Operation not supported ; vous voulez du KVM. Le guide VPN WireGuard auto-hébergé est la référence, et l'associer à des services attachés au tunnel est la façon de garder les choses entièrement hors de l'internet public.
• Traefik remplace les hôtes virtuels nginx écrits à la main et le renouvellement manuel des certificats : il découvre vos conteneurs par leurs labels Docker et récupère automatiquement les certificats Let's Encrypt. Prévoyez environ 100 Mo de RAM. Le piège : le modèle de configuration basé sur les labels est vraiment déroutant au début, et un seul label erroné laisse une application non routée sans erreur évidente. Le guide proxy inverse Traefik pour plusieurs applications Docker est conçu exactement pour faire tourner plusieurs des applications de cette page derrière un seul point d'entrée.
• AdGuard Home remplace une machine Pi-hole et le filtrage DNS payant, en bloquant publicités et traqueurs pour chaque appareil de votre réseau au niveau du DNS. Prévoyez 100 à 150 Mo de RAM. Le piège : il veut s'approprier le port 53, qui entre en conflit avec systemd-resolved sur Ubuntu : il refuse de démarrer avec listen udp 0.0.0.0:53: bind: address already in use tant que vous n'avez pas libéré le port d'abord.

Supervision

• Uptime Kuma remplace Pingdom, UptimeRobot et StatusPage par un tableau de bord clair et des alertes vers presque n'importe quel canal. Prévoyez 150 à 300 Mo de RAM. Le piège, et c'est celui que tout le monde oublie : surveillez votre machine de production depuis une autre machine ; Uptime Kuma tournant sur le serveur qu'il observe ne peut pas vous dire quand ce serveur meurt. Le guide supervision de statut Uptime Kuma couvre le placement externe.
• Zabbix remplace Datadog et les suites de supervision d'entreprise, avec des métriques approfondies basées sur des agents, des déclencheurs et de l'historique. Prévoyez 2 Go de RAM et plus, plus sa propre base de données. Le piège : Zabbix est puissant et vraiment lourd à mettre en place ; c'est excessif pour surveiller trois conteneurs et le bon outil pour une flotte. Commencez par Uptime Kuma ; passez au serveur de supervision Zabbix quand vous avez réellement une infrastructure à surveiller.

Prometheus et Grafana manquent volontairement à cette liste : ce sont d'excellents outils à l'échelle d'une flotte, mais ils sont plus lourds à exploiter et à régler que ne le justifie un ensemble personnel de deux ou trois machines, et Uptime Kuma plus Zabbix répondent aux mêmes questions à cette échelle avec moins à maintenir.

Tableaux de bord et panneaux de contrôle

Ceux-ci changent tout le modèle : au lieu de lancer des fichiers compose à la main, un panneau gère les applications pour vous.

• Cloudron remplace le souhait « j'aimerais que ce soit en un clic » par une boutique d'applications soignée, un TLS automatique et des sauvegardes intégrées. Prévoyez 2 Go de RAM au minimum, 4 Go confortablement. Le piège : il est opiniâtre et veut s'approprier toute la machine, et il n'est gratuit que jusqu'à deux applications ; au-delà, c'est un produit payant.
• CasaOS remplace un tableau de bord de homelab en désordre par une grille d'applications conviviale, gratuite et légère. Prévoyez environ 150 à 300 Mo pour CasaOS lui-même. Le piège : il est conçu pour un réseau domestique de confiance et n'est pas durci pour l'internet public ; ne l'exposez pas directement, atteignez-le via WireGuard.
• Coolify remplace Heroku, Vercel et Netlify : déploiements par git push, bases de données et prévisualisations sur votre propre serveur. Prévoyez 2 Go de RAM au minimum. Le piège : c'est un projet plus jeune qui évolue vite, alors épinglez les versions et lisez les notes de version avant de mettre à niveau. La comparaison Cloudron, CasaOS et Coolify détaille lequel des trois convient à quelle personne.

Outils de développement et de productivité

• Gitea (ou Forgejo) remplace GitHub pour les dépôts privés, les tickets et la CI. Prévoyez 200 à 500 Mo de RAM. Le piège : Forgejo est le fork gouverné par la communauté de Gitea et celui que beaucoup recommandent maintenant ; les deux sont excellents, mais choisissez-en un et sauvegardez les dépôts et la base de données ensemble : une sauvegarde de dépôt sans la base perd chaque ticket et chaque pull request.
• Paperless-ngx remplace un classeur et les scanners de documents payants, en passant tout à l'OCR pour que vos documents deviennent consultables. Prévoyez environ 1 Go de RAM, avec des pics de CPU pendant l'OCR. Le piège : les résultats de l'OCR ne valent que ce que valent vos scans, et retraiter une grande archive est lent ; réglez-le avant d'importer en masse dix ans de papier.
• Actual Budget remplace YNAB et Mint par une budgétisation par enveloppes rapide, locale et privée. Prévoyez environ 150 Mo de RAM. Le piège : la synchronisation bancaire automatique est un module additionnel séparé avec sa propre configuration, donc par défaut vous importez les transactions manuellement.
• FreshRSS remplace Feedly et le regretté Google Reader : un lecteur de flux rapide et privé avec applications mobiles. Prévoyez environ 150 Mo de RAM. Le piège : mettez en place le rafraîchissement des flux par cron, sinon les flux ne se mettent à jour que lorsque vous ouvrez la page.
• BookStack remplace Notion et Confluence pour la documentation, organisée en étagères, livres et pages. Prévoyez environ 500 Mo de RAM sur PHP et MySQL. Le piège : il structure le contenu à sa propre manière plutôt qu'en notes libres, ce que certains adorent et d'autres trouvent rigide ; essayez-le avant d'y confier tout votre wiki.
• Home Assistant remplace SmartThings et une douzaine d'applications de fabricants, en unifiant votre maison connectée localement. Prévoyez environ 1 Go de RAM. Le piège : une grande partie de sa magie a besoin d'un accès au réseau local vers vos appareils, il vit donc plus naturellement sur du matériel à la maison que sur un VPS distant ; faites tourner le tableau de bord à distance et faites le pont vers chez vous si vous devez.

Une installation représentative

Pour rendre cela concret, voici toute la forme d'un auto-hébergement : un fichier compose, un vrai certificat et une sauvegarde. C'est Uptime Kuma, mais chaque application de la liste suit le même schéma.

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

Remarquez le 127.0.0.1: : l'application n'écoute que sur localhost, et un proxy inverse tel que Traefik ou nginx termine le TLS devant elle. Se lier directement à 0.0.0.0:3001 est la façon dont les gens publient accidentellement un panneau d'administration non chiffré sur tout l'internet.

Ce qu'il ne faut PAS auto-héberger (pour l'instant)

• L'e-mail. C'est l'honnête. Le port sortant 25 est bloqué par la plupart des hébergeurs VPS : vous verrez Connection timed out depuis telnet aspmx.l.google.com 25 et il n'y a rien à réparer, c'est une politique. Même avec le 25 ouvert, une IP neuve sans réputation, sans enregistrement PTR, sans SPF, DKIM et DMARC fait atterrir votre courrier dans les spams ou le fait rejeter d'emblée. C'est un vrai travail continu, pas un week-end. Si vous y tenez, allez-y en connaissance de cause avec le guide e-mail auto-hébergé avec Mailcow, et attendez-vous à surveiller la délivrabilité pendant des mois.
• Tout ce que vous ne pouvez pas sauvegarder et restaurer de façon fiable. Si vous n'avez jamais fait de restauration de test, vous n'avez pas de sauvegarde, vous avez un espoir. Ne mettez pas de données irremplaçables, la seule copie de vos photos, de vos comptes, sur un service tant que sa restauration n'est pas prouvée.
• Votre seule copie d'une dépendance critique. Un serveur DNS auto-hébergé qui, en cas de plantage, emporte tout l'internet de votre réseau est un mauvais premier projet. Gardez un repli en amont.
• Les systèmes de sécurité en temps réel. Les alarmes de maison, les alertes médicales, tout ce où cinq minutes d'interruption sont un vrai problème n'ont pas leur place sur une machine de loisir que vous mettez à niveau le dimanche soir.

Comment choisir votre première application, et les deux points non négociables

Choisissez l'application qui supprime une facture qui vous agace ou une inquiétude de vie privée que vous ressentez vraiment. En pratique, les meilleures premières installations sont Vaultwarden et Uptime Kuma : les deux sont minuscules, immédiatement utiles, et indulgentes si vous faites une erreur. Faites-en fonctionner une de bout en bout, installation, certificat, sauvegarde, test de restauration, avant d'en ajouter une deuxième. La compétence que vous développez, ce sont les opérations, pas le fait de cliquer sur installer.

Deux choses sont non négociables sur chacune des applications ci-dessus, sans exception :

1. Le TLS sur tout ce qui est public. Un service en clair sur une simple IP est une démo, pas un déploiement. Placez un vrai certificat devant lui avec Certbot et Let's Encrypt sur nginx, ou laissez Traefik le faire automatiquement. Puis durcissez la porte d'entrée avec Fail2ban pour SSH sur Ubuntu 24.04.
2. Des sauvegardes que vous avez réellement restaurées. Automatisez un export nocturne, base de données et volume de données ensemble, envoyez-le hors de la machine, et une fois par mois restaurez-le sur un VPS jetable pour prouver que ça marche. Le jour où votre disque meurt est le mauvais jour pour découvrir que la sauvegarde était vide.

Réussissez ces deux points et l'auto-hébergement est un plaisir. Négligez-les et c'est un compte à rebours.

Les options vont du pratique à l'absurde, d'un serveur Minecraft sur un VPS pour la famille à, si vous aimez les récits édifiants, le centre de données le moins efficace du monde.

FAQ

Que dois-je auto-héberger en premier ?

Vaultwarden. Un gestionnaire de mots de passe vous apporte une valeur quotidienne, remplace un abonnement et vous force à apprendre tout le flux de travail, Docker, un proxy inverse, le TLS et les sauvegardes, sur une application assez petite pour être reconstruite en dix minutes si vous la cassez. Uptime Kuma est un excellent deuxième choix, pour être au courant des pannes avant vos utilisateurs.

De combien de VPS ai-je réellement besoin ?

Pour une seule petite application, 1 Go de RAM suffit. Pour une machine « faire tourner une poignée de choses » confortable, visez 4 Go : le milieu à 2 Go est l'endroit où les gens subissent des arrêts silencieux de conteneurs pour manque de mémoire (Out-Of-Memory) sans comprendre pourquoi. La RAM est presque toujours la limite ; ajoutez du disque à la hauteur des données que vous comptez stocker, et attendez-vous à ce qu'Immich, Ollama et tout ce qui a une grosse base de données en veuillent le plus des deux.

Que ne dois-je pas auto-héberger ?

L'e-mail, avant tout : le port sortant 25 est bloqué par la plupart des hébergeurs et la délivrabilité est un combat à plein temps. Ensuite, tout ce que vous ne pouvez pas sauvegarder et restaurer de façon fiable, et tout point unique de défaillance dont l'interruption cause un vrai préjudice, comme un serveur DNS sans repli ou un système de sécurité domestique. Tout le reste de cette liste est permis.

Ai-je besoin de Docker pour tout cela ?

Non, mais vous le voulez. Chaque application ici a une image Docker, et Docker vous offre des installations propres, des suppressions propres, un épinglage facile des versions et la portabilité vers un nouvel hôte. Quelques applications (WireGuard, Zabbix) s'installent aussi nativement depuis apt si vous préférez. Une fois que vous connaissez un fichier compose, vous les connaissez tous, ce qui rend toute la liste abordable.

Comment garder tout cela sécurisé ?

Quatre habitudes couvrent l'essentiel : placez le TLS devant tout, gardez SSH verrouillé avec une connexion par clé uniquement et Fail2ban qui bannit les tentatives de force brute, n'exposez publiquement que les ports dont vous avez vraiment besoin et atteignez le reste via votre VPN WireGuard, et mettez à jour régulièrement en lisant les notes de version pour qu'une mise à niveau ne vous surprenne jamais. Les sauvegardes sont la cinquième habitude : elles sont votre recours quand une erreur passe à travers les quatre premières.