Podman v6.0.0 é lançado

• O Podman v6.0.0 é uma versão principal que refina a experiência de gerenciamento de contêineres, incluindo modernização da infraestrutura central junto com melhorias de segurança e usabilidade
• A rede deixa de ser centrada em slirp4netns e iptables e passa para uma base em Netavark, Pasta e nftables, reduzindo a carga de manutenção e preparando o caminho para futuras expansões de recursos
• O recurso experimental Pesto rootless port forwarding oferece suporte à preservação correta do source IP em contêineres rootless em redes personalizadas
• O Podman Machine melhora a usabilidade com vários provedores de VM, e podman machine os update permite manter o ambiente da VM atualizado
• Quadlet, o processamento de arquivos de configuração, a compatibilidade com a API do Docker e a saída dos comandos também foram refinados, facilitando o gerenciamento multiusuário e a migração a partir do Docker

---

O que mudou no Podman v6.0.0

• A versão mais recente pode ser conferida na página de releases no GitHub e também deve chegar em breve aos gerenciadores de pacotes

• Modernização da rede

  • Houve a transição de slirp4netns e iptables para Netavark, Pasta e nftables
  • A pilha de rede reorganizada simplifica a manutenção e serve de base para futuras adições de recursos
  • O suporte experimental a Pesto rootless port forwarding permite preservar corretamente o source IP em contêineres rootless em redes personalizadas

• Melhorias no Podman Machine

  • A usabilidade foi melhorada para lidar de forma mais fluida com vários provedores de VM
  • O comando podman machine os update permite manter o ambiente da VM atualizado
  • Melhorias adicionais relacionadas serão abordadas com mais detalhes em um artigo separado no futuro

• Expansão do Quadlet

  • Foi adicionado suporte à REST API
  • O rastreamento de arquivos relacionados foi melhorado para facilitar o gerenciamento
  • Os recursos da unidade .volume foram ampliados
  • Foram incluídos caminhos de busca adicionais para facilitar o empacotamento de distribuição

Configuração e compatibilidade com Docker

• O processamento de arquivos de configuração foi alterado, permitindo que administradores em ambientes multiusuário usem o sistema de forma mais fluida e confiável
  • Os detalhes podem ser vistos em Podman 6 configuration file changes
• A compatibilidade com Docker também foi melhorada
  • O suporte à API do Docker foi atualizado
  • A saída dos comandos foi refinada, facilitando a migração do Docker para o Podman
• A lista completa de mudanças está organizada nas notas de lançamento do Podman v6.0.0

[click]

Estou pensando em migrar quando o podman compose ficar utilizável, mas não faço ideia de quando isso vai acontecer.
Hoje em dia, acho que executar diretamente com docker run serve só para contêineres temporários ou execuções de teste, então vejo o suporte ruim a compose como uma grande fraqueza.
Se você precisa de uma configuração extensa e de gerenciamento bem definido, é melhor simplesmente usar k8s.
Em pleno 2026, o atrativo do docker ou do podman é poder definir toda a stack usada por uma aplicação com um único arquivo de configuração yml simples, sem várias definições de recursos do k8s.
Se a ideia é destacar a compatibilidade com k8s, é muito melhor usar uma implementação leve de k8s que rode localmente, como k3s, minikube ou microk8s.
Não acho que rootless seja o problema.

[GN⁺]

Opiniões no Hacker News

• Não entendo por que o Docker ainda é muito mais popular que o Podman. Olhando só para a implementação, o Podman é claramente melhor, e os novos recursos de rede também são uma melhoria bem-vinda

  • O principal motivo deve ser que a implantação é um pouco mais trabalhosa e envolve mais etapas separadas. Especialmente se você quiser ir de modo rootless, e na verdade deveria ser assim.
    Para alguém que não coloca Linux em primeiro lugar, por exemplo um desenvolvedor iniciante aprendendo a conteinerizar apps, lidar com arquivos de unidade do systemd ou configuração do kubelet, criar uma conta de serviço local dedicada e ainda lembrar de ativar linger é bem mais intimidante do que instalar o Docker, criar um arquivo docker compose e clicar em “start”.
    Entendo por que escolheram essa abordagem, mas ela é bem grosseira e pouco amigável
  • O fuse-overlayfs era visivelmente mais lento que a configuração com overlayfs do Docker. Talvez exista uma forma de reconfigurar, mas não verifiquei recentemente.
    Ao compilar o ghostty com Zig, acho que no Podman quebrava com um erro vago de “unknown file”, e no fim era porque o fuse-overlayfs não dava suporte a alguns atributos que ele tentava verificar.
    Toda vez que tento migrar, esses pequenos problemas aleatórios continuam atrapalhando. Uso para casos simples
  • Da última vez que verifiquei, o podman compose só parecia com o docker compose por fora. Coisas como inotify também parecem quebrar aleatoriamente com frequência no lado do Podman.
    Eu queria recomendar o Podman, mas a compatibilidade com docker compose não é boa, e se o inotify em volumes fica faltando, a experiência do desenvolvedor vira um problema grande demais
  • Um nome de marca mais forte também deve ser um motivo. No macOS, o Docker Desktop era mais intuitivo. Só que, recentemente, os erros ficaram muito frequentes, e a montagem de arquivos ou a limpeza de regras de rede falhavam aleatoriamente, ou de repente tudo ficava extremamente lento e era preciso reiniciar a VM.
    O Podman no macOS parece muito menos polido, e o OrbStack é uma opção muito melhor.
    No Linux eu uso apenas Podman, e lá ele é muito rápido. Mesmo assim, a maioria dos recursos parece voltada a se integrar ao systemd para substituir Kubernetes, enquanto o suporte a docker compose em si é instável e a TUI/UX fica atrás da original
  • Desisti do Podman por motivos pequenos. Um deles foi que ele decidiu lidar com SELinux de forma diferente do Docker, exigindo alterar os rótulos de segurança do SELinux em um sistema CentOS padrão. Isso era inviável para adoção.
    Outro problema foram as pequenas diferenças em relação ao Docker, a ponto de um Docker compose empacotado não funcionar do mesmo jeito. Se eu trocasse para Docker, rodava imediatamente e eu podia seguir com o trabalho do dia; não queria gastar tempo depurando aquilo

• Depois que o Docker Desktop voltou a começar aleatoriamente a consumir uma quantidade enorme de memória, mudei para o Podman, e foi realmente tão fácil quanto instalar e apontar para o docker-compose.yml.
  Não precisei mudar nada, e agora também não preciso manter um daemon rodando o tempo todo. É um ótimo software

  • O colima era melhor que o Docker Desktop, e o Orbstack era melhor que o colima. Então descobri o smolvm, a microVM da https://smolmachines.com's
  • Por causa da bobagem de IA do Docker, ele finalmente passou dos limites e tentei migrar para o Podman, mas encontrei alguns problemas de compatibilidade. Foi alguns meses atrás, então não lembro dos detalhes.
    Então testei o Rancher Desktop e, tirando o fato de eu sempre esquecer o nome, ele simplesmente funcionou bem. É mais uma opção simples para quem precisar

• Eu gosto muito do Quadlet. Por anos hospedei contêineres rootless sem problemas com Hetzner, Ansible, SystemD e RockyLinux, e extraí essa configuração para um repositório de template.
  [1] https://github.com/Mati365/hetzner-podman-bunjs-deploy

  • Troquei meu servidor doméstico de k3s para quadlet e o consumo de energia caiu 8%

• Estou curioso sobre a experiência de migrar do Docker para o Podman
  Tenho muitos arquivos compose na minha configuração de homelab/automação, então essa é minha maior preocupação

  • Migrei do Docker para o Podman há cerca de 15 meses e não pretendo voltar. Pessoalmente, gosto muito do quadlet, ou seja, da integração com o systemd, que torna muito mais fácil monitorar um conjunto de serviços em execução, sejam serviços systemd comuns ou contêineres
    A execução rootless também é bem intuitiva, e o Podman é muito rápido. Pessoalmente, não sinto tanta falta do docker compose, mas entendo que a ausência do docker compose possa ser um problema crítico para outras pessoas. Nunca usei o plugin de compose do Podman
  • No meu homelab, converti um arquivo docker compose enorme para podman quadlet. Pelo que lembro, ao migrar os primeiros serviços, levou um pouco de tempo porque não havia tanta documentação e exemplos de quadlet em comparação com arquivos compose, mas depois disso ficou muito fácil. Recomendo muito
    O único problema é a validação. Não há um comando embutido conveniente para validar arquivos quadlet, e o systemd também não avisa quando a geração falha. É preciso rodar --dry-run antes, criar algum alias adequado para o comando completo, ou então verificar erros no journal
  • Migrei alguns anos atrás, antes da versão 5.0, e nunca olhei para trás. Para arquivos compose, vale considerar usar quadlet
    Para uma conversão rápida, você pode usar diretamente o podman-compose ou configurar o docker compose para apontar para o socket do Podman[0]
    Também existe o podlet[1], que converte arquivos compose para quadlet nativo. Ele geralmente lida bem sozinho com a maioria dos arquivos compose simples ou de complexidade média, e eles já funcionam de cara. Também há conversas sobre transformá-lo em uma biblioteca para que outras ferramentas convertam arquivos compose para quadlet de forma transparente, então espero ver mais ferramentas parecidas no futuro
    Se você tiver alguma familiaridade com arquivos de unidade do systemd, escrever arquivos Quadlet diretamente também não é difícil. A maioria dos argumentos de docker run ou podman run mapeia diretamente para quadlet, então, quando você se acostuma com o formato INI em vez de YAML, fica fácil olhar para um arquivo compose e produzir um quadlet equivalente
    [0] https://www.redhat.com/en/blog/podman-docker-compose
    [1] https://github.com/containers/podlet
  • Há 1 ou 2 anos, migrei tudo para Podman rootless. Alguns contêineres tiveram problemas de permissão ao ler dados antigos, porque tinham sido executados com outro UID
    Esse foi literalmente o único problema que tive, e teria acontecido o mesmo se eu tivesse migrado de Docker com privilégios de root para Docker rootless. Não me arrependo nem um pouco e jamais pretendo voltar
  • Tenho tanta gratidão pelo Podman quanto tenho pelo git
    O Podman se mostrou maduro e sensato. Se o contêiner de alguém depende de privilégios de su, culpo essa pessoa, não o Podman

• O que não gosto no Podman é que ele finge ser compatível com Docker, mas há pequenas diferenças que acabam mordendo você depois. Usuários de projetos baseados em Docker tentam executá-los com Podman e acabam vindo reclamar no projeto

  • A maioria das diferenças não veio da API de socket, do comportamento lógico ou de diferenças na linha de comando. Elas surgem principalmente do fato de o Docker presumir que está sendo executado como root, enquanto o Podman, por padrão, não faz isso
    Então corrigir incompatibilidades entre Podman/Docker geralmente significa lidar com essa suposição. Algo como adicionar algumas flags ao comando do Podman para mudar como o mapeamento de namespaces de usuário é feito entre o contêiner e o host
  • Uso Podman no Mac e no Linux há 3 anos e, infelizmente, isso sempre foi verdade. Estou disposto a insistir e encontrar a causa raiz para abrir bugs, mas, para muita gente, vai simplesmente parecer quebrado
    Mais recentemente, o comportamento do Netavark ao receber tráfego de broadcast em portas publicadas não batia com o do Docker
  • Exato. Isso me fez evitar o Podman por anos. Hoje acho que ele tem ideias inteligentes e, se você usa RHEL, é a escolha óbvia, mas deveriam ser mais honestos sobre o fato de que exige adaptação
    Especialmente ao migrar de Docker com privilégios de root para Podman rootless

• Estou curioso para saber como o Podman está hoje em dia. No macOS uso OrbStack, e parece bem mais rápido. Se o macOS 27 adicionar contêineres Linux baseados em microVM, mais nativos e com melhor desempenho, de forma parecida com o WSL, não sei como o cenário vai ficar

  • Não sei muito sobre macOS, mas no Linux ele se encaixa perfeitamente no meu uso. Um ponto de atenção é que o Podman Compose usa docker-compose como provedor padrão
    Não experimentei o provedor podman-compose, e o nome é um pouco diferente de um jeito confuso em relação ao Podman Compose. Podman Compose é uma abstração acima de docker-compose ou podman-compose. Se necessário, com Podman você também pode executar contêineres por meio do Docker Engine
  • Mesma pergunta e mesma situação. Testei no MacOS, e precisei mergulhar fundo nos fóruns da Redhat para entender o primeiro problema que encontrei. Mudar para o OrbStack foi uma escolha óbvia, mas há trade-offs claros do ponto de vista de funcionalidades

• Quadlet e contêineres rootless são dois grandes motivos para migrar do Docker para o Podman

  • Rootless foi o motivo pelo qual migrei para o Podman alguns anos atrás. É realmente fluido, e agora não preciso mais me preocupar com problemas estranhos de permissões ou falhas de serviço

• O Podman é bom, mas não entendo por que aquela cor cinza do texto é assim. Fica feio, é difícil de ler com contraste de 4,96:1, e nem chega ao nível AAA do WCAG

• Estou rodando meu servidor doméstico com podman + quadlets há cerca de 2 anos, e vi algumas coisas nas notas de versão que valem acompanhar
  podman quadlet list foi adicionado na v5.6.0 e lista os quadlets e seus contêineres
  podman system migrate --migrate-db é uma flag adicionada na v5.8.0. Eu já tinha visto antes um aviso de descontinuação do suporte ao bolt DB, mas não havia ferramenta para migrar para sqlite; agora há. Ou então, se você atualizar para o podman 6.0.0, isso será tratado automaticamente

• Tenho curiosidade sobre experiências usando o Podman para criar imagens para runtimes CRI, não Docker
  Se eu criar uma imagem com o Podman, ela vai rodar no cri-o, Docker e em vários outros runtimes?
  Como o docker build exige sudo e isso acaba sendo inconveniente em fluxos de trabalho baseados em agentes, estou pensando se devo criar imagens com o Podman rootless