Podman 6.0 Chegou Quebrando Tudo: Guia de Sobrevivência

Se você roda containers em produção e ainda depende de CNI, iptables ou cgroups v1, tenho uma notícia: o Podman 6.0 acabou de jogar tudo isso no lixo. E não, não foi gentil.

A Red Hat lançou o Podman 6.0.0 no final de junho de 2026 com uma lista de breaking changes que faria qualquer SRE perder o sono. Suporte a BoltDB? Morto. Intel Mac? Morto. Windows 10? Morto. slirp4netns? Morto. É basicamente um funeral de tecnologias legadas empacotado numa release note.

Mas calma. Antes de entrar em pânico (ou migrar tudo pra Docker por impulso), eu montei esse guia pra te mostrar exatamente o que mudou, o que vai quebrar no seu ambiente e como sobreviver à transição.

O que o Podman 6.0 matou de vez

Vou ser direto. Essas tecnologias não estão “deprecated”. Elas foram removidas. Sem flag de compatibilidade, sem aviso extra, sem “vai funcionar mais uma versão”. Saiu do código.

Isso é muita coisa pra uma release só. A mensagem da Red Hat é clara: se seu sistema operacional tem mais de 3 anos, provavelmente ficou pra trás.

Por que isso importa na prática

Se você roda Podman em um servidor CentOS 7 ou RHEL 7 com cgroups v1, o Podman 6.0 simplesmente não vai iniciar. Não é um warning. É um erro fatal.

O mesmo vale pra quem configurou redes com CNI. Seus arquivos de configuração em /etc/cni/net.d/ viraram peso morto. O Netavark usa um formato completamente diferente e fica em /etc/containers/networks/.

# Verificar se você usa cgroups v1 ou v2
stat -fc %T /sys/fs/cgroup/

# Se retornar "tmpfs" → cgroups v1 (incompatível com Podman 6)
# Se retornar "cgroup2fs" → cgroups v2 (compatível)

# Verificar se você usa CNI ou Netavark
podman info --format '{{.Host.NetworkBackend}}'

# Se retornar "cni" → precisa migrar
# Se retornar "netavark" → tudo certo

Networking: a maior mudança por baixo do capô

A stack de rede do Podman foi completamente reescrita. Saíram slirp4netns e iptables, entraram Pasta e nftables. E a mudança mais sutil (que vai pegar muita gente de surpresa): network isolation agora vem habilitado por padrão.

Isso significa que containers em redes customizadas não conseguem mais se comunicar com containers na rede padrão sem configuração explícita. Parece chato, mas é exatamente assim que o Docker sempre funcionou. Então, ironicamente, essa breaking change melhora a compatibilidade com Docker.

Pasta como substituto do slirp4netns

O Pasta (parte do projeto passt) é mais rápido e consome menos memória que o slirp4netns. A grande novidade é o suporte experimental a port forwarding rootless que preserva o IP de origem. Com slirp4netns, todo tráfego que chegava no container aparecia vindo de um IP interno genérico. Com Pasta, você finalmente vê o IP real do cliente.

# Antes (slirp4netns): IP de origem sempre 10.0.2.2
# Agora (Pasta): IP real do cliente preservado em redes customizadas

# Criar container rootless com Pasta (agora é o padrão)
podman run --rm -d --network custom-net -p 8080:80 nginx

# Verificar logs: o IP do cliente agora é real
podman logs <container_id> | head -5

nftables no lugar de iptables

Se você tinha regras manuais de firewall interagindo com containers Podman via iptables, elas pararam de funcionar. O Podman 6.0 usa exclusivamente nftables para gerenciar NAT e port forwarding.

# Listar regras nftables criadas pelo Podman
nft list ruleset | grep -A5 "podman"

# Verificar se nftables está disponível no sistema
nft --version

BoltDB morreu, SQLite assumiu

O Podman 5.x já tinha migrado internamente pra SQLite, mas ainda mantinha compatibilidade com BoltDB. No 6.0, essa ponte foi queimada.

Na primeira vez que você iniciar o Podman 6.0 com um banco BoltDB existente, ele tenta uma migração automática pra SQLite. Na maioria dos casos funciona sem problemas. Mas “na maioria dos casos” não é “sempre”.

# Backup antes de atualizar (faça isso ANTES de instalar o Podman 6)
cp -r ~/.local/share/containers/storage/libpod ~/.local/share/containers/storage/libpod.bak

# Após atualizar, verificar se a migração funcionou
podman system info | grep -i database

Eu recomendo fortemente fazer backup do diretório de storage antes de atualizar. Se a migração automática falhar, você vai precisar recriar seus containers e volumes do zero. Não é o fim do mundo, mas é trabalho que ninguém quer ter numa sexta à tarde.

Podman Machine: multi-provider e atualização de OS

O podman machine (usado principalmente no macOS e Windows pra rodar containers Linux em VMs) ganhou duas melhorias significativas.

Multi-provider transparente

Antes, se você trocasse de provider (por exemplo, de QEMU pra Apple Virtualization Framework), era uma dor de cabeça. Agora todos os comandos podman machine funcionam de forma consistente independente do provider.

Novo comando: podman machine os update

Finalmente dá pra atualizar o SO da VM sem destruir e recriar a máquina inteira.

# Atualizar o SO da VM
podman machine os update

# Nota: não funciona com provider WSL (Windows)

Cuidado com volumes no Linux

Se você usa podman machine no Linux (sim, algumas pessoas usam), os volumes agora são montados via systemd ao invés do método anterior. Isso significa que VMs existentes com volumes montados vão quebrar. A solução é recriar a VM.

# Recriar a VM (perde dados não persistidos)
podman machine rm podman-machine-default
podman machine init
podman machine start

GPU AMD: containers com aceleração gráfica

Uma das novidades mais interessantes: o Podman 6.0 agora suporta a flag --gpus para GPUs AMD, usando CDI (Container Device Interface).

Isso abre portas pra rodar workloads de machine learning e inferência em containers com GPUs AMD sem precisar de hacks ou configurações manuais. Antes, a flag --gpus só funcionava com NVIDIA.

# Rodar container com GPU AMD
podman run --gpus all --rm -it rocm/pytorch:latest python3 -c "import torch; print(torch.cuda.is_available())"

# Listar GPUs disponíveis via CDI
podman info --format '{{.Host.CDIDevices}}'

Se você estava preso ao ecossistema NVIDIA só porque o tooling de containers não suportava AMD, vale revisitar essa decisão.

Quadlet: gerenciamento declarativo de containers

O Quadlet (que permite gerenciar containers como units do systemd) ganhou melhorias estruturais importantes.

Nova estrutura de arquivos

Antes, o Quadlet usava arquivos .app pra rastrear quais arquivos pertenciam a qual Quadlet. Agora, tudo fica organizado em subdiretórios. Mais limpo, menos bugs, mais fácil de gerenciar manualmente.

# Estrutura antiga
~/.config/containers/systemd/
├── webapp.container
├── webapp.app         # tracking file

# Estrutura nova (Podman 6)
~/.config/containers/systemd/
├── webapp/
│   ├── webapp.container
│   └── (arquivos associados)

Novos recursos

Volumes anônimos agora podem ser montados via Quadlet, e as units .volume ganharam suporte a UID, GID e Options. Pra quem usa Quadlet em produção, isso simplifica bastante cenários de permissão de arquivos.

Segurança: CVE-2026-57231

O Podman 6.0 corrige uma vulnerabilidade importante: entradas malformadas no campo Env de imagens de container podiam vazar variáveis de ambiente do host para dentro do container, inclusive via operadores glob.

Isso significa que uma imagem maliciosa poderia acessar variáveis como AWS_SECRET_ACCESS_KEY ou DATABASE_URL do host. A correção é automática na atualização, mas vale verificar se você não está rodando imagens de fontes duvidosas.

# Verificar variáveis de ambiente expostas em um container
podman inspect <container_id> --format '{{.Config.Env}}'

Docker API v1.44 e a eterna compatibilidade

O Podman continua investindo pesado em compatibilidade com Docker. A API compatível foi atualizada pra v1.44, com novos endpoints e correções que aproximam ainda mais o comportamento do Podman ao do Docker.

Algumas melhorias notáveis:

• Health status dos containers agora aparece no endpoint Compat List (antes só funcionava na API nativa)
• Melhor tratamento de CDI devices e subpaths de volumes
• Pull progress report agora funciona via query parameter pullProgress

Pra quem usa ferramentas que dependem da Docker API (como Portainer, Watchtower ou CI/CD pipelines), essas correções reduzem os edge cases que ainda causavam problemas.

Mudanças sutis que vão pegar você de surpresa

Além das breaking changes grandes, tem uma série de mudanças menores que podem causar dor de cabeça se você não prestar atenção:

1. podman volume prune agora só remove volumes anônimos

Antes, removia todos os volumes não utilizados. Agora, precisa da flag --all pra manter o comportamento antigo.

# Antes (Podman 5): remove todos os volumes não usados
podman volume prune

# Agora (Podman 6): remove só volumes anônimos
podman volume prune

# Pra manter o comportamento antigo
podman volume prune --all

2. podman container commit agora pausa o container

Faz sentido (snapshot consistente), mas se seu workflow dependia de commits sem pausa, adicione --pause=false.

3. Filtros de podman volume list agora usam AND

Se você filtrava volumes com múltiplos critérios esperando OR, vai receber resultados diferentes. Agora é AND lógico.

4. Formato de labels em JSON mudou

O output de --format='{{json .Labels}}' agora retorna key=value ao invés de um map JSON. Scripts de automação que parseavam esse output vão precisar de ajuste.

Guia de migração rápido

Se você tá planejando atualizar, aqui vai um checklist prático:

# 1. Verificar compatibilidade do SO
stat -fc %T /sys/fs/cgroup/    # Precisa ser cgroup2fs
nft --version                   # nftables precisa estar instalado
podman info --format '{{.Host.NetworkBackend}}'  # Precisa ser netavark

# 2. Backup de dados
cp -r ~/.local/share/containers/storage/libpod ~/.local/share/containers/storage/libpod.bak
podman system info > /tmp/podman5-info.txt

# 3. Exportar containers importantes
podman export <container_id> > container-backup.tar

# 4. Listar redes CNI que precisam ser recriadas
ls /etc/cni/net.d/ 2>/dev/null

# 5. Atualizar
sudo dnf install -y podman  # Fedora/RHEL
# ou
sudo apt install -y podman  # Debian/Ubuntu

# 6. Verificar migração do banco
podman system info | grep -i database

# 7. Recriar redes (se usava CNI)
podman network create my-network --subnet 10.89.0.0/24

Go 1.25 como requisito mínimo

Pra quem desenvolve ferramentas ou plugins que importam o Podman como biblioteca Go, o import path mudou de github.com/containers/podman/v5 para go.podman.io/podman/v6, e o Go mínimo agora é 1.25. Se você mantém projetos que dependem do Podman como lib, essa mudança é obrigatória.

Comparativo: Podman 5.x vs Podman 6.0

Pra facilitar a decisão de migração, montei um comparativo direto entre as duas versões:

O padrão é claro: o Podman 6 cortou todas as opções legadas e ficou com a alternativa moderna em cada caso. Menos código pra manter, menos bugs, mas zero piedade de quem não atualizou a infra.

Certificados CA nativos no Machine

Um detalhe que passou batido pra muita gente: o podman machine init e podman machine set ganharam uma nova flag --import-native-ca. Quando habilitada, a VM importa automaticamente os certificados CA do host a cada boot.

Isso resolve um problema clássico de ambientes corporativos: proxies com TLS inspection que usam certificados internos. Antes, você tinha que manualmente copiar os certificados pra dentro da VM toda vez que recriava. Agora é uma flag.

# Criar VM com importação automática de certificados do host
podman machine init --import-native-ca

# Ou habilitar em VM existente
podman machine set --import-native-ca

Funciona em Windows, Linux e macOS. Menos um script de workaround no seu setup.

Vale atualizar agora?

Depende. Se você roda em infraestrutura moderna (cgroups v2, nftables, distro recente), a migração é relativamente tranquila e as melhorias de rede e segurança justificam a atualização.

Se você tá em ambientes legados ou tem pipelines de CI/CD com scripts que dependem do comportamento antigo de volume prune ou formatação de labels, eu esperaria pelo menos a versão 6.0.1 pra pegar os primeiros bug fixes.

A real é que o Podman está fazendo o que o Docker deveria ter feito anos atrás: cortar o suporte a tecnologias obsoletas ao invés de carregar compatibilidade infinita. Dói agora, mas o resultado é uma base de código mais limpa, mais segura e mais fácil de manter.

E se você ainda tá no Docker e nunca considerou o Podman: com a API Docker v1.44, network isolation por padrão e suporte nativo a GPUs AMD, talvez seja a hora de pelo menos testar. alias docker=podman e vê o que acontece. Eu apostaria que 90% dos seus workflows vão funcionar sem mudar uma linha.