Le script d'installation de Mon serveur, étape par étape

Lancer un script en sudo sur son serveur demande de la confiance. Ce guide explique chaque partie du fichier installer-mon-serveur.sh généré par Mon serveur, dans l’ordre où elles s’exécutent. Le script lui-même est lisible : ouvrez-le à côté de ce guide.

À retenir : le script ne télécharge rien d’autre que Docker (depuis son dépôt officiel) et les images de vos applications. Les mots de passe sont créés sur votre serveur, ils ne passent jamais par le site.

1. L’en-tête : votre mode d’emploi

Les premières lignes, qui commencent par #, sont des commentaires : rien n’est exécuté. On y retrouve le contenu de l’onglet README : les applications choisies, la mémoire estimée, les entrées DNS à créer et les premiers pas de chaque application. C’est votre aide-mémoire : gardez ce fichier.

2. Les réglages et les sécurités

set -euo pipefail
STACKS_DIR="${STACKS_DIR:-/opt/stacks}"
DRY_RUN="${DRY_RUN:-0}"

set -euo pipefail : le script s’arrête à la première erreur au lieu de continuer à moitié.
STACKS_DIR : le dossier où tout est installé, /opt/stacks par défaut.
DRY_RUN : le mode test, qui écrit les fichiers sans rien installer (voir le guide).

Ensuite, trois vérifications avant de toucher à quoi que ce soit :

le script est bien lancé avec sudo ;
le système est Ubuntu ou Debian (les commandes d’installation en dépendent) ;
à la première installation, il reste assez de place sur le disque pour les images de vos applications (Immich pèse à lui seul environ 5 Go). Sinon, le script s’arrête avant de commencer.

3. La vérification du DNS

Le script demande l’adresse IP publique du serveur, puis vérifie que chacun de vos domaines pointe dessus :

==> Vérification du DNS
  ✓ vault.mondomaine.fr -> 203.0.113.10
  ! photos.mondomaine.fr ne pointe pas vers ce serveur (203.0.113.10) mais vers : rien.

Un avertissement n’arrête pas l’installation : les applications seront installées, mais le HTTPS ne marchera pas pour ce domaine tant que l’entrée DNS n’est pas corrigée. Dès que c’est fait, le certificat est obtenu tout seul, sans relancer le script.

4. Le système

Mise à jour du système (apt-get upgrade), en gardant vos fichiers de configuration modifiés.
Fuseau horaire réglé (pour que les sauvegardes de 3 h aient lieu à 3 h chez vous).
Swap de 2 Go si le serveur n’en a pas (option) : une mémoire de secours sur le disque, qui évite les plantages.
Docker depuis son dépôt officiel, s’il n’est pas déjà là, avec une limite de taille des logs (3 fichiers de 10 Mo par conteneur) pour qu’ils ne remplissent jamais le disque.
Mises à jour de sécurité automatiques (option), avec redémarrage à 4 h 30 si vous l’avez choisi.
fail2ban (option) : 5 essais de connexion SSH ratés et l’adresse est bloquée une heure.
SSH par clé uniquement (option) : appliqué seulement si une clé est déjà installée, et annulé si la configuration est invalide. Le script ne peut pas vous enfermer dehors.

5. Le reverse proxy

Le script écrit la configuration de Traefik ou de Caddy dans /opt/stacks/traefik (ou caddy). C’est la porte d’entrée unique : il reçoit le trafic sur les ports 80 et 443, obtient les certificats HTTPS et transmet chaque adresse à la bonne application (le reverse proxy expliqué).

Avec Traefik, Docker n’est pas donné directement à Traefik : il passe par un socket-proxy qui ne l’autorise qu’à lire la liste des conteneurs. Avec l’option CrowdSec, un troisième conteneur analyse les visites et bloque les attaquants.

6. Vos applications

Pour chaque application, le script :

crée son dossier /opt/stacks/<application>/ ;
y écrit son compose.yml (chaque ligne expliquée) ;
génère ses mots de passe dans .env, seulement s’il n’existe pas déjà ;
crée les dossiers de données avec le bon propriétaire.

==> Vaultwarden -> https://vault.mondomaine.fr
  ✓ mots de passe générés dans .env

7. Le pare-feu

UFW est activé avec une règle simple : tout est fermé, sauf SSH (22), HTTP (80), HTTPS (443) et les ports qu’une application demande vraiment (22000 pour Syncthing, 2222 pour Gitea…).

8. Les tâches automatiques

Selon vos options, deux petits scripts sont installés avec leur planification :

Script	Quand	Guide
`/usr/local/bin/sauvegarde-serveur`	chaque nuit à 3 h	mode d’emploi de la sauvegarde
`/usr/local/bin/maj-applications`	le dimanche à 5 h	mode d’emploi des mises à jour
`/usr/local/bin/relance-conteneurs`	20 s après chaque démarrage de Docker, puis toutes les 15 min	pourquoi c’est utile

9. Le démarrage et le bilan

Le reverse proxy démarre en premier, puis chaque application. Le script affiche vos adresses et, en jaune, ce qu’il faut faire tout de suite :

les applications dont le premier visiteur devient administrateur (Jellyfin, Uptime Kuma, Gitea, Immich) : créez votre compte avant que quelqu’un d’autre le fasse ;
les applications livrées avec des identifiants connus de tous : changez-les immédiatement.

Peut-on le relancer ?

Oui. Le script est conçu pour ça : il ne recrée pas les mots de passe existants, n’écrase pas vos données et ne réinstalle pas Docker. C’est même la façon normale d’ajouter une application. Seule précaution : les fichiers compose.yml sont réécrits. Si vous en avez modifié un à la main, notez votre changement avant.

Une commande qui ne marche pas, une explication pas claire ? Signaler une erreur dans cette page.