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

Open Activiteitenweergave of Taakbeheer, start een kleine container, en Docker Desktop kan alsnog het luidruchtigste ding op de machine worden. In een Docker Desktop-issue van februari 2026meldde een gebruiker dat com.docker.backend.exe na het starten van de containers naar 100% CPU klom en zelfs doorging nadat de containers waren gestopt.

Er is een andere zet: haal de daemon helemaal van je laptop. Houd alleen de Docker-CLI lokaal, draai Docker Engine op een Linux-VPS en richt docker context er via SSH op. Je docker build verandert niet. De build draait gewoon ergens anders, op native Linux zonder VM-laag, waarbij de bandbreedte van de VPS de basis-images binnenhaalt in plaats van je café-wifi, en zonder een Docker Desktop-licentie om bij te houden.

Dit is de volledige opzet voor dat pad: vereisten, de exacte docker context commando's, multi-arch builds met een externe buildx-driver, hoe je de machine dimensioneert, en waar de externe aanpak de verkeerde keuze is.

TL;DR

• Het probleem: Docker Desktop sleept een lokale VM mee, duwt bestands-I/O door een virtualisatielaag, en vereist een betaald abonnement voor professioneel gebruik in grotere organisaties, waaronder bedrijven voorbij de gratis-tier-limieten van Docker.
• De oplossing: verwijder Docker Desktop. Draai Docker Engine op een Linux-VPS, maak een docker context die er via SSH op wijst, en je lokale docker build draait op de VPS terwijl je CLI alleen orkestreert.
• Het kostenkader: één bescheiden VPS vervangt een licentie per zetel en geeft je native Linux-buildsnelheid. Een heel team kan één build-machine delen in plaats van per ontwikkelaar te betalen.
• De eerlijke voorbehouden: de VPS moet bereikbaar zijn (niet bouwen in een vliegtuig), en je hebt discipline nodig met .dockerignore zodat je niet bij elke run een build-context van meerdere gigabytes uploadt.

Vereisten: wat je nodig hebt

Vóór het eerste commando, leg dit klaar. Niets hier is exotisch als je Docker al dagelijks gebruikt.

• A Linux VPS met root- of sudo-toegang. Ubuntu 22.04/24.04 of Debian 12/13 werken allemaal prima.
• Docker Engine op de VPS. docker context via SSH heeft Docker Engine 18.09 of nieuwer op de externe host nodig, volgens de Docker-context-documentatie.
• Docker CLI 19.03 of nieuwer lokaal. Dat is de client die het top-level commando context commando begrijpt.
• An Een SSH-sleutelpaar. Alleen sleutelgebaseerde authenticatie: wachtwoordauthenticatie wordt niet ondersteund voor docker context SSH-verbindingen.
• De externe gebruiker in de groep docker groep, zodat die zonder sudo bij elke aanroep met de daemon-socket kan praten.

Wat Docker Desktop je echt kost

De kosten zijn geen mysterie. Ze landen op drie plekken, en wie zich hierheen heeft gezocht, heeft er minstens één van gevoeld. Ze precies benoemen is het punt. De pijn ken je al.

Geheugen en VM-overhead. Docker Desktop betekent nog steeds een lokale Linux-VM. De Docker-instellingendocumentatie zegt dat Docker Desktop kan beperken hoeveel geheugen de Docker Desktop-VM gebruikt, wat het stille deel van het probleem is: er zit nog steeds een VM in de lus. De exacte voetafdruk varieert per besturingssysteem en project, maar de faalmodi zijn reëel. Een Docker voor Windows-issue meldt dat Docker Desktop vele gigabytes RAM verbruikt zonder dat er een container draait, en een WSL2-issue beschrijft Docker-builds die geheugen niet vrijgeven nadat containers zijn beëindigd. Het punt is niet dat elke machine op hetzelfde getal inactief staat. Het is dat Docker Desktop de lokale VM-overhead binnen je ontwikkellus houdt.

Build- en bestands-I/O-snelheid. Bind-mounts en bestandsbewerkingen die de VM-grens oversteken zijn trager dan native toegang tot het Linux-bestandssysteem. De Docker-documentatie over bekende problemen erkent de kosten van het virtualisatiebestandssysteem. Community-benchmarks melden routinematig iets in de orde van 3-10x trager voor bind-mounts door de VM-laag. Dat tweede getal is community-ervaring, geen door Docker gepubliceerde benchmark, maar de richting wordt niet betwist door iemand die een build op een Mac heeft zien kruipen.

Licentiëring. Sinds de wijziging van 2021 vereist Docker Desktop een betaald abonnement voor bedrijven met meer dan 250 werknemers of boven 10 mln. $ omzet. De huidige niveaus op de Docker-prijzenpagina zijn Personal ($0), Pro ($11/mo of $9 per jaar), Team ($16/mo of $15 per jaar) en Business ($24/mo). Het Team-niveau ging in december 2024 van $9 naar $15 per jaar, een sprong die een stille post in een inkoopgesprek verandert, en dat is het deel dat echt pijn doet wanneer je het over dertig zetels vermenigvuldigt.

De alternatieven en de splitsing lokaal versus extern

Bijna elk Docker Desktop-alternatief dat je vindt, ruilt één lokale daemon in voor een andere lokale daemon. Dat is de echte as om op te merken: de keuze waarover de meesten piekeren gaat tussen lokale tools, terwijl de interessantere splitsing lokaal versus extern is. Alleen het externe pad haalt de VM van je machine.

Hier is het landschap, naast elkaar.

Een paar hiervan verdienen een zin eerlijkheid:

• OrbStack lost het Mac-resourceprobleem voor een solo-ontwikkelaar echt op. Het claimt ~300 MB inactief en tot 10x snellere containerstart (de OrbStack-site), beide leverancierscijfers, geen onafhankelijke benchmarks. Als je een Mac-only-ontwikkelaar bent die geen externe infrastructuur wil beheren, is OrbStack de betere keuze, en het commerciële niveau van $8/mo (OrbStack-prijzen) gaat onder het Team-niveau van Docker Desktop. Het addertje: het is alleen voor Mac, en de commerciële licentie brengt precies terug waaraan je probeerde te ontsnappen.
• Colima is gratis en CLI-first, maar de "geen directe vervanging"-ruwe randen zijn goed gedocumenteerd, en sommige teams belanden na een vastgelopen migratie weer bij Docker Desktop.
• Podman Desktop en Rancher Desktop zijn beide gratis en platformonafhankelijk. Geen van beide is een stille vervanging, en de Compose-compatibiliteit van Podman loopt via zijn Docker-compatibele socket.
• Docker Offload is Dockers eigen beheerde dienst voor extern bouwen/uitvoeren, maar het is geen schone uitstap uit Docker Desktop. De huidige Docker-documentatie noemt het iets dat Docker Desktop 4.68 of nieuwer, een Docker Business-abonnement en een Docker Offload-abonnement vereist. Het draait workloads op door Docker beheerde cloud-hosts, maar elke gebruiker krijgt één Offload-sessie tegelijk, inactieve sessies eindigen na een respijtperiode van 5 minuten, en de omgeving is kortstondig, dus containers, images en volumes verdwijnen wanneer de sessie eindigt. Dat is prima als je beheerde externe capaciteit binnen Docker Desktop wilt. Het is niet hetzelfde als een blijvende VPS-builder met je eigen cache, schijf, root-toegang en zonder Desktop-afhankelijkheid.

Blijven zitten is nog in één geval rationeel: een individu onder de gratis-drempel zonder buildsnelheidspijn heeft geen reden om iets te veranderen. Alle anderen hebben een splitsing te maken.

Kernpunt van deze sectie: de beslissing die telt is niet welke lokale tool je kiest. Het is of je überhaupt een daemon op je laptop houdt.

Hoe docker context over SSH werkt

Om Docker-images op een externe server via SSH te bouwen, draai je Docker Engine op die server, maak je een docker context die ernaar wijst met docker context create name --docker "host=ssh://user@host", voer je vervolgens docker context use nameuit. Daarna draait je normale docker build op de externe host, en de lokale CLI stuurt alleen instructies terwijl de daemon het werk doet.

Een context is een benoemd, omschakelbaar doel voor de Docker-CLI. In plaats van elke keer te goochelen met omgevingsvariabelen DOCKER_HOST of met de hand een SSH-tunnel op te tuigen, definieer je de externe host één keer en schakel je ernaar zoals je van map wisselt. De build draait volledig op de externe host: basis-image-pulls gebruiken de uplink van de VPS, lagen cachen op de schijf van de VPS, en CPU-werk gebeurt op de kernen van de VPS. De enige latentiegevoelige stappen zijn de initiële SSH-handshake en het uploaden van je build-context. Al het overige is extern.

Je VPS-build-machine opzetten

De hele opzet is vier korte commando's plus een SSH-configuratieblok. Ik toon de verwachte output waar die je helpt te bevestigen dat elke stap is geland.

Stap 1: Krijg Docker Engine op een Linux-VPS. Voorzie de machine en installeer Docker Engine (18.09+ op de externe host is de ondergrens voor context-SSH; je lokale CLI heeft 19.03+ nodig). Als je de installatie liever niet zelf doet, deploy dan een VPS die het al meelevert (meer daarover hieronder). De externe gebruiker moet in de docker-groep zitten:

sudo usermod -aG docker $USER

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

Stap 2: Stel SSH-sleutelauthenticatie en een configuratie-alias in. Sleutelgebaseerde authenticatie is verplicht. Geef de host een korte alias in ~/.ssh/config zodat je het IP en het sleutelpad niet opnieuw hoeft te typen:

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

Stap 3: Maak de context. Richt hem via SSH op de externe daemon. Gebruik de uitgeschreven vorm:

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

Of, met de SSH-configuratie-alias uit stap 2:

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

Stap 4: Verifieer. Lijst je contexten op en controleer of de externe engine antwoordt:

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

Als dat de serverversie van de externe daemon afdrukt, praat je CLI met de VPS.

Stap 5: Schakel en bouw. Maak de VPS het actieve doel, bouw dan zoals normaal:

docker context use my-vps

docker build -t myapp .

Die build draait op de VPS. Liever niet globaal wisselen? Richt op één enkel commando:

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

Of stel het in voor de shell-sessie:

export DOCKER_CONTEXT=my-vps

Wanneer je de lokale daemon van je laptop terugwilt (als je er een hebt gehouden), ga terug naar huis:

docker context use default

Pro-tip: let op je .dockerignore. De build-context wordt vóór het starten van de build naar de externe host geüpload. Een verdwaalde node_modules or .git map betekent dat je bij elke run gigabytes over de lijn stuurt, en het externe pad voelt zonder goede reden trager aan dan lokaal. Een strakke .dockerignore is het ene ding dat het meest bepaalt of het externe pad snel aanvoelt: sluit afhankelijkheden, build-artefacten en VCS-metadata uit, en de upload wordt een afrondingsfout.

Multi-arch builds met een externe buildx-driver

Maak een buildx-builder die BuildKit in een container op de externe Docker-host draait, en bouw er dan tegenaan:

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 .

De --load -vlag is belangrijk voor lokaal verbruik op één platform: met de docker-container -driver verschijnen gebouwde images niet automatisch in je lokale image-lijst. Als je een echt multi-platform-image bouwt, duw het dan in plaats daarvan naar een registry:

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

Dat onderscheid is belangrijk. Een externe build voor één platform kan terug in je lokale image-opslag worden geladen. Een multi-platform-image wordt meestal naar een registry geduwd, omdat het een manifest-lijst is met aparte varianten voor elke doelarchitectuur. Deze sectie is optioneel: als al je images single-arch zijn, is de context-opzet hierboven het hele werk.

De build-machine dimensioneren en beveiligen

Twee vragen bepalen of deze machine je goed dient: hoe groot je hem maakt, en hoe je de daemon vergrendeld houdt. Docker-builds zijn CPU-gebonden, dus de dimensioneringslogica gaat vooral over kernen en genoeg RAM om swap te vermijden. De beveiligingslogica gaat vooral over de daemon aan niemand behalve jou blootstellen.

Op welke grootte je hem zet

Geef hem generieke specificaties. Je kunt ze afbeelden op wat je provider ook aanbiedt.

• Ondergrens (één ontwikkelaar, lichte builds): 2 vCPU / 4 GB RAM / ~120 GB NVMe. This is the minimum that works, not what I'd reach for.
• Wat ik daadwerkelijk zou deployen (de meeste teams): 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.
• Team of zware CI: 8 vCPU / 16-24 GB RAM for several developers sharing one box or big multi-stage Dockerfiles.

Omdat builds CPU-gebonden zijn, kopen hoogfrequente (CPU-geoptimaliseerde) kernen je meer snelle iteratie dan extra RAM voorbij de swap-drempel. GPU-plannen zijn hier irrelevant, aangezien image-builds de GPU niet raken. En de keuze van datacenter beïnvloedt alleen de SSH-responsiviteit en de tijd om de context te uploaden, niet de buildsnelheid: de build draait op de VPS ongeacht waar je zit, dus kies een locatie dicht bij je voor een vlotte handshake en ga verder.

De externe daemon beveiligen

De opzet hierboven dwingt de juiste standaard al af: SSH-sleutelauthenticatie, geen daemon-poort blootgesteld aan het netwerk. Houd het zo. Op het moment dat je BuildKit of de daemon voorbij SSH blootstelt (een rauw TCP-eindpunt, een open BuildKit-poort), word je een doelwit. De Hacker News-thread over trage builds die het idee van de externe VPS voor het eerst opwierp, waarschuwde ook voor cryptomining-aanvallen op blootgestelde BuildKit-eindpunten. Een niet-geauthenticeerde build-daemon op het open internet is een gratis reken-buffet.

Pro-tip: stel de daemon niet bloot. Als alleen SSH genoeg voor je is (dat is het voor de meeste enkele-machine-opzetten), open dan nooit een daemon-TCP-poort . Als je echt TCP-toegang nodig hebt, zet er wederzijdse TLS (mTLS) voor zodat alleen clients met een geldig certificaat kunnen verbinden. Alleen SSH of mTLS: er is geen aanvaardbare derde optie voor een vanaf het internet bereikbare build-machine.

Zodra de machine draait, is het een Linux-server voor algemeen gebruik, en er is nog veel meer dat de moeite waard is om erop te draaien. Onze gids voor de self-hosted stack voor indie hackers is een zinvolle volgende leestip over wat er nog meer een plek op je VPS verdient.

Als je de Docker Engine-installatie liever overslaat en meteen naar docker context creategaat, deployt onze Docker-marketplace-app een VPS met Docker Engine, Compose V2 en buildx al geconfigureerd. Eén klik en de machine is SSH-klaar, dus de doorloop hierboven begint bij stap 2 in plaats van stap 1.

Veelgestelde vragen

Kan ik Docker-builds op een externe server draaien en mijn lokale CLI gebruiken?

Ja. Draai Docker Engine op de externe host, maak een docker context die er via SSH op wijst, en schakel naar die context. Je lokale docker build draait dan op de externe server terwijl de CLI op je machine alleen orkestreert, zonder dat een lokale daemon nodig is.

Wat is het verschil tussen docker context en DOCKER_HOST?

A docker context is een benoemd, omschakelbaar, blijvend doel dat je één keer definieert en selecteert met docker context use. DOCKER_HOST is één enkele omgevingsvariabele die je voor elke shell met de hand instelt en weer verwijdert. De context is de moderne vervanging van de oude aanpak met tunnel plus omgevingsvariabele.

Werkt docker compose met een externe context?

Ja. Compose V2 respecteert de actieve Docker-context, dus docker compose -commando's draaien tegen de host waar de context naar wijst. De diensten en eventuele image-builds draaien op de externe host, net als een gewone docker build.

Wat is Docker Offload en is het gratis?

Docker Offload is Dockers eigen beheerde dienst voor extern bouwen/uitvoeren om containerwerk te verplaatsen naar door Docker beheerde cloud-hosts terwijl de Docker Desktop-workflow behouden blijft. De huidige Docker-documentatie noemt het iets dat Docker Desktop 4.68 of nieuwer vereist, plus Docker Business- en Docker Offload-abonnementen. Het is ook sessiegebaseerd: elke gebruiker krijgt één Offload-sessie tegelijk, inactieve sessies eindigen na een respijtperiode van 5 minuten, en de externe omgeving is kortstondig.

Hoe stop ik Docker Desktop van zoveel geheugen gebruiken?

Het afstemmen van de resource-limieten van Docker Desktop verkleint alleen een voetafdruk die nooit naar nul gaat, omdat de VM altijd een ondergrens heeft. Het pad dat de geheugenkosten echt wegneemt, is de lokale daemon helemaal verwijderen: draai Docker Engine op een VPS en verbind via docker context over SSH, zodat er op je machine niets anders dan de CLI draait.

Kan ik dit in plaats daarvan met Podman doen?

Dat kan. Podman is beschikbaar als Docker-compatibele engine, en docker context kan naar een externe Podman-host wijzen, maar dat vereist dat Podman zijn Docker-compatibele socket via SSH beschikbaar stelt. De commandostroom is hetzelfde. De opzet aan de externe kant verschilt.