Dois anos de Docker: o que mudou de 2024 para cá

Entre setembro de 2024 e setembro de 2026 o Docker Engine saiu da série 27 e chegou na 29.8.1. No caminho teve um release que derrubou acesso a container em produção, uma troca do armazenamento de imagem por padrão, a remoção de um subsistema inteiro de assinatura e a depreciação do cgroup v1.

Fora do Engine, o período teve um anúncio de cobrança no Docker Hub que foi revertido publicamente, um catálogo de imagens endurecidas que começou pago e virou open source, e uma linha de produto inteira voltada a agentes de IA.

Este artigo é o levantamento do que mudou, com a fonte oficial de cada ponto. Não é guia de migração, é mapa: o que aconteceu, quando, e o que morde na prática.

O que sobrou de 2024: a série 27

O fim da linha 27 foi de ajuste fino, quase todo em rede. As notas completas estão nas release notes do Engine 27.

• 27.2.1 (09/09/2024): atualização do runc para a v1.1.14, corrigindo a CVE-2024-45310. Corrigiu também o docker login gravando credencial sob a chave errada.
• 27.3.0 (19/09/2024): chega a flag --feature no daemon, que passa a ser o mecanismo padrão de ligar e desligar comportamento novo sem esperar release major.
• 27.4.0 (09/12/2024): portas publicadas passam a ser acessíveis entre bridge networks diferentes quando o br_netfilter está carregado e o userland-proxy está desligado. Detecção de endereço duplicado (DAD) de IPv6 foi desabilitada no bridge.
• 27.4.1 (18/12/2024): limpeza da chain DOCKER FILTER e correção de carregamento de módulo de kernel em Docker in Docker.
• 27.5.1 (22/01/2025): aparece o DOCKER_IGNORE_BR_NETFILTER_ERROR, sintoma de que o terreno de rede já estava sendo preparado para o que viria em seguida.

Engine 28.0.0, o release que quebrou rede

Publicado em 19/02/2025, é o release mais importante da janela e o que mais gerou chamado de suporte.

Até o 27.x, em Linux com iptables, qualquer host com rota até a máquina do Docker conseguia falar direto com o IP interno de um container, mesmo em porta que nunca foi publicada. Bastava saber o endereço na rede bridge, tipicamente algo em 172.17.0.0/16. Na prática, subir um banco com docker run sem -p não deixava ele isolado da rede local, deixava ele apenas sem NAT.

O 28.0.0 fecha isso. Tráfego inbound não solicitado para o IP do container passa a ser descartado na chain DOCKER, salvo se a porta foi publicada com -p ou --publish. O anúncio oficial está em Hardening Container Networking by Default.

Três detalhes que pegam gente de surpresa:

• Vale só para Linux com iptables. Docker Desktop não é afetado.
• Passa a exigir os módulos de kernel de ipset (ip_set, ip_set_hash_net e netfilter_xt_set). Em host enxuto ou kernel customizado, o daemon reclama na subida.
• O binário docker-proxy mudou e não é compatível com dockerd antigo, então atualizar os pacotes pela metade não funciona. O rootlesskit-docker-proxy foi removido.

As saídas de emergência

Se alguma coisa no ambiente dependia do comportamento antigo, existem escapes documentados. Em ordem, do mais cirúrgico para o mais amplo:

{
  "allow-direct-routing": true
}

A recomendação prática é não começar pelo allow-direct-routing, porque ele desfaz o ganho de segurança do release inteiro. Se só um host de monitoração precisa alcançar o container, trusted_host_interfaces resolve com escopo bem menor.

O 28.0 também trouxe o modo isolated para redes internal, o gw-priority, a definição de nome de interface do container via com.docker.network.endpoint.ifname, a flag --ipv4 no docker network create e IPv6 sem precisar de fixed-cidr-v6.

O que o 28.0 removeu

• O driver de log logentries.
• Plugins externos de graph-driver.
• A flag --api-cors-header.
• A flag --time em docker stop e docker restart, que virou --timeout.
• Suporte a imagens no schema 1 legado. A variável DOCKER_ENABLE_DEPRECATED_PULL_SCHEMA_1_IMAGE deixou de funcionar.

A série 28 depois do 28.0

As release notes do Engine 28 trazem o resto da linha:

• 28.1.0 (17/04/2025): docker bake vira comando de topo, como alias de docker buildx bake. Entra o --use-api-socket em modo experimental.
• 28.2.0 (28/05/2025): mudança de default silenciosa e relevante, o CDI (Container Device Interface) passa a vir habilitado. Bind mount com caminho relativo passa a funcionar.
• 28.3.0 (24/06/2025): suporte a GPU AMD e uso do DOCKER_AUTH_CONFIG como credential store.
• 28.3.3 (29/07/2025): corrige a CVE-2025-54388, em que um reload do firewalld reabria portas publicadas. É o contraponto irônico do 28.0: o release que fechou a rede tinha um caminho para reabrir sozinho.
• 28.4.0 (03/09/2025): GODEBUG configurável via docker context.
• 28.5.0 (02/10/2025): anúncio da depreciação do Raspberry Pi OS 32 bits após a série 28.

Engine 29.0.0, a troca de defaults

Publicado em 10/11/2025, o 29.0.0 é menos barulhento que o 28.0 mas mexe em mais coisa de uma vez. As release notes do Engine 29 listam tudo.

• O containerd image store passa a ser o padrão em instalação nova.
• docker image ls ganha uma visão nova, em árvore colapsada, e deixa de mostrar imagem sem tag a menos que você passe --all.
• O backend experimental de firewall em nftables fica disponível via firewall-backend: nftables. Vale reforçar, porque circula informação errada sobre isso: nftables não chegou no 28.x, toda a série 28 é iptables.

• cgroup v1 depreciado. O suporte segue até maio de 2029, então não é urgência, mas é o aviso formal.
• Docker Content Trust removido do CLI. A Docker publicou depois um guia de aposentadoria e migração em 16/06/2026.
• O daemon passa a exigir API v1.44 ou superior, ou seja, cliente de Docker v25.0 para cima.
• As chains DOCKER-ISOLATION-STAGE-1 e DOCKER-ISOLATION-STAGE-2 do iptables foram removidas. Se você tem automação que escreve regra apoiada nesses nomes, ela quebra em silêncio.
• O módulo Go github.com/docker/docker foi depreciado em favor de github.com/moby/moby/client e github.com/moby/moby/api.
• Pacotes Debian armhf passam a mirar ARMv7 e os pacotes de Raspbian 32 bits foram descontinuados.

Traduzindo: o containerd image store como padrão

Historicamente o Docker guardava imagem num store próprio, baseado em graph drivers como o overlay2. O containerd image store substitui essa camada pelo mesmo mecanismo que o containerd já usa, e ser padrão a partir do 29.0 muda três coisas no dia a dia.

A migração não é automática em host que já existia. Instalação nova nasce com o store novo, host antigo continua no store anterior até a troca ser feita de forma explícita, o que é bom, porque a troca não preserva as imagens já baixadas.

Traduzindo: cgroup v1 depreciado e o rootless novo

Duas mudanças que valem checagem antes de subir para o 29.

stat -fc %T /sys/fs/cgroup/
# cgroup2fs  = v2, tudo certo
# tmpfs      = v1, entra na fila de migração

A série 29 ao longo de 2026

• 29.2.0 (26/01/2026): suporte experimental a NRI (Node Resource Interface) e campo Identity no inspect.
• 29.3.0 (05/03/2026): a versão mínima de API volta de v1.44 para v1.40, recuando parcialmente a quebra do 29.0. Entra o bind-create-src no --mount.
• 29.3.1 (25/03/2026): corrige a CVE-2026-34040, bypass de autorização em plugin AuthZ, mais três CVEs de BuildKit.
• 29.4.2 (01/05/2026): o perfil seccomp padrão passa a bloquear sockets AF_ALG e a syscall socketcall(2). O efeito colateral foi conhecido e documentado: quebra programa 32 bits e imagem i386, com workaround via perfil seccomp v0.2.1.
• 29.5.0 (14/05/2026): driver rootless novo e time namespace privado, já citados.
• 29.5.1 (18/05/2026): trio de correções no docker cp, incluindo duas TOCTOU que permitiam criar arquivo arbitrário e redirecionar bind mount para caminho arbitrário do host.
• 29.6.0 (18/06/2026): endpoint de attestations e correção do COPY --chmod sendo filtrado pelo umask do daemon.
• 29.7.0 (30/07/2026): mount type=image deixa de ser experimental, entra o embedded-containerd experimental rodando containerd dentro do processo do daemon, e o default-stop-timeout.
• 29.8.0 (03/09/2026): flag --umask no docker run e create, templates de perfil AppArmor configuráveis no daemon.
• 29.8.1 (15/09/2026): versão corrente na data deste artigo.

Docker Hub: o anúncio que foi revertido

Essa é a parte do período com mais informação errada circulando, então vale reconstituir a linha do tempo com calma.

No fim de 2024 a Docker anunciou uma revisão de planos que incluía cobrança por consumo, tanto de pull quanto de storage, com limites de pull por hora previstos para 1 de março de 2025. O anúncio está em Announcing Upgraded Docker Plans, e os planos novos entraram à venda em 10/12/2024.

Em 21/02/2025, poucos dias antes da data prevista, a empresa voltou atrás em Revisiting Docker Hub Policies:

• a cobrança por consumo de pull foi cancelada de vez;
• a cobrança por storage foi adiada por tempo indeterminado;
• o aumento de rate limit previsto não foi aplicado;
• a Docker se comprometeu a anunciar qualquer mudança futura com seis meses de antecedência.

Ou seja, os números de "10 pulls por hora para anônimo" e "40 por hora para conta Personal" que ainda aparecem em post de blog e em thread de fórum são de um plano que nunca entrou em vigor. Citar eles hoje é citar documento revogado.

Os limites que valem de fato, segundo a documentação oficial de uso do Docker Hub, são contados numa janela de seis horas, não por hora:

O detalhe do IPv4 compartilhado é o que costuma doer. Um cluster inteiro atrás de um NAT, ou um runner de CI numa faixa compartilhada, consome a cota como se fosse um único usuário. É exatamente o cenário que motiva colocar um cache de registry na frente do Hub, assunto que já tratei em ACR Artifact Cache.

Planos: o reajuste do fim de 2024

O que de fato mudou de preço na janela foi a tabela de planos, em 10/12/2024:

A contrapartida foi deixar de vender Docker Build Cloud e Testcontainers Cloud como licença por assento separada, passando a incluí-los nos planos pagos, com Docker Scout ilimitado em Team e Business.

Imagens endurecidas: DHI, o fim da Minimus e o ELS

Em 19/05/2025 a Docker lançou as Docker Hardened Images, um catálogo curado de imagens mínimas, sem shell e sem package manager, rodando como usuário não root, com base Alpine ou Debian. O argumento de venda era redução de superfície de ataque na casa de 95%. O modelo, no lançamento, era pago.

Em 17/12/2025 o modelo virou: mais de mil imagens passaram a ser gratuitas e open source sob Apache 2.0, com SBOM completo, dado de CVE transparente e proveniência SLSA Build Level 3. O pago ficou restrito ao DHI Enterprise, com SLA de remediação de CVE crítico em menos de sete dias, imagens FIPS e STIG e customização.

Em 2026 o catálogo seguiu crescendo: Hardened System Packages em 03/03/2026 e, no balanço de um ano publicado em 14/04/2026, 500 mil pulls por dia e mais de 2 mil imagens.

Se o assunto é reduzir imagem sem comprar catálogo, a abordagem de imagem mínima construída na mão está em Imagens de contêiners Python no Kubernetes com Distroless.

Build e Compose

Vale uma ressalva de precisão: o docker compose watch, da seção develop, não teve anúncio de GA nessa janela. Ele amadureceu no período, mas já existia antes.

Segurança do período

Além dos CVEs já citados por release, quatro eventos merecem registro.

A virada para agentes

Boa parte do investimento da Docker nos últimos dois anos foi para IA. Em ordem:

• Model Runner ficou GA em 18/09/2025. Roda LLM local, puxa modelo do Docker Hub em formato OCI ou do HuggingFace em GGUF, expõe API compatível com a da OpenAI e usa GPU em macOS com Apple Silicon, Windows com NVIDIA ou Qualcomm e Linux. É construído sobre o llama.cpp e é open source. Em 26/02/2026 ganhou vLLM no Apple Silicon.
• MCP Catalog e MCP Toolkit foram anunciados em 22/04/2025 e ficaram disponíveis em beta em 05/05/2025, com mais de 100 servidores MCP conteinerizados no Hub e gestão de credenciais com isolamento por container.
• MCP Gateway saiu em 09/07/2025 como projeto open source, disponível em github.com/docker/mcp-gateway. É um ponto único de enforcement entre agente e servidores MCP, com --verify-signatures, --log-calls e --block-secrets. Se MCP com Docker é o assunto, escrevi sobre o uso prático em MCP Server com Docker e Terraform.
• cagent é o runtime de agentes declarado em YAML, distribuível como artefato OCI pelo Docker Hub, apresentado em 2025 e depois integrado ao Docker Desktop, com suporte a Agent Client Protocol.
• Docker Offload entrou em beta em 10/07/2025 e ficou GA em 02/04/2026, como add-on de Docker Business. Manda build e execução para infraestrutura na nuvem da Docker, com GPU opcional.
• Gordon, o agente de IA integrado ao fluxo de container, ficou GA em 19/05/2026, gratuito em qualquer conta, com um tier Gordon Plus a 20 dólares por mês.
• Docker Sandboxes é o movimento mais recente, anunciado em 30/01/2026 e detalhado em Run Agents in YOLO Mode, Safely em 31/03/2026. Roda agente de código em microVM, cada sandbox com daemon Docker, filesystem e rede próprios, via CLI sbx. A documentação diz que o CLI é gratuito inclusive para uso comercial, e que só os recursos de governança organizacional exigem assinatura. Em 16/04/2026 a Docker explicou por que microVM e não container: o VMM é proprietário justamente para funcionar em macOS e Windows.

O fio comum é o mesmo que já discuti em Loop Engineering na prática: a pergunta deixou de ser se o agente escreve código e passou a ser onde ele executa, com qual credencial e sob qual limite.

De relance

• Docker VMM entrou em public beta em 12/08/2026, reescrito para performance.
• Verified Publisher virou self-serve em 20/08/2026.
• OIDC para GitHub Actions em organizações Docker saiu em 31/07/2026, o que elimina secret de longa duração no pipeline.
• Docker Desktop passou por 4.40 (Model Runner), 4.43 (MCP Catalog remodelado e Compose Bridge, que gera configuração de Kubernetes) e 4.50 (ferramentas de debug gratuitas).
• Não há anúncio oficial de mudança de preço ou de limite do Docker Hub em 2026. O que circula em site de terceiros sobre "allowance com overage" não tem fonte primária, então não tratei como fato.

O que eu tiro disso

Olhando os dois anos inteiros, três coisas entram na minha lista de atenção.

O resto, imagem, build, Compose e registry, continua sendo o mesmo Docker de sempre, o que é uma boa notícia sobre a estabilidade da base.

Referências

• Docker Engine release notes 27
• Docker Engine release notes 28
• Docker Engine release notes 29
• Hardening Container Networking by Default
• Docker Hub: uso e limites de pull
• Revisiting Docker Hub Policies
• Announcing Upgraded Docker Plans
• Introducing Docker Hardened Images
• Docker Hardened Images grátis e open source
• Migração da Minimus para Docker Hardened Images
• Docker ELS e o fim de vida do MinIO
• GA do Docker Bake
• Build AI Agents with Docker Compose
• GA do Docker Model Runner
• Docker MCP Catalog e Toolkit
• Docker MCP Gateway
• GA do Docker Offload
• Docker Sandboxes
• Comprometimento da supply chain do Trivy
• Aposentadoria do Docker Content Trust
• runc releases e advisories