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

Apri Monitoraggio Attività o Gestione attività, avvia un piccolo container, e Docker Desktop può ancora diventare la cosa più rumorosa sulla macchina. In un ticket di Docker Desktop di febbraio 2026, un utente ha segnalato com.docker.backend.exe che saliva al 100% di CPU dopo l'avvio dei container, e continuava anche dopo averli fermati.

C'è un'altra mossa: togli del tutto il demone dal tuo portatile. Tieni solo la CLI di Docker in locale, esegui Docker Engine su un VPS Linux e punta docker context a esso via SSH. Il tuo docker build non cambia. La build viene semplicemente eseguita altrove, su Linux nativo senza strato di VM, con la banda del VPS che scarica le immagini di base invece del Wi-Fi del tuo bar, e senza alcuna licenza di Docker Desktop da tracciare.

Questa è la configurazione completa per quel percorso: prerequisiti, i comandi esatti di docker context , build multi-arch con un driver buildx remoto, come dimensionare la macchina, e dove l'approccio remoto è la scelta sbagliata.

TL;DR

• Il problema: Docker Desktop si porta dietro una VM locale, spinge l'I/O dei file attraverso uno strato di virtualizzazione, e richiede un abbonamento a pagamento per l'uso professionale nelle organizzazioni più grandi, incluse le aziende oltre i limiti del piano gratuito di Docker.
• La soluzione: rimuovi Docker Desktop. Esegui Docker Engine su un VPS Linux, crea un docker context che punti a esso via SSH, e la tua docker build locale viene eseguita sul VPS mentre la tua CLI si limita a orchestrare.
• L'inquadramento dei costi: un VPS modesto sostituisce una licenza per postazione e ti dà la velocità di build di Linux nativo. Un intero team può condividere una singola macchina di build invece di pagare per sviluppatore.
• Gli avvertimenti onesti: il VPS deve essere raggiungibile (niente build in aereo), e ti serve disciplina con .dockerignore per non caricare un contesto di build di diversi gigabyte a ogni esecuzione.

Prerequisiti: cosa ti serve

Prima del primo comando, prepara questi elementi. Nulla qui è esotico se già usi Docker ogni giorno.

• A Linux VPS con accesso root o sudo. Ubuntu 22.04/24.04 o Debian 12/13 vanno tutti bene.
• Docker Engine sul VPS. docker context via SSH richiede Docker Engine 18.09 o più recente sull'host remoto, secondo la documentazione dei context di Docker.
• Docker CLI 19.03 o più recente in locale. È il client che comprende il comando di primo livello context comando.
• An Una coppia di chiavi SSH. Solo autenticazione a chiave: l'autenticazione a password non è supportata per docker context le connessioni SSH.
• L' utente remoto nel gruppo docker gruppo, così che possa parlare con il socket del demone senza sudo a ogni chiamata.

Cosa ti costa davvero Docker Desktop

I costi non sono un mistero. Si concentrano in tre punti, e chi è arrivato fin qui cercando ne ha sentito almeno uno. Nominarli con precisione è il punto. Il dolore lo conosci già.

Memoria e sovraccarico della VM. Docker Desktop significa ancora una VM Linux locale. La documentazione delle impostazioni di Docker dice che Docker Desktop può limitare quanta memoria usa la VM di Docker Desktop, che è la parte silenziosa del problema: c'è ancora una VM di mezzo. L'impronta esatta varia in base al sistema operativo e al progetto, ma i modi di fallimento sono reali. Un ticket di Docker per Windows segnala che Docker Desktop consuma molti gigabyte di RAM senza alcun container in esecuzione, e un ticket di WSL2 descrive build di Docker che lasciano memoria non liberata dopo la terminazione dei container. Il punto non è che ogni macchina resti inattiva sullo stesso numero. È che Docker Desktop mantiene il sovraccarico della VM locale dentro il tuo ciclo di sviluppo.

Velocità di build e di I/O dei file. I bind mount e le operazioni sui file che attraversano il confine della VM sono più lenti dell'accesso nativo al filesystem di Linux. La documentazione dei problemi noti di Docker riconosce il costo del filesystem di virtualizzazione. I benchmark della community riportano abitualmente qualcosa nell'ordine di 3-10x più lento per i bind mount attraverso lo strato di VM. Quel secondo numero è esperienza della community, non un benchmark pubblicato da Docker, ma la direzione non è messa in discussione da nessuno che abbia visto una build arrancare su un Mac.

Licenze. Dal cambiamento del 2021, Docker Desktop richiede un abbonamento a pagamento per le aziende con più di 250 dipendenti o oltre 10 M$ di fatturato. I livelli attuali sulla pagina dei prezzi di Docker sono Personal ($0), Pro ($11/mo o $9 all'anno), Team ($16/mo o $15 all'anno) e Business ($24/mo). Il livello Team è passato da $9 a $15 all'anno a dicembre 2024, un salto che trasforma una voce silenziosa in una conversazione con l'ufficio acquisti, che è la parte che brucia davvero quando la moltiplichi per trenta postazioni.

Le alternative e il bivio locale-remoto

Quasi ogni alternativa a Docker Desktop che troverai scambia un demone locale con un altro demone locale. Questo è il vero asse da notare: la scelta su cui la maggior parte si arrovella è tra strumenti locali, quando il bivio più interessante è locale contro remoto. Solo il percorso remoto toglie la VM dalla tua macchina.

Ecco il panorama, affiancato.

Alcune di queste meritano una frase di onestà:

• OrbStack risolve davvero il problema delle risorse su Mac per uno sviluppatore in solitaria. Dichiara ~300 MB a riposo e un avvio dei container fino a 10x più veloce (il sito di OrbStack), entrambi numeri del fornitore, non benchmark indipendenti. Se sei uno sviluppatore solo su Mac che non vuole gestire infrastruttura remota, OrbStack è la scelta migliore, e il suo livello commerciale a $8/mo (prezzi di OrbStack) sta sotto il livello Team di Docker Desktop. Il rovescio: è solo per Mac, e la licenza commerciale riporta proprio la cosa da cui cercavi di scappare.
• Colima è gratis e incentrato sulla CLI, ma le sue asperità da "non è un sostituto immediato" sono ben documentate, e alcuni team finiscono per tornare a Docker Desktop dopo che una migrazione si arena.
• Podman Desktop e i piani Rancher Desktop sono entrambi gratuiti e multipiattaforma. Nessuno dei due è un sostituto silenzioso, e la compatibilità con Compose di Podman passa per il suo socket compatibile con Docker.
• Docker Offload è il servizio gestito di build/esecuzione remota di Docker stesso, ma non è un'uscita pulita da Docker Desktop. La documentazione attuale di Docker lo elenca come qualcosa che richiede Docker Desktop 4.68 o più recente, un abbonamento a Docker Business e un abbonamento a Docker Offload. Esegue i carichi su host cloud gestiti da Docker, ma ogni utente ottiene una sessione di Offload alla volta, le sessioni inattive terminano dopo un periodo di grazia di 5 minuti, e l'ambiente è effimero, quindi container, immagini e volumi spariscono quando la sessione finisce. Va bene se vuoi capacità remota gestita dentro Docker Desktop. Non è la stessa cosa di un builder su VPS persistente con la tua cache, il tuo disco, l'accesso root e nessuna dipendenza da Desktop.

Restare fermi è ancora razionale in un caso: una persona sotto la soglia del piano gratuito e senza problemi di velocità di build non ha alcun motivo di cambiare nulla. Tutti gli altri hanno un bivio da affrontare.

Punto chiave della sezione: la decisione che conta non è quale strumento locale scegliere. È se tenere o no un demone sul tuo portatile.

Come funziona docker context via SSH

Per compilare immagini Docker su un server remoto via SSH, esegui Docker Engine su quel server, crea un docker context che punti a esso con docker context create name --docker "host=ssh://user@host", poi esegui docker context use name. Dopodiché la tua docker build normale viene eseguita sull'host remoto, e la CLI locale si limita a inviare istruzioni mentre il demone fa il lavoro.

Un context è una destinazione con nome e commutabile per la CLI di Docker. Invece di destreggiarti con variabili d'ambiente DOCKER_HOST o di allestire a mano un tunnel SSH ogni volta, definisci il remoto una volta e ci passi come cambiando directory. La build viene eseguita interamente sull'host remoto: i download delle immagini di base usano l'uplink del VPS, i layer vengono messi in cache sul disco del VPS, e il lavoro di CPU avviene sui core del VPS. Gli unici passi sensibili alla latenza sono l'handshake SSH iniziale e il caricamento del tuo contesto di build. Tutto il resto è remoto.

Configurare la tua macchina di build su VPS

L'intera configurazione sono quattro comandi brevi più un blocco di configurazione SSH. Mostrerò l'output atteso dove ti aiuta a confermare che ogni passo è andato a buon fine.

Passo 1: porta Docker Engine su un VPS Linux. Prepara la macchina e installa Docker Engine (18.09+ sul remoto è il minimo per l'SSH dei context; la tua CLI locale ha bisogno di 19.03+). Se preferisci non fare l'installazione da solo, distribuisci un VPS che lo includa già (più avanti su questo). L'utente remoto deve essere nel gruppo docker:

sudo usermod -aG docker $USER

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

Passo 2: imposta l'autenticazione a chiave SSH e un alias di configurazione. L'autenticazione a chiave è obbligatoria. Dai all'host un alias breve in ~/.ssh/config così da non riscrivere l'IP e il percorso della chiave:

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

Passo 3: crea il context. Puntalo al demone remoto via SSH. Usa la forma estesa:

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

Oppure, usando l'alias di configurazione SSH del passo 2:

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

Passo 4: verifica. Elenca i tuoi context e controlla che il motore remoto risponda:

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

Se questo stampa la versione del server del demone remoto, la tua CLI sta parlando con il VPS.

Passo 5: passa e compila. Rendi il VPS la destinazione attiva, poi compila normalmente:

docker context use my-vps

docker build -t myapp .

Quella build viene eseguita sul VPS. Preferisci non passare globalmente? Mira a un singolo comando:

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

Oppure impostalo per la sessione di shell:

export DOCKER_CONTEXT=my-vps

Quando vuoi riavere il demone locale del tuo portatile (se ne hai tenuto uno), torna a casa:

docker context use default

Consiglio: cura il tuo .dockerignore. Il contesto di build viene caricato sull'host remoto prima che la build inizi. Una node_modules or .git vagante significa che spedisci gigabyte via rete a ogni esecuzione, e il percorso remoto sembrerà più lento del locale senza alcun buon motivo. Un .dockerignore ben curato è la cosa che più influisce sul fatto che il percorso remoto sembri veloce: escludi dipendenze, artefatti di build e metadati del controllo di versione, e il caricamento diventa un errore di arrotondamento.

Build multi-arch con un driver buildx remoto

Crea un builder buildx che esegue BuildKit dentro un container sull'host Docker remoto, poi compila contro di esso:

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 .

L' --load conta per il consumo locale a piattaforma singola: con il driver docker-container driver, le immagini compilate non compaiono automaticamente nel tuo elenco di immagini locale. Se stai compilando una vera immagine multipiattaforma, spingila invece a un registry:

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

Quella distinzione è importante. Una build remota a piattaforma singola può essere ricaricata nel tuo archivio di immagini locale. Un'immagine multipiattaforma di solito viene spinta a un registry, perché è una manifest list con varianti separate per ogni architettura di destinazione. Questa sezione è opzionale: se tutte le tue immagini sono a singola architettura, la configurazione dei context sopra è tutto il lavoro.

Dimensionare e mettere in sicurezza la macchina di build

Due domande decidono se questa macchina ti serve bene: quanto grande farla e come tenere il demone ben protetto. Le build di Docker sono limitate dalla CPU, quindi la logica di dimensionamento riguarda soprattutto i core e abbastanza RAM da evitare lo swap. La logica di sicurezza riguarda soprattutto il non esporre il demone a nessuno tranne te.

A quale dimensione impostarla

Dalle specifiche generiche. Puoi mapparle su qualunque cosa offra il tuo provider.

• Minimo (singolo sviluppatore, build leggere): 2 vCPU / 4 GB RAM / ~120 GB NVMe. This is the minimum that works, not what I'd reach for.
• Ciò che distribuirei davvero (la maggior parte dei team): 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 o CI pesante: 8 vCPU / 16-24 GB RAM for several developers sharing one box or big multi-stage Dockerfiles.

Poiché le build sono limitate dalla CPU, i core ad alta frequenza (ottimizzati per la CPU) ti danno un'iterazione più veloce più di quanto faccia la RAM aggiuntiva oltre la soglia dello swap. I piani con GPU sono irrilevanti qui, dato che le build delle immagini non toccano la GPU. E la scelta del data center incide solo sulla reattività dell'SSH e sul tempo di caricamento del contesto, non sulla velocità di build: la build viene eseguita sul VPS ovunque tu ti trovi, quindi scegli una posizione vicina a te per un handshake scattante e vai avanti.

Mettere in sicurezza il demone remoto

La configurazione sopra impone già il default corretto: autenticazione a chiave SSH, nessuna porta del demone esposta alla rete. Tienila così. Nel momento in cui esponi BuildKit o il demone oltre l'SSH (un endpoint TCP grezzo, una porta BuildKit aperta), diventi un bersaglio. Il thread su Hacker News sulle build lente che ha sollevato per primo l'idea del VPS remoto avvertiva anche di attacchi di cryptomining su endpoint BuildKit esposti. Un demone di build non autenticato sull'Internet aperta è un buffet di calcolo gratis.

Consiglio: non esporre il demone. Se ti basta il solo SSH (basta alla maggior parte delle configurazioni a macchina singola), non aprire mai una porta TCP del demone . Se hai davvero bisogno dell'accesso TCP, metti davanti un TLS reciproco (mTLS) così che solo i client con un certificato valido possano connettersi. Solo SSH o mTLS: non c'è una terza opzione accettabile per una macchina di build raggiungibile da Internet.

Una volta che la macchina è attiva, è un server Linux generico, e c'è molto altro che vale la pena eseguirci. La nostra guida allo stack self-hosted per indie hacker è una buona lettura successiva su cos'altro si guadagna un posto sul tuo VPS.

Se preferisci saltare l'installazione di Docker Engine e andare dritto a docker context create, la nostra app Docker del marketplace distribuisce un VPS con Docker Engine, Compose V2 e buildx già configurati. Un clic e la macchina è pronta per SSH, così la guida sopra inizia dal passo 2 invece che dal passo 1.

Domande frequenti

Posso eseguire build di Docker su un server remoto e usare la mia CLI locale?

Sì. Esegui Docker Engine sull'host remoto, crea un docker context che punti a esso via SSH, e passa a quel context. La tua docker build locale viene poi eseguita sul server remoto mentre la CLI sulla tua macchina si limita a orchestrare, senza alcun demone locale necessario.

Qual è la differenza tra docker context e DOCKER_HOST?

A docker context è una destinazione con nome, commutabile e persistente che definisci una volta e selezioni con docker context use. DOCKER_HOST è una singola variabile d'ambiente che imposti e rimuovi a mano per ogni shell. Il context è il sostituto moderno del vecchio approccio a tunnel più variabile d'ambiente.

docker compose funziona con un context remoto?

Sì. Compose V2 rispetta il context Docker attivo, quindi i comandi docker compose vengono eseguiti contro l'host a cui punta il context. I servizi e qualsiasi build di immagini vengono eseguiti sull'host remoto, come una semplice docker build.

Cos'è Docker Offload ed è gratis?

Docker Offload è il servizio gestito di build/esecuzione remota di Docker stesso per spostare il lavoro sui container su host cloud gestiti da Docker mantenendo il flusso di Docker Desktop. La documentazione attuale di Docker lo elenca come qualcosa che richiede Docker Desktop 4.68 o più recente, oltre a abbonamenti a Docker Business e Docker Offload. È anche basato su sessioni: ogni utente ottiene una sessione di Offload alla volta, le sessioni inattive terminano dopo un periodo di grazia di 5 minuti, e l'ambiente remoto è effimero.

Come impedisco a Docker Desktop di usare così tanta memoria?

Regolare i limiti di risorse di Docker Desktop riduce solo un'impronta che non arriva mai a zero, perché la VM ha sempre un minimo. Il percorso che rimuove davvero il costo di memoria è togliere del tutto il demone locale: esegui Docker Engine su un VPS e connettiti tramite docker context via SSH, così che sulla tua macchina non giri altro che la CLI.

Posso fare questo con Podman invece?

Puoi. Podman è disponibile come motore compatibile con Docker, e docker context può puntare a un host Podman remoto, ma questo richiede che Podman esponga il suo socket compatibile con Docker via SSH. Il flusso dei comandi è lo stesso. La configurazione sul lato remoto differisce.