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

Åbn Aktivitetsovervågning eller Jobliste, start en lille container, og Docker Desktop kan stadig blive det mest støjende på maskinen. I et Docker Desktop-issue fra februar 2026rapporterede en bruger, at com.docker.backend.exe steg til 100 % CPU, efter at containerne startede, og fortsatte selv efter, at containerne var stoppet.

Der er et andet træk: tag daemonen helt af din laptop. Behold kun Docker-CLI'en lokalt, kør Docker Engine på en Linux-VPS, og peg docker context på den over SSH. Din docker build ændrer sig ikke. Buildet kører bare et andet sted, på native Linux uden VM-lag, hvor VPS'ens båndbredde henter basis-images i stedet for din café-wi-fi, og uden en Docker Desktop-licens at holde styr på.

Dette er hele opsætningen til den vej: forudsætninger, de præcise docker context kommandoer, multi-arch builds med en fjern buildx-driver, hvordan du dimensionerer maskinen, og hvor den fjerne tilgang er det forkerte valg.

TL;DR

• Problemet: Docker Desktop slæber en lokal VM med, presser fil-I/O gennem et virtualiseringslag og kræver et betalt abonnement til professionel brug i større organisationer, herunder virksomheder ud over gratis-niveauets grænser hos Docker.
• Løsningen: fjern Docker Desktop. Kør Docker Engine på en Linux-VPS, opret en docker context der peger på den over SSH, og din lokale docker build kører på VPS'en, mens din CLI blot orkestrerer.
• Omkostningsrammen: en beskeden VPS erstatter en licens pr. plads og giver dig native Linux-buildhastighed. Et helt team kan dele en enkelt build-maskine i stedet for at betale pr. udvikler.
• De ærlige forbehold: VPS'en skal være tilgængelig (ingen builds i et fly), og du har brug for disciplin med .dockerignore så du ikke uploader en build-kontekst på flere gigabyte ved hver kørsel.

Forudsætninger: hvad du får brug for

Før den første kommando, få styr på disse ting. Intet her er eksotisk, hvis du allerede bruger Docker til daglig.

• A Linux VPS med root- eller sudo-adgang. Ubuntu 22.04/24.04 eller Debian 12/13 fungerer alle fint.
• Docker Engine på VPS'en. docker context over SSH kræver Docker Engine 18.09 eller nyere på fjernværten, ifølge Dockers kontekst-dokumentation.
• Docker CLI 19.03 eller nyere lokalt. Det er den klient, der forstår topniveau-kommandoen context kommando.
• An Et SSH-nøglepar. Kun nøglebaseret autentificering: adgangskodeautentificering understøttes ikke til docker context SSH-forbindelser.
• Den fjerne bruger i gruppen docker gruppe, så den kan tale med daemon-socket'en uden sudo ved hvert kald.

Hvad Docker Desktop reelt koster dig

Omkostningerne er ingen gåde. De lander tre steder, og den, der har søgt sig hertil, har mærket mindst et af dem. At navngive dem præcist er pointen. Smerten kender du allerede.

Hukommelse og VM-overhead. Docker Desktop betyder stadig en lokal Linux-VM. Dockers indstillingsdokumentation siger, at Docker Desktop kan begrænse, hvor meget hukommelse Docker Desktop-VM'en bruger, hvilket er den stille del af problemet: der er stadig en VM i loopet. Det præcise aftryk varierer efter styresystem og projekt, men fejltilstandene er reelle. Et Docker for Windows-issue rapporterer, at Docker Desktop bruger mange gigabyte RAM uden nogen kørende container, og et WSL2-issue beskriver Docker-builds, der efterlader hukommelse ikke frigivet, efter at containere er afsluttet. Pointen er ikke, at hver maskine er inaktiv på det samme tal. Det er, at Docker Desktop holder det lokale VM-overhead inde i din udviklingsloop.

Build- og fil-I/O-hastighed. Bind-mounts og filoperationer, der krydser VM-grænsen, er langsommere end native adgang til Linux-filsystemet. Dockers dokumentation om kendte problemer anerkender omkostningen ved virtualiseringsfilsystemet. Fællesskabsbenchmarks rapporterer rutinemæssigt noget i omegnen af 3-10x langsommere for bind-mounts gennem VM-laget. Det andet tal er fællesskabserfaring, ikke et benchmark udgivet af Docker, men retningen bestrides ikke af nogen, der har set et build kravle på en Mac.

Licensering. Siden ændringen i 2021 kræver Docker Desktop et betalt abonnement for virksomheder med mere end 250 ansatte eller over 10 mio. $ i omsætning. De nuværende niveauer på Dockers prisside er Personal ($0), Pro ($11/mo eller $9 årligt), Team ($16/mo eller $15 årligt) og Business ($24/mo). Team-niveauet steg i december 2024 fra $9 til $15 årligt, et spring, der forvandler en stille post til en indkøbssamtale, og det er den del, der virkelig svier, når du ganger den med tredive pladser.

Alternativerne og forgreningen lokal versus fjern

Næsten hvert Docker Desktop-alternativ, du finder, bytter én lokal daemon ud med en anden lokal daemon. Det er den egentlige akse at bemærke: det valg, de fleste tumler med, er mellem lokale værktøjer, mens den mere interessante forgrening er lokal versus fjern. Kun den fjerne vej fjerner VM'en fra din maskine.

Her er landskabet, side om side.

Et par af disse fortjener en sætning ærlighed:

• OrbStack løser virkelig Mac-ressourceproblemet for en solo-udvikler. Den påstår ~300 MB inaktiv og op til 10x hurtigere containerstart (OrbStack-siden), begge leverandørtal, ikke uafhængige benchmarks. Hvis du er en Mac-only-udvikler, der ikke vil administrere fjern infrastruktur, er OrbStack det bedre valg, og dens kommercielle niveau på $8/mo (OrbStack-priser) underbyder Docker Desktops Team-niveau. Hagen: den er kun til Mac, og den kommercielle licens bringer præcis det tilbage, du forsøgte at slippe væk fra.
• Colima er gratis og CLI-first, men dens "ikke en direkte erstatning"-ru kanter er veldokumenterede, og nogle teams ender tilbage på Docker Desktop, efter at en migrering går i stå.
• Podman Desktop og Rancher Desktop er begge gratis og på tværs af platforme. Ingen af dem er en tavs erstatning, og Podmans Compose-kompatibilitet går gennem dens Docker-kompatible socket.
• Docker Offload er Dockers egen administrerede tjeneste til fjern build/kørsel, men det er ingen ren udgang fra Docker Desktop. Den nuværende Docker-dokumentation opfører det som noget, der kræver Docker Desktop 4.68 eller nyere, et Docker Business-abonnement og et Docker Offload-abonnement. Den kører workloads på Docker-administrerede cloud-værter, men hver bruger får én Offload-session ad gangen, inaktive sessioner afsluttes efter en frist på 5 minutter, og miljøet er flygtigt, så containere, images og volumener forsvinder, når sessionen slutter. Det er fint, hvis du vil have administreret fjern kapacitet inde i Docker Desktop. Det er ikke det samme som en vedvarende VPS-builder med din egen cache, disk, root-adgang og uden Desktop-afhængighed.

At blive siddende er stadig rationelt i ét tilfælde: en enkeltperson under gratis-tærsklen uden buildhastighedssmerte har ingen grund til at ændre noget. Alle andre har en forgrening at træffe.

Afsnittets hovedpointe: Beslutningen, der tæller, er ikke, hvilket lokalt værktøj man vælger. Det er, om du overhovedet beholder en daemon på din laptop.

Sådan fungerer docker context over SSH

For at bygge Docker-images på en fjernserver over SSH kører du Docker Engine på den server, opretter en docker context, der peger på den med docker context create name --docker "host=ssh://user@host"og kører derefter docker context use name. Derefter kører din normale docker build på fjernværten, og den lokale CLI sender kun instruktioner, mens daemonen udfører arbejdet.

En kontekst er et navngivet, omskifteligt mål for Docker-CLI'en. I stedet for at jonglere med miljøvariabler DOCKER_HOST eller håndlave en SSH-tunnel hver gang, definerer du fjernværten én gang og skifter til den, som du skifter mappe. Buildet kører helt på fjernværten: basis-image-pulls bruger VPS'ens uplink, lag caches på VPS'ens disk, og CPU-arbejdet sker på VPS'ens kerner. De eneste latensfølsomme trin er det indledende SSH-handshake og uploadet af din build-kontekst. Alt derefter er fjernt.

Sådan sætter du din VPS-build-maskine op

Hele opsætningen er fire korte kommandoer plus en SSH-konfigurationsblok. Jeg viser den forventede output, hvor den hjælper dig med at bekræfte, at hvert trin landede.

Trin 1: Få Docker Engine på en Linux-VPS. Klargør maskinen og installer Docker Engine (18.09+ på fjernværten er minimum for kontekst-SSH; din lokale CLI kræver 19.03+). Hvis du hellere ikke selv vil køre installationen, så deploy en VPS, der allerede leverer den (mere om det nedenfor). Fjernbrugeren skal være i docker-gruppen:

sudo usermod -aG docker $USER

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

Trin 2: Sæt SSH-nøgleautentificering og et konfigurations-alias op. Nøglebaseret autentificering er påkrævet. Giv værten et kort alias i ~/.ssh/config så du ikke skal gentaste IP'en og nøglestien:

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

Trin 3: Opret konteksten. Peg den på fjern-daemonen over SSH. Brug den fulde form:

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

Eller, med SSH-konfigurations-aliaset fra trin 2:

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

Trin 4: Verificér. Oplist dine kontekster og tjek, at fjern-enginen svarer:

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

Hvis det udskriver serverversionen af fjern-daemonen, taler din CLI med VPS'en.

Trin 5: Skift og byg. Gør VPS'en til det aktive mål, og byg så som normalt:

docker context use my-vps

docker build -t myapp .

Det build kører på VPS'en. Vil du hellere ikke skifte globalt? Sigt mod en enkelt kommando:

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

Eller sæt det for shell-sessionen:

export DOCKER_CONTEXT=my-vps

Når du vil have din laptops lokale daemon tilbage (hvis du beholdt en), så skift hjem:

docker context use default

Pro-tip: pas på din .dockerignore. Build-konteksten uploades til fjernværten, før buildet starter. En vildfaren node_modules or .git mappe betyder, at du sender gigabyte over ledningen ved hver kørsel, og den fjerne vej vil føles langsommere end lokalt uden god grund. En stram .dockerignore er den ene ting, der mest afgør, om den fjerne vej føles hurtig: udeluk afhængigheder, build-artefakter og VCS-metadata, og uploadet bliver en afrundingsfejl.

Multi-arch builds med en fjern buildx-driver

Opret en buildx-builder, der kører BuildKit i en container på fjern-Docker-værten, og byg så mod den:

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 .

Den --load -flaget er vigtigt for lokalt forbrug på én platform: med docker-container -driveren dukker byggede images ikke automatisk op på din lokale image-liste. Hvis du bygger et ægte multi-platform-image, så skub det i stedet til et registry:

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

Den skelnen er vigtig. Et fjern-build på én platform kan indlæses tilbage i din lokale image-lager. Et multi-platform-image skubbes normalt til et registry, fordi det er en manifest-liste med separate varianter for hver målarkitektur. Dette afsnit er valgfrit: hvis alle dine images er single-arch, er kontekst-opsætningen ovenfor hele arbejdet.

Dimensionering og sikring af build-maskinen

To spørgsmål afgør, om denne maskine tjener dig godt: hvor stor du gør den, og hvordan du holder daemonen låst ned. Docker-builds er CPU-bundne, så dimensioneringslogikken handler mest om kerner og nok RAM til at undgå swap. Sikkerhedslogikken handler mest om ikke at udsætte daemonen for andre end dig.

Hvilken størrelse du sætter den til

Giv den generiske specifikationer. Du kan afbilde dem på, hvad end din udbyder tilbyder.

• Bund (én udvikler, lette builds): 2 vCPU / 4 GB RAM / ~120 GB NVMe. This is the minimum that works, not what I'd reach for.
• Hvad jeg faktisk ville deploye (de fleste 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 eller tung CI: 8 vCPU / 16-24 GB RAM for several developers sharing one box or big multi-stage Dockerfiles.

Fordi builds er CPU-bundne, køber højfrekvente (CPU-optimerede) kerner dig hurtigere iteration mere end ekstra RAM ud over swap-tærsklen. GPU-planer er irrelevante her, da image-builds ikke rører GPU'en. Og valget af datacenter påvirker kun SSH-responsiviteten og tiden til at uploade konteksten, ikke buildhastigheden: buildet kører på VPS'en, uanset hvor du sidder, så vælg en placering tæt på dig for et hurtigt handshake, og gå videre.

Sikring af fjern-daemonen

Opsætningen ovenfor gennemtvinger allerede den rigtige standard: SSH-nøgleautentificering, ingen daemon-port udsat for netværket. Hold det sådan. I det øjeblik du udsætter BuildKit eller daemonen ud over SSH (et råt TCP-endpoint, en åben BuildKit-port), bliver du et mål. Hacker News-tråd om langsomme builds, der først rejste idéen om den fjerne VPS, advarede også om cryptomining-angreb på udsatte BuildKit-endpoints. En ikke-autentificeret build-daemon på det åbne internet er en gratis compute-buffet.

Pro-tip: udsæt ikke daemonen. Hvis kun SSH er nok for dig (det er det for de fleste enkelt-maskine-opsætninger), så åbn aldrig en daemon-TCP-port . Hvis du virkelig har brug for TCP-adgang, så sæt gensidig TLS (mTLS) foran, så kun klienter med et gyldigt certifikat kan forbinde. Kun SSH eller mTLS: der er ingen acceptabel tredje mulighed for en build-maskine, der kan nås fra internettet.

Så snart maskinen kører, er den en Linux-server til generelt brug, og der er masser andet værd at køre på den. Vores guide til self-hosted stack for indie hackers er en fornuftig næste læsning om, hvad der ellers gør sig fortjent til en plads på din VPS.

Hvis du hellere vil springe Docker Engine-installationen over og gå direkte til docker context createdeployer vores Docker-marketplace-app en VPS med Docker Engine, Compose V2 og buildx allerede konfigureret. Ét klik, og maskinen er SSH-klar, så gennemgangen ovenfor begynder ved trin 2 i stedet for trin 1.

Ofte stillede spørgsmål

Kan jeg køre Docker-builds på en fjernserver og bruge min lokale CLI?

Ja. Kør Docker Engine på fjernværten, opret en docker context der peger på den over SSH, og skift til den kontekst. Din lokale docker build kører så på fjernserveren, mens CLI'en på din maskine kun orkestrerer, uden at en lokal daemon er nødvendig.

Hvad er forskellen mellem docker context og DOCKER_HOST?

A docker context er et navngivet, omskifteligt, vedvarende mål, du definerer én gang og vælger med docker context use. DOCKER_HOST er en enkelt miljøvariabel, du sætter og fjerner manuelt for hver shell. Konteksten er den moderne erstatning for den gamle tilgang med tunnel plus miljøvariabel.

Virker docker compose med en fjern kontekst?

Ja. Compose V2 respekterer den aktive Docker-kontekst, så docker compose -kommandoer kører mod den vært, konteksten peger på. Tjenesterne og eventuelle image-builds kører på fjernværten, ligesom et almindeligt docker build.

Hvad er Docker Offload, og er det gratis?

Docker Offload er Dockers egen administrerede tjeneste til fjern build/kørsel til at flytte containerarbejde til Docker-administrerede cloud-værter, mens Docker Desktop-workflowet bevares. Den nuværende Docker-dokumentation opfører det som noget, der kræver Docker Desktop 4.68 eller nyere, plus Docker Business- og Docker Offload-abonnementer. Det er også session-baseret: hver bruger får én Offload-session ad gangen, inaktive sessioner afsluttes efter en frist på 5 minutter, og fjernmiljøet er flygtigt.

Hvordan forhindrer jeg Docker Desktop i at bruge så meget hukommelse?

At justere Docker Desktops ressourcegrænser krymper kun et aftryk, der aldrig går til nul, fordi VM'en altid har en bund. Vejen, der reelt fjerner hukommelsesomkostningen, er at fjerne den lokale daemon helt: kør Docker Engine på en VPS og forbind via docker context over SSH, så intet andet end CLI'en kører på din maskine.

Kan jeg gøre dette med Podman i stedet?

Det kan du. Podman er tilgængelig som en Docker-kompatibel engine, og docker context kan pege på en fjern Podman-vært, men det kræver, at Podman eksponerer sin Docker-kompatible socket over SSH. Kommandoflowet er det samme. Opsætningen på fjernsiden er forskellig.