This content originally appeared on DEV Community and was authored by Rafael Pazini
“Se eu já rodo
docker compose up
pra tudo, por que teria de aprender outro comando, ou pior, abrir um console na AWS, só pra treinar um modelo pesado?”
Foi exatamente aí que a galera da Docker acertou em cheio com o Docker Offload: um clique, e o que estava consumindo sua CPU (ou derretendo sua GPU) passa a rodar num runner de nuvem, mas sem mudar seu fluxo local. Vamos aos detalhes.
O que é o Docker Offload?
Em poucas palavras, é um serviço que “teleporta” builds e containers para máquinas na nuvem, com GPU NVIDIA L4, mantendo a experiência local. Ele nasceu para o novo mundo dos agentes de IA (Compose 2.0) e tarefas que exigem muito hardware, como LLMs e pipelines de vídeo.
Recurso | Por que isso importa? |
---|---|
GPU on-demand | Treine ou execute LLMs sem ter placa dedicada |
Integração nativa com Docker Desktop/Engine | Mesmos comandos (docker run , docker compose up ) |
Sessões efêmeras | Nada de “limpar servidor” depois |
300 min grátis + \$0,015/GPU min (beta) | Dá pra testar sem abrir a carteira |
Debaixo do capô
O Offload reutiliza a infraestrutura que move o Docker Build Cloud, mas vai além: ele não serve só para build, e sim para execução contínua de containers com GPU. A experiência híbrida (local nuvem) usa port‑forwarding e bind‑mounts para você nem perceber que algo saiu da sua máquina.
Como habilitar em 3 passos
Bora mostrar esse carinha rodando a todo vapor.
Primeira coisa é garantir que vc tem a versão do Docker Desktop 4.43+
e a conta Pro
docker offload start # para ativar sua sessão
docker offload status # para consultar se sua sessão está ativa
E agora podemos rodar um container para ver mais informações da GPU que estamos utilizando
docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu
Boa Rafa, e se eu quiser rodar um MySQL neste mesmo contexto? Tenho que fazer algo?
Isso é o legal dessa feature, você só precisa rodar como já estamos acostumados.
Eu fiz um exemplo de teste, onde criei um Docker Compose com 3 containers:um banco de dados, uma api em Node e um NGINX como servidor http, para exibir uma pagina html simples.
services:
db:
image: postgres:16-alpine
networks:
- my-app-net
environment:
- POSTGRES_USER=user
- POSTGRES_PASSWORD=password
- POSTGRES_DB=testdb
healthcheck:
test: ["CMD-SHELL", "pg_isready -U user -d testdb"]
interval: 5s
timeout: 5s
retries: 5
api:
image: node:22-alpine
networks:
- my-app-net
command: >
sh -c "npm install -g json-server && json-server --host 0.0.0.0 --watch db.json"
working_dir: /app
volumes:
- ./api-data:/app
depends_on:
db:
condition: service_healthy
frontend:
image: nginx:alpine
networks:
- my-app-net
ports:
- "8080:80"
- "8081:80"
volumes:
- ./nginx-content:/usr/share/nginx/html
depends_on:
- api
networks:
my-app-net:
driver: bridge
Para rodar, eu só tenho que garantir que estou no Docker Offload context e rodar o meu Docker compose:
docker compose up --build -d
[+] Running 3/3
✔ Container offload-db-1 Healthy 5.8s
✔ Container offload-api-1 Started 0.6s
✔ Container offload-frontend-1 Started
E agora eu só acesso a linha localhost:8080
, como se eu estivesse rodando localmente minha aplicação. Simples assim!
Contextos: Local vs Offload
Quando você ativa o Offload, o Docker cria automaticamente um contexto remoto chamado offload
. Contextos são perfis que apontam o CLI para diferentes daemons; assim, você muda de “máquina” sem trocar de terminal.
docker context ls
NAME DESCRIPTION DOCKER ENDPOINT ERROR
default Current DOCKER_HOST based configuration unix:///var/run/docker.sock
desktop-linux Docker Desktop unix:///Users/rflpazini/.docker/run/docker.sock
docker-cloud * docker cloud context created by version v0.4.2 unix:///Users/rflpazini/.docker/cloud/docker-cloud.sock
- O
*
indica o contexto ativo. - Use
docker context use offload
para mandar todos os comandos para o runner na nuvem. - Volte para o notebook com
docker context use default
.
No Docker Desktop, o botão de toggle Local Offload (
) troca automaticamente o contexto; o ícone do notebook muda para uma nuvem, e o header do app fica roxo quando você está em Offload.
Docker Local:
“Está em BETA, mesmo assim funciona?” – meus testes de estresse
Pensando nisso e durante a ajuda nos testes da ferramenta, estou usando ela fazem 2 dias desde que disponibilizaram para os Docker Captains, eu fiz os seguintes testes:
-
Falha de rede simulada. Interrompi o download durante um
docker build
gigante viawget
; a sessão se recuperou sem corromper camadas. - Resource exhaustion. Disparei OOM matando um container propositalmente e ainda lancei um fork‑bomb; o runner isolou o caos e o Compose continuou intacto.
- Compose complexo. Subi front‑end, API, DB e Redis, com health‑checks e volumes bind; tudo funcionou.
- Workloads de IA. Rodei o gemma‑3‑7B via Model Runner com GPU e desempenho semelhante a instâncias GKE equivalentes.
Todos os testes funcionaram 100%, sem problemas. Então eu diria que vale a pena usar.
Um ponto te atenção que devemos ter é que neste momento ele está disponível apenas na US East region
, então isso pode afetar um pouco a latencia de seu uso.
Custos
Como tudo na vida, existe os custos. E atualmente são estes:
Faixa | Valor | Observações |
---|---|---|
Primeiros 300 min por mês | Gratuito | Renovação automática |
Minuto com GPU | US$ 0,015 | Cobrados apenas se sessão ativa |
Minuto só CPU | US$ 0,01 | Útil para pipelines CI pesados |
Tráfego de saída | Sem custo (primeiros 100 GB) / US$ 0,02 por GB (após) | Cobrança feita por minuto arredondado para cima; desligue a sessão para parar o relógio. |
Quando (não) usar
Use se… | Talvez não seja a melhor se… |
---|---|
Precisa de GPU esporádica para IA ou vídeo | O time já tem cluster Kubernetes com GPUs livres |
Seu laptop é um Mac M3 sem CUDA ![]() |
Latência é crítica; os runners estão só em us‑east‑1 hoje |
Builds grandes travam seu CI | Você não tem conta Pro ou quer custo fixo mensal |
Dicas de produtividade
-
Cache inteligente. Combine
docker buildx build --cache-to=type=registry
com Offload para acelerar builds subsequentes. -
Alias rápido.
alias dco='docker compose --offload'
e pronto. -
Logs locais. Use
docker logs -f
normalmente, o Desktop faz stream para você. -
Reutilize no CI. O token em
~/.docker/offload/config.json
pode ser exportado na pipeline, manuseie com cuidado.
Conclusão
O Docker Offload acerta em cheio quem quer ficar no mesmo CLI, mas precisa explodir limites de hardware de vez em quando. Não substitui clusters 24/7, mas entrega a elasticidade que faltava no loop de desenvolvimento e, como bônus, sem aquele barulho de turbina do notebook.
Próximos passos. Cadastre‑se na beta, ganhe seus 300 minutos e me conta no LinkedIn como foi sua experiência. Se o seu fan‑cooler agradecer, já valeu o teste.
This content originally appeared on DEV Community and was authored by Rafael Pazini