Mode d'emploi des outils

La mise à jour automatique des applications : mode d'emploi

Le script maj-applications met à jour vos conteneurs chaque dimanche. Ce qu'il fait, comment voir ce qui a changé, le lancer, le désactiver et revenir en arrière.

Publié le 10 octobre 2026 · ⏱ 6 min de lecture

Avec l’option Mise à jour des applis de Mon serveur, vos applications se mettent à jour toutes seules le dimanche à 5 h. Pratique, mais il faut savoir ce qui se passe, et quoi faire le jour où une mise à jour casse quelque chose.

Ce que fait le script

/usr/local/bin/maj-applications est très court. Pour chaque dossier de /opt/stacks :

docker compose pull -q     # télécharge la dernière version des images
docker compose up -d       # recrée les conteneurs dont l'image a changé

Puis docker image prune -f supprime les anciennes versions devenues inutiles, pour ne pas remplir le disque.

« Dernière version » veut dire : la dernière version du tag écrit dans le compose.yml. Avec image: gitea/gitea:1, vous recevez les 1.x, jamais la 2.0. Avec :latest, vous recevez tout, y compris les changements majeurs.

Voir ce qui s’est passé dimanche

journalctl -u maj-applications --since "last sunday"
systemctl list-timers maj-applications.timer

Pour savoir quelle version tourne maintenant :

sudo docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Status}}"

« Up 2 days » le mardi : le conteneur a été recréé dimanche, donc mis à jour.

Mettre à jour tout de suite

sudo systemctl start maj-applications.service

Ou une seule application, à la main :

cd /opt/stacks/vaultwarden
sudo docker compose pull && sudo docker compose up -d

Désactiver les mises à jour automatiques

sudo systemctl disable --now maj-applications.timer

Le script reste installé : vous pouvez le lancer à la main quand vous voulez, ou réactiver la planification avec enable --now.

Exclure une seule application

Le plus simple : figer sa version dans son compose.yml. Remplacez par exemple

    image: ghcr.io/immich-app/immich-server:release

par une version précise, celle qui tourne aujourd’hui (numéro exact sur la page « Releases » de l’application) :

    image: ghcr.io/immich-app/immich-server:vX.Y.Z    # remplacez par le vrai numéro

Le script continuera de passer, mais il n’y aura jamais rien de nouveau à télécharger pour ce tag. Pour Immich, figez le même numéro sur immich-server et immich-machine-learning : les deux doivent toujours avoir la même version.

Une mise à jour a tout cassé : revenir en arrière

  1. Trouvez la version d’avant dans l’historique des versions de l’application (page « Releases » de son dépôt GitHub, ou les tags sur Docker Hub).
  2. Figez cette version dans le compose.yml, comme ci-dessus.
  3. Relancez :
cd /opt/stacks/<application>
sudo docker compose up -d
  1. Si les données ont été modifiées par la nouvelle version (migration de base de données), restaurez aussi la sauvegarde de la nuit précédente : celle de 3 h, faite avant la mise à jour de 5 h.

Pourquoi la sauvegarde passe avant : la sauvegarde tourne à 3 h et la mise à jour à 5 h. Le dimanche matin, vous avez donc toujours une copie de l’état d’avant la mise à jour. Ne changez pas ces horaires dans le mauvais sens.

Faut-il activer les mises à jour automatiques ?

  • Oui si vous n’allez pas sur le serveur toutes les semaines : une application jamais mise à jour finit par avoir des failles connues.
  • Non pour les applications à risque de casse (Immich et Nextcloud changent souvent en profondeur) : figez leur version et mettez-les à jour vous-même après avoir lu les notes de version.

Le guide mettre à jour ses applications sans rien casser détaille une approche plus prudente : n’installer une version que lorsqu’elle a quelques jours.

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

Prêt à vous lancer ?

Choisissez vos applications et récupérez une installation complète.

Créer mon serveur