Docker v29 casse l'écosystème self-hosted : checklist de survie

Docker v29 est sorti, et la moitié de l’écosystème self-hosted s’est effondrée. Portainer ne charge plus vos environnements. Traefik ne détecte plus vos conteneurs. Swarmpit ne démarre même plus. Le point commun : une seule ligne dans le changelog de Docker Engine v29 qui relève la version minimale de l’API de 1.24 à 1.44.

Si vous gérez un VPS avec des outils self-hosted, cet article vous donne la checklist pour éviter la casse — ou réparer les dégâts.

Ce qui a changé dans Docker v29

Docker Engine maintient depuis des années une compatibilité descendante avec les anciennes versions de son API. Un outil compilé pour l’API v1.25 (Docker 17.x) fonctionnait encore avec Docker 28. Cette tolérance permettait aux outils de tourner pendant des années sans mise à jour.

Docker v29 met fin à cette tolérance. Le daemon rejette désormais toute connexion client utilisant une API inférieure à la version 1.44, qui correspond à Docker v25.0.

Concrètement, si un outil envoie une requête avec API-Version: 1.41, Docker v29 répond :

# Message d'erreur retourné par le daemon Docker v29
Error response from daemon: client version 1.41 is too old.
Minimum supported API version is 1.44, please upgrade your client to a newer version.

Ce n’est pas le seul changement. Docker v29 passe aussi le containerd image store en défaut pour les nouvelles installations, déprécie cgroup v1 et retire plusieurs fonctions du SDK Go. Mais c’est le relèvement de l’API minimale qui a provoqué le plus de dégâts, parce qu’il touche tous les outils qui communiquent avec le daemon Docker — c’est-à-dire à peu près tout l’écosystème.

Qui est touché : le tableau des outils et versions

Selon l’analyse publiée par Portainer, les outils self-hosted se divisent en deux camps depuis Docker v29 : ceux qui sont maintenus activement et ceux qui ne le sont plus.

Outils corrigés (mise à jour disponible) :

Outil	Problème	Version corrigée
Portainer	Client hardcodé à API v1.41	2.33.5 LTS / 2.36.0 STS
Traefik	Provider Docker pincé à API v1.24	v3.6.1
CapRover	Backend bloqué à API v1.43	v1.14.1
LazyDocker	Client Go sans négociation	v0.24.2
cAdvisor	Client Docker obsolete	v0.53.0

Outils cassés sans correctif :

Outil	Problème	Statut
Watchtower	Image pincée à API v1.25	Non maintenu depuis 2+ ans
Swarmpit	Projet archivé	Projet mort
Dockge	Pas de patch v29	Non corrigé
CasaOS	Compilé contre API v1.43	Pas de solution upstream
Yacht	dockerode obsolète	Inactif depuis mi-2023

Si vous utilisez Coolify pour déployer vos outils — ce que nous avons détaillé dans notre guide de déploiement VPS — sachez que Coolify utilise l’API Docker en interne. Vérifiez que votre version de Coolify est compatible avant de mettre à jour Docker.

Checklist de survie avant de mettre à jour

Ne lancez pas apt upgrade docker-ce sans préparation. Voici les cinq étapes à suivre dans l’ordre.

1. Vérifiez votre version Docker actuelle

# Affiche la version du client et du serveur Docker
docker version

Si votre serveur indique une version inférieure à 29.0.0, vous n’êtes pas encore concerné. Mais la mise à jour arrivera — par un apt upgrade automatique, par votre provider, ou par une mise à jour de votre image serveur.

2. Inventoriez vos outils Docker

Listez tous les conteneurs actifs et les images qu’ils utilisent :

# Liste tous les conteneurs avec leur image et leur statut
docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Status}}"

Pour chaque outil, vérifiez dans le tableau ci-dessus s’il est concerné et si un correctif existe.

3. Vérifiez les versions de vos outils critiques

Pour Portainer :

# Affiche la version de Portainer depuis son conteneur
docker exec portainer /portainer --version
# Requis : >= 2.33.5 (LTS) ou >= 2.36.0 (STS)

Pour Traefik :

# Affiche la version de Traefik
docker exec traefik traefik version
# Requis : >= 3.6.1

4. Mettez à jour vos outils AVANT Docker

C’est la règle d’or : mettez à jour les outils d’abord, Docker ensuite. Si vous faites l’inverse, vos outils casseront entre la mise à jour de Docker et celle des outils — et pendant ce temps, votre reverse proxy ne route plus, votre dashboard ne répond plus, et vos alertes ne partent plus.

5. Testez sur un environnement de staging

Si vous avez un VPS de test ou un Docker local, faites la mise à jour là-bas d’abord. Si ce n’est pas possible, planifiez une fenêtre de maintenance et prévoyez un rollback :

# Pincez la version Docker actuelle avant mise à jour
sudo apt-mark hold docker-ce docker-ce-cli
# Quand vous êtes prêt, relâchez le hold et mettez à jour
sudo apt-mark unhold docker-ce docker-ce-cli

Le workaround temporaire : forcer l’API minimale

Si vous ne pouvez pas mettre à jour vos outils immédiatement — parce qu’un correctif n’existe pas encore ou parce que la mise à jour introduit d’autres incompatibilités — Docker v29 permet de forcer l’API minimale à une version inférieure.

Méthode 1 : via daemon.json

Modifiez ou créez le fichier /etc/docker/daemon.json :

{
  "min-api-version": "1.24"
}

Puis redémarrez Docker :

sudo systemctl restart docker

Méthode 2 : via systemd override

# Crée un override systemd pour le service Docker
sudo systemctl edit docker.service

Ajoutez :

[Service]
Environment=DOCKER_MIN_API_VERSION=1.24

Puis :

sudo systemctl daemon-reload
sudo systemctl restart docker

Ce workaround est un palliatif, pas une solution. Il réintroduit la tolérance que Docker v29 a volontairement supprimée. Utilisez-le pour débloquer une situation d’urgence, pas comme configuration permanente. Le problème de fond reste : vos outils doivent supporter l’API 1.44.

La leçon de fond : gérer la dépendance à Docker dans votre stack

Docker v29 n’a pas cassé l’écosystème self-hosted. Il a révélé quels outils étaient réellement maintenus et lesquels tournaient par inertie, protégés par la tolérance du daemon.

Swarmpit, Watchtower, Yacht — ces projets étaient déjà morts. Ils fonctionnaient uniquement parce que Docker acceptait des requêtes API vieilles de six ans. Le jour où Docker a dit stop, ces outils ont cessé de fonctionner instantanément.

C’est le même pattern que nous avons documenté avec les changements de licence open source : une dépendance centrale change les règles, et les projets non maintenus s’effondrent.

Pour votre stack self-hosted, cela implique trois réflexes :

Surveillez la santé des projets. Un outil dont le dernier commit remonte à plus de six mois est un candidat au prochain breaking change. Vérifiez la fréquence des releases, le nombre de contributeurs actifs et la réactivité sur les issues.

Pincez vos versions Docker. Ne laissez pas apt upgrade mettre à jour Docker automatiquement. Utilisez apt-mark hold docker-ce et planifiez vos mises à jour manuellement, après avoir vérifié la compatibilité de chaque outil.

Préparez un plan B. Pour chaque outil critique de votre stack, identifiez une alternative maintenue. Si vous utilisez Watchtower, regardez Diun. Si vous utilisez Swarmpit, migrez vers Portainer. Si vous utilisez Yacht, passez à Dockge — en gardant un oeil sur sa compatibilité v29.

L’auto-hébergement reste une stratégie viable pour les PME qui veulent maîtriser leurs coûts et leurs données. Mais il exige une veille active sur les outils que vous déployez. Docker v29 vient de rappeler cette réalité à l’ensemble de l’écosystème.