Stop Running Docker Desktop: Offload Your Builds to a VPS Instead

Ouvrez le Moniteur d'activité ou le Gestionnaire des tâches, démarrez un petit conteneur, et Docker Desktop peut malgré tout devenir l'élément le plus gourmand de la machine. Dans un ticket Docker Desktop de février 2026, un utilisateur a signalé com.docker.backend.exe une montée à 100 % de CPU après le démarrage des conteneurs, qui se poursuivait même après leur arrêt.

Il existe une autre approche : retirez complètement le démon de votre ordinateur portable. Conservez uniquement la CLI Docker en local, exécutez Docker Engine sur un VPS Linux, et pointez docker context vers lui via SSH. Votre docker build commande ne change pas. Le build s'exécute simplement ailleurs, sur du Linux natif sans couche de VM, avec la bande passante du VPS pour télécharger les images de base au lieu du Wi-Fi de votre café, et sans licence Docker Desktop à suivre.

Voici la configuration complète pour cette approche : les prérequis, les docker context commandes exactes, les builds multi-architectures avec un pilote buildx distant, comment dimensionner la machine, et les cas où l'approche distante est un mauvais choix.

En bref

• Le problème : Docker Desktop embarque une VM locale, fait passer les E/S de fichiers par une couche de virtualisation, et exige un abonnement payant pour un usage professionnel dans les grandes organisations, y compris les entreprises au-delà des limites de l'offre gratuite de Docker.
• La solution : Supprimez Docker Desktop. Exécutez Docker Engine sur un VPS Linux, créez un docker context qui pointe vers lui via SSH, et votre docker build local s'exécute sur le VPS pendant que votre CLI se contente d'orchestrer.
• Le cadre des coûts : Un VPS modeste remplace une licence par siège et vous offre la vitesse de build de Linux natif. Une équipe entière peut partager une seule machine de build au lieu de payer par développeur.
• Les réserves en toute honnêteté : Le VPS doit être joignable (pas de build dans un avion), et vous avez besoin de .dockerignore discipline pour ne pas téléverser un contexte de build de plusieurs gigaoctets à chaque exécution.

Prérequis : ce dont vous aurez besoin

Avant la première commande, préparez ces éléments. Rien ici n'est exotique si vous utilisez déjà Docker au quotidien.

• A Linux VPS avec un accès root ou sudo. Ubuntu 22.04/24.04 ou Debian 12/13 conviennent tous.
• Docker Engine sur le VPS. docker context via SSH nécessite Docker Engine 18.09 ou plus récent sur l'hôte distant, selon la documentation de Docker context.
• Docker CLI 19.03 ou plus récent en local. C'est le client qui comprend la commande de premier niveau context commande.
• An Paire de clés SSH. Authentification par clé uniquement : l'authentification par mot de passe n'est pas prise en charge for docker context pour les connexions SSH.
• The l'utilisateur distant dans le docker groupe, afin qu'il puisse dialoguer avec le socket du démon sans sudo à chaque appel.

Ce que Docker Desktop vous coûte réellement

Les coûts n'ont rien de mystérieux. Ils se logent à trois endroits, et le lecteur qui est arrivé ici par une recherche en a ressenti au moins un. Le but est de les nommer précisément. Vous connaissez déjà la douleur.

Surcharge de mémoire et de VM. Docker Desktop implique toujours une VM Linux locale. La documentation des paramètres Docker indique que Docker Desktop peut limiter la quantité de mémoire utilisée par la VM de Docker Desktop, ce qui est la partie tue du problème : il y a toujours une VM dans la boucle. L'empreinte exacte varie selon l'OS et le projet, mais les modes de défaillance sont réels. Un ticket Docker for Windows signale que Docker Desktop consomme plusieurs gigaoctets de RAM sans qu'aucun conteneur ne tourne, et un ticket WSL2 décrit des builds Docker laissant de la mémoire non libérée après l'arrêt des conteneurs. Le point n'est pas que chaque machine tourne au ralenti au même chiffre. C'est que Docker Desktop maintient la surcharge d'une VM locale au sein de votre boucle de développement.

Vitesse de build et d'E/S de fichiers. Les montages bind et les opérations de fichiers qui franchissent la frontière de la VM sont plus lents qu'un accès au système de fichiers Linux natif. La documentation des problèmes connus de Docker reconnaît le coût du système de fichiers de virtualisation. Les benchmarks de la communauté rapportent régulièrement quelque chose de l'ordre de 3 à 10 fois plus lent pour les montages bind à travers la couche de VM. Ce second chiffre relève de l'expérience de la communauté, pas d'un benchmark publié par Docker, mais quiconque a regardé un build patiner sur un Mac ne conteste pas la tendance.

Licences. Depuis le changement de 2021, Docker Desktop exige un abonnement payant pour les entreprises de plus de 250 employés ou dépassant 10 M$ de chiffre d'affaires. Les paliers actuels sur la page de tarification de Docker sont Personal ($0), Pro ($11/mo ou $9 en annuel), Team ($16/mo ou $15 en annuel) et Business ($24/mo). Le palier Team est passé de $9 à $15 en annuel en décembre 2024, un bond qui transforme un poste discret en une discussion d'achat, et c'est la partie qui pique vraiment quand vous la multipliez par trente sièges.

Les alternatives, et le choix local ou distant

Presque toutes les alternatives à Docker Desktop que vous trouverez remplacent un démon local par un autre démon local. C'est le véritable axe à remarquer : le choix sur lequel la plupart des gens se torturent oppose des outils locaux, alors que le vrai choix intéressant est local contre distant. Seule la voie distante retire la VM de votre machine.

Voici le paysage, côte à côte.

Quelques-uns méritent une phrase de franchise :

• OrbStack résout véritablement le problème de ressources sur Mac pour un développeur seul. Il annonce ~300 MB au repos et un démarrage de conteneur jusqu'à 10 fois plus rapide (le site d'OrbStack), deux chiffres de l'éditeur, pas des benchmarks indépendants. Si vous êtes un développeur exclusivement sur Mac qui ne veut pas gérer d'infrastructure distante, OrbStack est le meilleur choix, et son palier commercial à $8/mo (tarification d'OrbStack) reste sous le palier Team de Docker Desktop. Le hic : il est réservé à Mac, et la licence commerciale ramène précisément ce que vous cherchiez à fuir.
• Colima est gratuit et pensé pour la CLI d'abord, mais ses aspérités de « remplacement non immédiat » sont bien documentées, et certaines équipes finissent par revenir à Docker Desktop après une migration qui s'enlise.
• Podman Desktop et Rancher Desktop sont tous deux gratuits et multiplateformes. Aucun n'est un remplacement silencieux, et la compatibilité Compose de Podman passe par son socket compatible Docker.
• Docker Offload est le service géré de build/exécution distant de Docker, mais ce n'est pas une sortie propre de Docker Desktop. La documentation actuelle de Docker le présente comme nécessitant Docker Desktop 4.68 ou plus récent, un abonnement Docker Business et un abonnement Docker Offload. Il exécute les charges de travail sur des hôtes cloud gérés par Docker, mais chaque utilisateur obtient une seule session Offload à la fois, les sessions inactives se terminent après un délai de grâce de 5 minutes, et l'environnement est éphémère, de sorte que conteneurs, images et volumes disparaissent à la fin de la session. C'est très bien si vous voulez une capacité distante gérée au sein de Docker Desktop. Ce n'est pas la même chose qu'un builder VPS persistant avec votre propre cache, votre disque, un accès root et aucune dépendance à Desktop.

Ne rien changer reste rationnel dans un cas : un particulier sous le seuil de l'offre gratuite et sans problème de vitesse de build n'a aucune raison de changer quoi que ce soit. Tous les autres ont un choix à faire.

À retenir de cette section : la décision qui compte n'est pas de savoir quel outil local choisir. C'est de savoir si vous conservez ou non un démon sur votre ordinateur portable.

Comment fonctionne docker context via SSH

Pour construire des images Docker sur un serveur distant via SSH, exécutez Docker Engine sur ce serveur, créez un docker context qui pointe vers lui avec docker context create name --docker "host=ssh://user@host", puis lancez docker context use name. Ensuite, votre docker build habituel s'exécute sur l'hôte distant, et la CLI locale se contente d'envoyer des instructions pendant que le démon fait le travail.

Un contexte est une cible nommée et interchangeable pour la CLI Docker. Au lieu de jongler avec des DOCKER_HOST variables d'environnement ou de bricoler un tunnel SSH à chaque fois, vous définissez l'hôte distant une seule fois et vous y basculez comme vous changeriez de répertoire. Le build s'exécute entièrement sur l'hôte distant : les téléchargements d'images de base utilisent le lien montant du VPS, les couches sont mises en cache sur le disque du VPS, et le travail CPU a lieu sur les cœurs du VPS. Les seules étapes sensibles à la latence sont la poignée de main SSH initiale et le téléversement de votre contexte de build. Tout le reste est distant.

Configurer votre machine de build sur VPS

Toute la configuration tient en quatre commandes courtes plus un bloc de configuration SSH. Je montrerai la sortie attendue là où cela vous aide à confirmer que chaque étape a réussi.

Étape 1 : installez Docker Engine sur un VPS Linux. Provisionnez la machine et installez Docker Engine (18.09+ sur l'hôte distant est le minimum pour le contexte SSH ; votre CLI locale a besoin de 19.03+). Si vous préférez ne pas faire l'installation vous-même, déployez un VPS qui l'embarque déjà (plus de détails ci-dessous). L'utilisateur distant doit appartenir au groupe docker :

sudo usermod -aG docker $USER

# log out and back in for the group change to take effect

Étape 2 : configurez l'authentification par clé SSH et un alias de configuration. L'authentification par clé est requise. Donnez à l'hôte un alias court dans ~/.ssh/config pour ne pas ressaisir l'IP et le chemin de la clé :

# ~/.ssh/config
Host my-vps
  HostName 1.2.3.4
  User ubuntu
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

Étape 3 : créez le contexte. Pointez-le vers le démon distant via SSH. Utilisez la forme brute :

docker context create my-vps --docker "host=ssh://[email protected]"

Ou, en utilisant l'alias de configuration SSH de l'étape 2 :

docker context create my-vps --docker "host=ssh://my-vps"

Étape 4 : vérifiez. Listez vos contextes et vérifiez que le moteur distant répond :

docker context ls

NAME        DESCRIPTION                               DOCKER ENDPOINT
default *   Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
my-vps                                                ssh://my-vps

docker --context=my-vps version

Si cela affiche la version serveur du démon distant, votre CLI dialogue bien avec le VPS.

Étape 5 : basculez et construisez. Faites du VPS la cible active, puis construisez normalement :

docker context use my-vps

docker build -t myapp .

Ce build s'exécute sur le VPS. Vous préférez ne pas basculer globalement ? Ciblez une seule commande :

docker --context=my-vps build -t myapp .

Ou définissez-le pour la session du shell :

export DOCKER_CONTEXT=my-vps

Quand vous voulez récupérer le démon local de votre ordinateur portable (si vous en avez gardé un), rebasculez chez vous :

docker context use default

Astuce de pro : surveillez votre .dockerignore. Le contexte de build est téléversé vers l'hôte distant avant le début du build. Un répertoire node_modules or .git égaré signifie que vous envoyez des gigaoctets sur le réseau à chaque exécution, et la voie distante paraîtra plus lente que le local sans bonne raison. Un .dockerignore bien réglé est ce qui influe le plus sur la sensation de rapidité de la voie distante : excluez les dépendances, les artefacts de build et les métadonnées de VCS, et le téléversement devient négligeable.

Builds multi-architectures avec un pilote buildx distant

Créez un builder buildx qui exécute BuildKit dans un conteneur sur l'hôte Docker distant, puis construisez avec lui :

docker buildx create --name remote-builder \
  --driver docker-container \
  --use \
  ssh://ubuntu@your-vps-ip

docker buildx inspect --bootstrap

docker buildx build \
  --builder remote-builder \
  --platform linux/amd64 \
  -t myapp:latest \
  --load .

The --load compte pour une consommation locale sur une seule plateforme : avec le pilote docker-container driver, les images construites n'apparaissent pas automatiquement dans votre liste d'images locale. Si vous construisez une véritable image multiplateforme, poussez-la plutôt vers un registre :

docker buildx build \
  --builder remote-builder \
  --platform linux/amd64,linux/arm64 \
  -t registry.example.com/myapp:latest \
  --push .

Cette distinction est importante. Un build distant sur une seule plateforme peut être rechargé dans votre magasin d'images local. Une image multiplateforme est généralement poussée vers un registre, car il s'agit d'une liste de manifestes avec des variantes distinctes pour chaque architecture cible. Cette section est facultative : si toutes vos images sont mono-architecture, la configuration de contexte ci-dessus suffit.

Dimensionner et sécuriser la machine de build

Deux questions décident si cette machine vous sert bien : quelle taille lui donner, et comment garder le démon verrouillé. Les builds Docker sont limités par le CPU, si bien que la logique de dimensionnement porte surtout sur les cœurs et sur une RAM suffisante pour éviter le swap. La logique de sécurité consiste surtout à n'exposer le démon à personne d'autre que vous.

Comment le dimensionner

Donnez-lui des specs génériques. Vous pouvez les rapporter à ce que propose votre fournisseur.

• Minimum (un seul développeur, builds légers) : 2 vCPU / 4 GB RAM / ~120 GB NVMe. This is the minimum that works, not what I'd reach for.
• Ce que je déploierais réellement (la plupart des équipes) : 4 vCPU / 8-12 GB RAM / 240-300 GB NVMe. Four vCPUs stop your parallel build steps from serializing, 8-12 GB handles concurrent builds without touching swap, and the NVMe headroom keeps a healthy layer cache.
• Équipe ou CI intensive : 8 vCPU / 16-24 GB RAM for several developers sharing one box or big multi-stage Dockerfiles.

Comme les builds sont limités par le CPU, des cœurs à haute fréquence (optimisés CPU) vous offrent une itération plus rapide que de la RAM supplémentaire une fois franchi le seuil de swap. Les plans GPU sont sans intérêt ici, puisque les builds d'images ne touchent pas le GPU. Et le choix du datacenter n'influe que sur la réactivité SSH et le temps de téléversement du contexte, pas sur la vitesse de build : le build s'exécute sur le VPS quel que soit l'endroit où vous vous trouvez, alors choisissez un emplacement proche de vous pour une poignée de main réactive et passez à autre chose.

Sécuriser le démon distant

La configuration ci-dessus impose déjà le bon réglage par défaut : authentification par clé SSH, aucun port de démon exposé au réseau. Gardez-le ainsi. Dès l'instant où vous exposez BuildKit ou le démon au-delà de SSH (un point de terminaison TCP brut, un port BuildKit ouvert), vous devenez une cible. Le fil Hacker News sur les builds lents qui a lancé l'idée du VPS distant mettait aussi en garde contre les attaques de cryptominage sur les points de terminaison BuildKit exposés. Un démon de build non authentifié sur l'internet ouvert est un buffet de calcul gratuit.

Astuce de pro : n'exposez pas le démon. Si le tout-SSH vous suffit (c'est le cas pour la plupart des configurations à une seule machine), n'ouvrez jamais de port TCP du démon , tout simplement. Si vous avez vraiment besoin d'un accès TCP, placez du TLS mutuel (mTLS) devant lui pour que seuls les clients disposant d'un certificat valide puissent se connecter. Tout-SSH ou mTLS : il n'y a pas de troisième option acceptable pour une machine de build joignable depuis internet.

Une fois la machine en route, c'est un serveur Linux polyvalent, et bien d'autres choses méritent d'y tourner. Notre guide de la pile auto-hébergée pour indie hackers est une lecture toute indiquée pour la suite, sur ce qui mérite aussi une place sur votre VPS.

Si vous préférez sauter l'installation de Docker Engine et passer directement à docker context create, notre application Docker de la marketplace déploie un VPS avec Docker Engine, Compose V2 et buildx déjà configurés. Un clic et la machine est prête pour SSH, si bien que le tutoriel ci-dessus commence à l'étape 2 au lieu de l'étape 1.

Foire aux questions

Puis-je exécuter des builds Docker sur un serveur distant et utiliser ma CLI locale ?

Oui. Exécutez Docker Engine sur l'hôte distant, créez un docker context qui pointe vers lui via SSH, et basculez sur ce contexte. Votre docker build local s'exécute alors sur le serveur distant tandis que la CLI de votre machine se contente d'orchestrer, sans qu'aucun démon local ne soit requis.

Quelle est la différence entre docker context et DOCKER_HOST ?

A docker context est une cible nommée, interchangeable et persistante que vous définissez une fois et sélectionnez avec docker context use. DOCKER_HOST est une simple variable d'environnement que vous définissez et supprimez manuellement pour chaque shell. Le contexte est le remplacement moderne de l'ancienne approche tunnel plus variable d'environnement.

docker compose fonctionne-t-il avec un contexte distant ?

Oui. Compose V2 respecte le contexte Docker actif, de sorte que les docker compose commandes s'exécutent sur l'hôte vers lequel pointe le contexte. Les services et tous les builds d'images s'exécutent sur l'hôte distant, comme pour un simple docker build.

Qu'est-ce que Docker Offload et est-il gratuit ?

Docker Offload est le service géré de build/exécution distant de Docker qui déplace le travail de conteneurs vers des hôtes cloud gérés par Docker tout en conservant le flux de travail de Docker Desktop. La documentation actuelle de Docker le présente comme nécessitant Docker Desktop 4.68 ou plus récent, ainsi que des abonnements Docker Business et Docker Offload. Il fonctionne aussi par session : chaque utilisateur obtient une seule session Offload à la fois, les sessions inactives se terminent après un délai de grâce de 5 minutes, et l'environnement distant est éphémère.

Comment empêcher Docker Desktop de consommer autant de mémoire ?

Ajuster les limites de ressources de Docker Desktop ne fait que réduire une empreinte qui ne descend jamais à zéro, car la VM a toujours un plancher. La voie qui supprime réellement le coût mémoire consiste à retirer entièrement le démon local : exécutez Docker Engine sur un VPS et connectez-vous via docker context SSH, de sorte que seule la CLI tourne sur votre machine.

Puis-je faire cela avec Podman à la place ?

Oui. Podman est disponible comme moteur compatible Docker, et docker context peut pointer vers un hôte Podman distant, mais cela exige que Podman expose son socket compatible Docker via SSH. Le déroulement des commandes est le même. La configuration côté distant diffère.