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 de cette liste 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 chez vous. Si vous comparez le coût d’une location mensuelle à l’achat de la RAM, Proxmox chez soi ou 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 fois, et vous pourrez utiliser presque toute la liste. Les deux exceptions sont Cloudron et CasaOS, qui s’installent sur l’hôte avec leurs propres scripts d’installation. Consultez la section consacrée aux panneaux de contrôle :

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 un nouveau shell. Déconnectez-vous, puis reconnectez-vous. Si docker compose renvoie docker: 'compose' is not a docker command, vous utilisez l’ancien binaire autonome. 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 toute la suite. Premièrement, la RAM est la contrainte, pas le disque ni le CPU. Un VPS de 1 GB fait fonctionner 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 une capacité intermédiaire problématique : un débutant ajoute un troisième service, subit un arrêt silencieux pour manque de mémoire, puis ne comprend jamais pourquoi le conteneur a simplement disparu. 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 que vous voulez qu’une application mobile ou un navigateur lui fasse confiance. Troisièmement, deux ports déterminent la moitié de vos possibilités : le port entrant 80 doit atteindre la machine pour le challenge de certificat HTTP-01 standard. Un challenge DNS-01 évite cette contrainte en prouvant le contrôle du domaine avec un enregistrement DNS, ce qui est pratique lorsque le port 80 est fermé. Le port sortant 25 est bloqué par la plupart des fournisseurs. C’est pourquoi la messagerie figure dans la liste des services à éviter à 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 principal : 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 après y avoir stocké vos données est le moyen le plus courant de rendre une instance Nextcloud inutilisable. Le guide complet Nextcloud sur un VPS avec Docker, TLS et sauvegardes configure correctement l’ensemble dès la première installation.
• Immich remplace Google Photos, y compris l’application mobile qui envoie automatiquement les photos de votre pellicule et la recherche par visage ou par objet. Prévoyez 6 GB de RAM : la documentation d’Immich indique qu’il s’agit du minimum, tandis que 8 GB offrent une marge confortable. Le conteneur de machine learning est le plus gourmand. Prévoyez aussi un espace disque égal à la taille de votre photothèque, augmenté d’environ vingt pour cent pour les miniatures. Le piège principal : Immich suit le versionnage sémantique depuis sa première version stable, v2.0.0, publiée en octobre 2025. Les changements incompatibles sont donc réservés aux versions majeures. Immich est déjà passé à v3. Ne récupérez donc jamais latest sans vérifier la version, car cette commande vous ferait passer directement à la prochaine version majeure. Épinglez une version et lisez les notes de version avant chaque mise à niveau. Le guide photothèque Immich auto-hébergée explique la procédure de mise à niveau sûre. Si ces 6 GB minimum dépassent les capacités de votre serveur, 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 d’y stocker 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 principal : Seafile stocke vos fichiers sous forme de blocs adressés par leur contenu, et non comme des fichiers ordinaires sur le disque. Vous ne pouvez donc pas parcourir les données avec ls et vous devez utiliser les outils de Seafile pour effectuer les sauvegardes, plutôt que copier un dossier.

Mots de passe

• Vaultwarden remplace l’offre payante de Bitwarden, LastPass et 1Password par un petit serveur Rust qui parle le protocole Bitwarden. Toutes les applications officielles Bitwarden et les extensions de navigateur fonctionnent donc directement. 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 forme de hash Argon2, car un token en clair dans votre fichier compose donne accès au panneau d’administration de votre serveur. Ce panneau répertorie tous les utilisateurs et permet de modifier les paramètres du serveur. Le token resterait lisible par toute personne pouvant lire le fichier. Le guide gestionnaire de mots de passe Vaultwarden constitue le meilleur premier 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 générateur visuel de workflows que vous contrôlez, sans facturation par tâche. Prévoyez 400 MB à 1 GB de RAM. Le point critique : n8n chiffre les identifiants enregistrés avec une clé qu’il génère lors de la première exécution. Si vous perdez cette clé, ou si vous oubliez de définir N8N_ENCRYPTION_KEY et le laissez en générer une nouvelle, tous les identifiants enregistrés deviennent illisibles et vous devez tous les saisir de nouveau. Le guide n8n auto-hébergé avec HTTPS conserve cette clé et place un véritable certificat devant les URL de webhook.
• Ollama remplace un abonnement ChatGPT pour exécuter des LLM localement et de manière privée. Prévoyez la mémoire selon le modèle : un modèle de 7–8B nécessite environ 8 GB de RAM. Sa taille sur disque dépend de la quantification : comptez environ 4 à 5 GB pour le téléchargement 4-bit habituel et 13 GB ou plus pour une version fp16 en pleine précision. Le point critique : 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 s’appuie sur MongoDB, qui constitue le principal poste de consommation. Point important : chaque version majeure de Rocket.Chat ne prend en charge qu’une plage restreinte de versions de MongoDB (la version 8.x nécessite MongoDB 8.0 ou une version ultérieure, tandis que la version 7.x fonctionnait avec 6.0 ou 7.0). Les recommandations de mise à niveau de Rocket.Chat demandent aussi de passer les versions majeures dans l’ordre. Sauter une version peut donc bloquer la base de données. Effectuez la mise à niveau une étape à la fois. Le guide Rocket.Chat avec Docker Compose explique le parcours entre les versions.
• Matrix (Synapse) remplace Slack et Discord par un réseau fédéré et chiffré de bout en bout, dont vous contrôlez le homeserver. Prévoyez 1–2 GB de RAM, avec une consommation qui augmente lorsque vous rejoignez de grandes salles publiques. Point important : la consommation mémoire de Synapse augmente fortement dans les grandes salles fédérées. Synapse doit fonctionner avec PostgreSQL. SQLite, qui est utilisé par défaut, convient uniquement à un test avec un seul utilisateur et ne résiste pas dès que la fédération est activée. Si Synapse est trop lourd, les serveurs Conduit ou Dendrite, plus légers, 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 outils 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 se faisait en un clic » par un app store soigné, le TLS automatique et les sauvegardes intégrées. Prévoyez au minimum 2 GB de RAM, et 4 GB pour être à l’aise. Le point à connaître : Cloudron impose ses choix et veut gérer l’intégralité du serveur. Il s’installe directement sur un serveur Ubuntu vierge avec son propre script cloudron-setup, et non comme un conteneur. Sa documentation exclut les hôtes ARM, LXC, Docker et OpenVZ. La version gratuite est également 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. Il s’installe directement sur l’hôte avec son propre script (curl -fsSL https://get.casaos.io | sudo bash), et non comme un conteneur, puis exécute vos applications dans Docker. 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 suffisamment sécurisé pour Internet. Ne l’exposez pas directement ; accédez-y via WireGuard.
• Coolify remplace Heroku, Vercel et Netlify pour les déploiements avec git push, les bases de données et les environnements de prévisualisation sur votre propre serveur. 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 Cloudron vs CasaOS vs Coolify explique lequel des trois convient à chaque profil.

Outils pour les développeurs et la 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. Point important : Forgejo est le fork de Gitea gouverné par la communauté et celui que beaucoup recommandent désormais. Les deux sont excellents, mais choisissez-en un et sauvegardez les dépôts et la base de données ensemble. Une sauvegarde des dépôts sans la base de données fait perdre toutes les issues et les pull requests.
• Paperless-ngx remplace un classeur et les scanners de documents payants. Il applique l’OCR à tous vos documents pour les rendre consultables. Prévoyez environ 1 GB de RAM, avec des pics d’utilisation CPU pendant l’OCR. Point important : la qualité des résultats OCR dépend directement de celle de vos scans. 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, désormais fermé, par une solution locale, rapide et privée de gestion budgétaire par enveloppes. Prévoyez environ 150 MB de RAM. Point important : la synchronisation automatique avec les banques est intégrée, mais facultative. Elle ne fonctionne qu’après l’inscription auprès d’un fournisseur régional comme SimpleFIN Bridge ou Enable Banking et l’ajout de vos propres identifiants API. Par défaut, vous importez donc les transactions manuellement.
• FreshRSS remplace Feedly et Google Reader, désormais disparu, par un lecteur de flux rapide et privé avec des applications mobiles. Prévoyez environ 150 MB de RAM. 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, organisée sous forme d’étagères, de livres et de pages. Prévoyez environ 500 MB de RAM avec PHP et MySQL. Point important : il structure le contenu selon sa propre organisation plutôt que sous forme de notes libres. Certains 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 fournisseurs en centralisant votre maison connectée localement. Prévoyez environ 1 GB de RAM. Point important : une grande partie de ses fonctions dépend de l’accès au réseau local de vos appareils. Il s’installe donc plus naturellement sur du matériel situé chez vous que sur un VPS distant. Si nécessaire, exécutez le dashboard à distance et établissez un pont vers le 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 point le plus évident. La plupart des fournisseurs de VPS bloquent le port sortant 25. Vous verrez Connection timed out depuis telnet aspmx.l.google.com 25, et vous ne pourrez rien corriger de votre côté : c’est une règle du fournisseur. Certains fournisseurs lèveront cette restriction sur demande. AWS permet par exemple de demander sa suppression. Mais il s’agit d’une demande, pas d’un simple réglage. Même avec le port 25 ouvert, une adresse IP récente sans réputation, enregistrement PTR, SPF, DKIM ni DMARC verra vos messages arriver dans les spams ou être rejetés directement. C’est une tâche réelle et continue, pas un projet de week-end. Si vous tenez à vous lancer, faites-le en connaissance de cause avec le guide auto-héberger sa messagerie avec Mailcow 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 : vous avez un espoir. Ne placez pas de données irremplaçables, l’unique copie de vos photos ou vos comptes sur un service tant que sa restauration n’a pas été validée.
• Votre seule copie d’une dépendance critique. Un serveur DNS auto-hébergé qui, lorsqu’il tombe en panne, prive tout votre réseau d’accès à Internet est un mauvais premier projet. Conservez une solution de secours en amont.
• 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’interruption posent un vrai problème 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 dois-je d’abord auto-héberger ?

Vaultwarden. Un gestionnaire de mots de passe vous est utile au quotidien, remplace un abonnement et vous oblige à apprendre tout le workflow : Docker, un reverse proxy, TLS et les sauvegardes. L’application est assez petite pour être reconstruite en dix minutes si vous la cassez. Uptime Kuma est un excellent deuxième choix, afin que vous soyez informé des indisponibilités avant vos utilisateurs.

De quelles ressources VPS ai-je 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, vous risquez de subir des arrêts silencieux de conteneurs pour cause d’Out-Of-Memory sans comprendre 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 les applications utilisant une base de données volumineuse auront généralement besoin du plus de RAM et d’espace disque.

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

L’e-mail, avant tout. Le port sortant 25 est bloqué par la plupart des fournisseurs et garantir la remise des messages est un combat permanent. Évitez ensuite tout service que vous ne pouvez pas sauvegarder et restaurer de manière fiable, ainsi que tout point de défaillance unique dont l’indisponibilité aurait des conséquences graves, 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é.

Ai-je besoin de Docker pour tout cela ?

Non, mais Docker reste recommandé. Toutes les applications de cette liste, à l’exception de Cloudron et CasaOS, disposent d’une image Docker. Ces deux applications s’installent directement sur l’hôte avec leurs propres scripts d’installation, puis exécutent leurs applications dans des conteneurs à votre place. Pour les autres, Docker fournit des installations et des suppressions propres, facilite le verrouillage des versions et permet de migrer facilement vers un nouvel hôte. Quelques applications, comme WireGuard et Zabbix, s’installent aussi nativement avec apt si vous le préférez. Une fois que vous maîtrisez un fichier Compose, les autres suivent le même modèle. C’est pourquoi l’ensemble de cette liste reste accessible.

Comment sécuriser l’ensemble ?

Quatre habitudes couvrent l’essentiel : placez TLS devant tous les services, limitez SSH à l’authentification par clé et utilisez Fail2ban pour bloquer les tentatives de brute force, n’exposez publiquement que les ports dont vous avez réellement besoin et accédez au reste via votre VPN WireGuard, puis effectuez régulièrement les mises à jour en lisant 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 service lorsqu’une erreur échappe aux quatre premières protections.