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

Abre o Monitor de Atividade ou o Gestor de Tarefas, arranca um contentor pequeno, e o Docker Desktop ainda consegue tornar-se a coisa mais barulhenta na máquina. Num ticket do Docker Desktop de fevereiro de 2026, um utilizador relatou com.docker.backend.exe a subir para 100% de CPU depois de os contentores arrancarem, e a continuar mesmo depois de os parar.

Há outra jogada: tira o daemon do teu portátil por completo. Mantém só a CLI do Docker em local, executa o Docker Engine num VPS Linux e aponta o docker context para ele por SSH. O teu docker build não muda. A build é simplesmente executada noutro sítio, em Linux nativo sem camada de VM, com a largura de banda do VPS a puxar as imagens base em vez do Wi-Fi do teu café, e sem qualquer licença do Docker Desktop para acompanhar.

Esta é a configuração completa para esse caminho: pré-requisitos, os comandos exatos de docker context , builds multi-arquitetura com um driver buildx remoto, como dimensionar a máquina, e onde a abordagem remota é a escolha errada.

TL;DR

• O problema: o Docker Desktop carrega uma VM local, empurra a E/S de ficheiros através de uma camada de virtualização, e exige uma subscrição paga para uso profissional em organizações maiores, incluindo empresas para além dos limites do nível gratuito do Docker.
• A solução: remove o Docker Desktop. Executa o Docker Engine num VPS Linux, cria um docker context que aponte para ele por SSH, e a tua docker build local corre no VPS enquanto a tua CLI apenas orquestra.
• O enquadramento dos custos: um VPS modesto substitui uma licença por posto e dá-te a velocidade de build do Linux nativo. Uma equipa inteira pode partilhar uma única máquina de build em vez de pagar por programador.
• As ressalvas honestas: o VPS tem de estar acessível (nada de builds num avião), e precisas de disciplina com o .dockerignore para não estares a carregar um contexto de build de vários gigabytes em cada execução.

Pré-requisitos: o que vais precisar

Antes do primeiro comando, alinha estes pontos. Nada aqui é exótico se já usas o Docker no dia a dia.

• A Linux VPS com acesso root ou sudo. Ubuntu 22.04/24.04 ou Debian 12/13 funcionam todos bem.
• Docker Engine no VPS. docker context por SSH precisa do Docker Engine 18.09 ou mais recente no host remoto, de acordo com a documentação de contextos do Docker.
• Docker CLI 19.03 ou mais recente em local. É o cliente que compreende o comando de topo context comando.
• An Um par de chaves SSH. Apenas autenticação por chave: a autenticação por palavra-passe não é suportada para docker context as ligações SSH.
• O utilizador remoto no grupo docker grupo, para que possa falar com o socket do daemon sem sudo em cada chamada.

O que o Docker Desktop realmente te custa

Os custos não são um mistério. Concentram-se em três sítios, e quem chegou aqui à procura sentiu pelo menos um deles. Nomeá-los com precisão é o ponto. A dor já a conheces.

Memória e sobrecarga da VM. O Docker Desktop continua a significar uma VM Linux local. A documentação de definições do Docker diz que o Docker Desktop pode limitar quanta memória a VM do Docker Desktop usa, que é a parte silenciosa do problema: continua a haver uma VM ao barulho. A pegada exata varia conforme o sistema operativo e o projeto, mas os modos de falha são reais. Um ticket do Docker para Windows relata que o Docker Desktop consome muitos gigabytes de RAM sem qualquer contentor em execução, e um ticket do WSL2 descreve builds do Docker que deixam memória por libertar depois de os contentores terminarem. O ponto não é que cada máquina fique inativa no mesmo número. É que o Docker Desktop mantém a sobrecarga da VM local dentro do teu ciclo de desenvolvimento.

Velocidade de build e de E/S de ficheiros. Os bind mounts e as operações de ficheiros que atravessam a fronteira da VM são mais lentos do que o acesso nativo ao sistema de ficheiros do Linux. A documentação de problemas conhecidos do Docker reconhece o custo do sistema de ficheiros de virtualização. Os benchmarks da comunidade relatam habitualmente algo na ordem de 3-10x mais lento para os bind mounts através da camada de VM. Esse segundo número é experiência da comunidade, não um benchmark publicado pelo Docker, mas a direção não é contestada por ninguém que tenha visto uma build a arrastar-se num Mac.

Licenciamento. Desde a mudança de 2021, o Docker Desktop exige uma subscrição paga para empresas com mais de 250 funcionários ou acima de 10 M$ de receita. Os níveis atuais na página de preços do Docker são Personal ($0), Pro ($11/mo ou $9 por ano), Team ($16/mo ou $15 por ano) e Business ($24/mo). O nível Team passou de $9 para $15 por ano em dezembro de 2024, um salto que transforma uma rubrica silenciosa numa conversa com as compras, que é a parte que realmente arde quando a multiplicas por trinta postos.

As alternativas e a bifurcação local versus remoto

Quase todas as alternativas ao Docker Desktop que vais encontrar trocam um daemon local por outro daemon local. Esse é o verdadeiro eixo a notar: a escolha sobre a qual a maioria se atormenta é entre ferramentas locais, quando a bifurcação mais interessante é local versus remoto. Só o caminho remoto retira a VM da tua máquina.

Aqui está o panorama, lado a lado.

Algumas destas merecem uma frase de honestidade:

• OrbStack resolve mesmo o problema de recursos em Mac para um programador a solo. Afirma ~300 MB inativo e um arranque de contentores até 10x mais rápido (o site do OrbStack), ambos números do fornecedor, não benchmarks independentes. Se és um programador só de Mac que não quer gerir infraestrutura remota, o OrbStack é a melhor escolha, e o seu nível comercial de $8/mo (preços do OrbStack) fica abaixo do nível Team do Docker Desktop. O senão: é só para Mac, e a licença comercial traz de volta exatamente aquilo de que estavas a tentar fugir.
• Colima é grátis e centrado na CLI, mas as suas arestas de "não é um substituto direto" estão bem documentadas, e algumas equipas acabam por voltar ao Docker Desktop depois de uma migração emperrar.
• Podman Desktop e Rancher Desktop são ambos grátis e multiplataforma. Nenhum é um substituto silencioso, e a compatibilidade com o Compose do Podman passa pelo seu socket compatível com o Docker.
• Docker Offload é o serviço gerido de build/execução remota do próprio Docker, mas não é uma saída limpa do Docker Desktop. A documentação atual do Docker lista-o como algo que exige Docker Desktop 4.68 ou mais recente, uma subscrição Docker Business e uma subscrição Docker Offload. Executa as cargas em hosts na cloud geridos pelo Docker, mas cada utilizador obtém uma sessão de Offload de cada vez, as sessões inativas terminam após um período de tolerância de 5 minutos, e o ambiente é efémero, por isso contentores, imagens e volumes desaparecem quando a sessão termina. Isso é bom se queres capacidade remota gerida dentro do Docker Desktop. Não é o mesmo que um builder em VPS persistente com a tua própria cache, disco, acesso root e sem dependência do Desktop.

Ficar parado ainda é racional num caso: uma pessoa abaixo do limiar do nível gratuito e sem dor de velocidade de build não tem qualquer razão para mudar nada. Todos os outros têm uma bifurcação a fazer.

Conclusão-chave da secção: a decisão que importa não é qual a ferramenta local a escolher. É se mantens ou não um daemon no teu portátil.

Como funciona o docker context por SSH

Para compilar imagens Docker num servidor remoto por SSH, executa o Docker Engine nesse servidor, cria um docker context que aponte para ele com docker context create name --docker "host=ssh://user@host", depois executa docker context use name. Depois disso, a tua docker build normal é executada no host remoto, e a CLI local apenas envia instruções enquanto o daemon faz o trabalho.

Um contexto é um destino nomeado e comutável para a CLI do Docker. Em vez de andares a fazer malabarismos com variáveis de ambiente DOCKER_HOST ou a montar à mão um túnel SSH de cada vez, defines o remoto uma vez e mudas para ele como quem muda de diretório. A build é executada inteiramente no host remoto: os downloads das imagens base usam o uplink do VPS, as camadas ficam em cache no disco do VPS, e o trabalho de CPU acontece nos núcleos do VPS. Os únicos passos sensíveis à latência são o handshake SSH inicial e o carregamento do teu contexto de build. Tudo o resto é remoto.

Configurar a tua máquina de build em VPS

A configuração toda são quatro comandos curtos mais um bloco de configuração SSH. Vou mostrar a saída esperada onde te ajude a confirmar que cada passo resultou.

Passo 1: põe o Docker Engine num VPS Linux. Provisiona a máquina e instala o Docker Engine (18.09+ no remoto é o mínimo para o SSH de contextos; a tua CLI local precisa de 19.03+). Se preferes não fazer a instalação tu próprio, implementa um VPS que já o inclua (mais sobre isso abaixo). O utilizador remoto tem de estar no grupo docker:

sudo usermod -aG docker $USER

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

Passo 2: configura a autenticação por chave SSH e um alias de configuração. A autenticação por chave é obrigatória. Dá ao host um alias curto em ~/.ssh/config para não reescreveres o IP e o caminho da chave:

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

Passo 3: cria o contexto. Aponta-o ao daemon remoto por SSH. Usa a forma direta:

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

Ou, usando o alias de configuração SSH do passo 2:

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

Passo 4: verifica. Lista os teus contextos e confirma que o motor remoto responde:

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 isso imprimir a versão do servidor do daemon remoto, a tua CLI está a falar com o VPS.

Passo 5: muda e compila. Faz do VPS o destino ativo, depois compila normalmente:

docker context use my-vps

docker build -t myapp .

Essa build é executada no VPS. Preferes não mudar globalmente? Aponta a um único comando:

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

Ou define-o para a sessão de shell:

export DOCKER_CONTEXT=my-vps

Quando quiseres o daemon local do teu portátil de volta (se guardaste um), volta a casa:

docker context use default

Dica: cuida do teu .dockerignore. O contexto de build é carregado para o host remoto antes de a build começar. Um node_modules or .git perdido significa que envias gigabytes pela rede em cada execução, e o caminho remoto vai parecer mais lento do que o local sem qualquer bom motivo. Um .dockerignore bem afinado é a coisa que mais afeta se o caminho remoto parece rápido: exclui dependências, artefactos de build e metadados de controlo de versões, e o carregamento torna-se um erro de arredondamento.

Builds multi-arquitetura com um driver buildx remoto

Cria um builder buildx que executa o BuildKit dentro de um contentor no host Docker remoto, depois compila contra ele:

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 .

O --load importa para o consumo local de plataforma única: com o driver docker-container driver, as imagens compiladas não aparecem automaticamente na tua lista de imagens local. Se estás a compilar uma verdadeira imagem multiplataforma, envia-a para um registo em vez disso:

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

Essa distinção é importante. Uma build remota de plataforma única pode ser recarregada para o teu armazém de imagens local. Uma imagem multiplataforma é normalmente enviada para um registo, porque é uma manifest list com variantes separadas para cada arquitetura de destino. Esta secção é opcional: se todas as tuas imagens são de arquitetura única, a configuração de contexto acima é o trabalho todo.

Dimensionar e proteger a máquina de build

Duas perguntas decidem se esta máquina te serve bem: quão grande a fazer, e como manter o daemon bem trancado. As builds do Docker são limitadas pela CPU, por isso a lógica de dimensionamento é sobretudo sobre núcleos e RAM suficiente para evitar o swap. A lógica de segurança é sobretudo sobre não expor o daemon a ninguém a não ser a ti.

A que tamanho a definir

Dá-lhe especificações genéricas. Podes mapeá-las para o que quer que o teu fornecedor ofereça.

• Mínimo (um só programador, builds leves): 2 vCPU / 4 GB RAM / ~120 GB NVMe. This is the minimum that works, not what I'd reach for.
• O que eu de facto implementaria (a maioria das equipas): 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.
• Equipa ou CI pesada: 8 vCPU / 16-24 GB RAM for several developers sharing one box or big multi-stage Dockerfiles.

Como as builds são limitadas pela CPU, os núcleos de alta frequência (otimizados para CPU) compram-te uma iteração mais rápida mais do que a RAM extra para além do limiar do swap. Os planos com GPU são irrelevantes aqui, já que as builds de imagens não tocam na GPU. E a escolha do datacenter afeta só a capacidade de resposta do SSH e o tempo de carregamento do contexto, não a velocidade de build: a build é executada no VPS independentemente de onde estás sentado, por isso escolhe uma localização perto de ti para um handshake ágil e segue em frente.

Proteger o daemon remoto

A configuração acima já força o valor por omissão correto: autenticação por chave SSH, nenhuma porta do daemon exposta à rede. Mantém-na assim. No momento em que expões o BuildKit ou o daemon para além do SSH (um endpoint TCP em bruto, uma porta BuildKit aberta), tornas-te um alvo. O tópico do Hacker News sobre builds lentas que primeiro levantou a ideia do VPS remoto também alertava para ataques de criptomineração em endpoints BuildKit expostos. Um daemon de build não autenticado na Internet aberta é um buffet de computação grátis.

Dica: não exponhas o daemon. Se só o SSH te basta (basta à maioria das configurações de máquina única), nunca abras uma porta TCP do daemon . Se precisas mesmo de acesso TCP, põe um TLS mútuo (mTLS) à frente para que só os clientes com um certificado válido se possam ligar. Só SSH ou mTLS: não há uma terceira opção aceitável para uma máquina de build acessível a partir da Internet.

Assim que a máquina está de pé, é um servidor Linux de uso geral, e há muito mais que vale a pena executar nela. O nosso guia de stack self-hosted para indie hackers é uma boa leitura seguinte sobre o que mais ganha um lugar no teu VPS.

Se preferes saltar a instalação do Docker Engine e ir direto ao docker context create, a nossa app Docker do marketplace implementa um VPS com Docker Engine, Compose V2 e buildx já configurados. Um clique e a máquina está pronta para SSH, por isso o passo a passo acima começa no passo 2 em vez do passo 1.

Perguntas frequentes

Posso executar builds do Docker num servidor remoto e usar a minha CLI local?

Sim. Executa o Docker Engine no host remoto, cria um docker context a apontar para ele por SSH, e muda para esse contexto. A tua docker build local é então executada no servidor remoto enquanto a CLI na tua máquina apenas orquestra, sem qualquer daemon local necessário.

Qual é a diferença entre docker context e DOCKER_HOST?

A docker context é um destino nomeado, comutável e persistente que defines uma vez e selecionas com docker context use. DOCKER_HOST é uma única variável de ambiente que defines e retiras à mão em cada shell. O contexto é o substituto moderno da velha abordagem de túnel mais variável de ambiente.

O docker compose funciona com um contexto remoto?

Sim. O Compose V2 respeita o contexto Docker ativo, por isso os comandos docker compose são executados contra o host para o qual o contexto aponta. Os serviços e quaisquer builds de imagens são executados no host remoto, tal como um docker build.

O que é o Docker Offload e é grátis?

O Docker Offload é o serviço gerido de build/execução remota do próprio Docker para mover o trabalho de contentores para hosts na cloud geridos pelo Docker mantendo o fluxo do Docker Desktop. A documentação atual do Docker lista-o como algo que exige Docker Desktop 4.68 ou mais recente, mais subscrições Docker Business e Docker Offload. É também baseado em sessões: cada utilizador obtém uma sessão de Offload de cada vez, as sessões inativas terminam após um período de tolerância de 5 minutos, e o ambiente remoto é efémero.

Como impeço o Docker Desktop de usar tanta memória?

Afinar os limites de recursos do Docker Desktop só encolhe uma pegada que nunca chega a zero, porque a VM tem sempre um mínimo. O caminho que realmente remove o custo de memória é retirar o daemon local por completo: executa o Docker Engine num VPS e liga-te via docker context por SSH, para que na tua máquina não corra nada a não ser a CLI.

Posso fazer isto com o Podman em vez disso?

Podes. O Podman está disponível como motor compatível com o Docker, e docker context pode apontar para um host Podman remoto, mas isso exige que o Podman exponha o seu socket compatível com o Docker por SSH. O fluxo de comandos é o mesmo. A configuração no lado remoto difere.