Podman v6.0.0 publicado

• Podman v6.0.0 es una versión mayor que refina la experiencia de gestión de contenedores e incluye tanto la modernización de la infraestructura central como mejoras de seguridad y usabilidad
• El networking pasa de estar centrado en slirp4netns e iptables a basarse en Netavark, Pasta y nftables, reduciendo la carga de mantenimiento y preparando el camino para futuras ampliaciones de funciones
• La función experimental Pesto rootless port forwarding permite conservar correctamente la IP de origen en contenedores rootless dentro de redes personalizadas
• Podman Machine mejora la usabilidad con varios proveedores de VM y permite mantener actualizado el entorno de VM con podman machine os update
• También se refinaron Quadlet, el procesamiento de archivos de configuración, la compatibilidad con la API de Docker y la salida de comandos, lo que facilita la administración multiusuario y la migración desde Docker

---

Qué cambió en Podman v6.0.0

• La versión más reciente puede consultarse en la página de releases de GitHub y pronto también se distribuirá mediante gestores de paquetes

• Modernización del networking

  • Se hizo la transición desde slirp4netns e iptables hacia Netavark, Pasta y nftables
  • El stack de networking depurado simplifica el mantenimiento y sirve como base para agregar funciones en el futuro
  • El soporte experimental de Pesto rootless port forwarding permite conservar correctamente la IP de origen en contenedores rootless dentro de redes personalizadas

• Mejoras en Podman Machine

  • Se mejoró la usabilidad para manejar de forma más fluida varios proveedores de VM
  • Con el comando podman machine os update se puede mantener actualizado el entorno de VM
  • Otras mejoras relacionadas se tratarán con más detalle en una publicación aparte más adelante

• Expansión de Quadlet

  • Se agregó soporte para la REST API
  • Se mejoró el seguimiento de archivos relacionados, lo que facilita la administración
  • Se ampliaron las funciones de las unidades .volume
  • Se incluyeron rutas de búsqueda adicionales para facilitar el empaquetado de distribuciones

Configuración y compatibilidad con Docker

• Cambió el procesamiento de archivos de configuración, para que los administradores que gestionan entornos multiusuario puedan usarlo de forma más fluida y confiable
  • Los detalles concretos pueden consultarse en Podman 6 configuration file changes
• También mejoró la compatibilidad con Docker
  • Se actualizó el soporte de la API de Docker
  • Se refinó la salida de comandos, lo que facilita la migración de Docker a Podman
• La lista completa de cambios está resumida en las notas de la versión Podman v6.0.0

[click]

Estoy pensando en cambiarme cuando podman compose ya sea realmente usable, pero no sé cuándo va a pasar eso.
Últimamente creo que ejecutar directamente con docker run es solo para contenedores temporales o para pruebas, así que veo como una gran debilidad que el soporte de Compose no sea bueno.
Si necesitas una configuración verbosa y una gestión más rigurosa, mejor usar k8s.
En esta era moderna de 2026, el atractivo de Docker o Podman es justamente poder definir todo el stack que usa una aplicación en un solo archivo de configuración yml, sin tener que pasar por todas las definiciones de recursos de k8s.
Si van a presumir compatibilidad con k8s, entonces es mucho mejor usar una implementación ligera de k8s que corra en local, como k3s, minikube o microk8s.
No creo que el problema sea rootless.

[GN⁺]

Opiniones en Hacker News

• No entiendo por qué Docker sigue siendo mucho más popular que Podman. Viendo solo la implementación, Podman claramente es mejor, y las nuevas funciones de red son una mejora bienvenida.

  • Creo que la razón principal es que la implementación es un poco más engorrosa y tiene más pasos separados. Sobre todo si quieres ir por el camino rootless, que en realidad es lo que deberías hacer.
    Para alguien que no prioriza Linux, por ejemplo un desarrollador principiante que está aprendiendo a contenerizar apps, tener que manejar archivos unit de systemd o configuración de kubelet, crear una cuenta de servicio local dedicada y además recordar activar linger resulta bastante más intimidante que instalar Docker, crear un archivo docker compose y apretar “start”.
    Entiendo por qué eligieron este enfoque, pero es bastante tosco y poco amigable.
  • fuse-overlayfs era notablemente más lento que la configuración overlayfs de Docker. Quizá haya alguna forma de reconfigurarlo, pero no lo he revisado últimamente.
    Al compilar ghostty con Zig, creo que en Podman fallaba con un error ambiguo de “unknown file”, y resultó ser porque fuse-overlayfs no soportaba algunos atributos que intentaba verificar.
    Cada vez que intento cambiarme, estos pequeños problemas arbitrarios terminan frenándome. Lo uso para casos simples.
  • La última vez que lo revisé, podman compose se parecía a docker compose solo en la superficie. Cosas como inotify también parecen romperse al azar con frecuencia del lado de Podman.
    Me gustaría recomendar Podman, pero si la compatibilidad con docker compose no es buena y falta inotify en los volúmenes, la experiencia de desarrollo se vuelve demasiado problemática.
  • Un nombre de marca más fuerte también debe influir. En macOS, Docker Desktop era más intuitivo. Aunque últimamente empezó a fallar muchísimo: los montajes de archivos o la limpieza de reglas de red fallaban al azar, o de pronto se volvía lentísimo y había que reiniciar la VM.
    Podman en macOS se siente mucho menos pulido, y OrbStack es una opción mucho mejor.
    Uso Podman solo en Linux, y ahí es muy rápido. Aun así, parece que la mayoría de sus funciones están orientadas a integrarse con systemd para reemplazar Kubernetes, mientras que el soporte de docker compose es inestable y la TUI/UX queda por detrás del original.
  • Dejé Podman por motivos menores. Uno fue que decidió manejar SELinux de forma distinta a Docker, lo que en un sistema CentOS estándar requería cambiar las etiquetas de seguridad de SELinux. Eso era inaceptable para adoptarlo.
    Otro problema fueron pequeñas diferencias con Docker, al punto de que el Docker compose empaquetado no funcionaba tal cual. Si cambiaba a Docker, todo corría de inmediato y podía seguir con mi día; no quería gastar tiempo depurando eso.

• Después de que Docker Desktop volviera a empezar a consumir una cantidad enorme de memoria al azar, me cambié a Podman, y de verdad fue tan fácil como instalarlo y apuntarlo a docker-compose.yml.
  No hizo falta cambiar nada, y ahora tampoco necesito mantener un demonio corriendo todo el tiempo. Es un software excelente.

  • colima fue mejor que Docker Desktop, y Orbstack fue mejor que colima. Luego descubrí smolvm, la microVM de https://smolmachines.com's.
  • Las tonterías de IA de Docker terminaron cruzando la línea y me hicieron intentar migrar a Podman, pero encontré algunos problemas de compatibilidad. Fue hace unos meses, así que no recuerdo los detalles.
    Entonces probé Rancher Desktop y, salvo que siempre se me olvida el nombre, simplemente funcionó bien. Es otra opción sencilla para quien la necesite.

• Me encanta Quadlet. Durante años alojé contenedores rootless sin problemas con Hetzner, Ansible, SystemD y RockyLinux, y extraje esa configuración como un repositorio de plantilla.
  [1] https://github.com/Mati365/hetzner-podman-bunjs-deploy

  • Cambié mi servidor casero de k3s a quadlet y el consumo eléctrico bajó 8%.

• Me da curiosidad conocer experiencias de quienes hayan migrado de Docker a Podman
  En mi homelab/configuración de automatización tengo muchos archivos compose, y eso es lo que más me preocupa

  • Hace unos 15 meses migré de Docker a Podman, y no pienso volver. Personalmente, quadlet, es decir, la integración con systemd, me parece realmente buena; hace mucho más fácil monitorear conjuntos de servicios en ejecución, ya sean servicios normales de systemd o contenedores
    La ejecución rootless también es muy intuitiva, y Podman es muy rápido. En lo personal no extraño mucho docker compose, pero entiendo que la falta de docker compose puede ser crítica para otras personas. Nunca he usado el plugin compose de Podman
  • En mi homelab convertí un archivo docker compose enorme a podman quadlet. Si mal no recuerdo, al migrar los primeros servicios me tomó algo de tiempo porque no había tanta documentación ni ejemplos de quadlet comparado con los archivos compose, pero después fue muy fácil. Lo recomiendo mucho
    El único problema es la validación. No hay un comando integrado cómodo para validar archivos quadlet, y systemd tampoco advierte cuando falla la generación. Hay que correr primero --dry-run, crear un alias adecuado para el comando completo, o revisar los errores en el journal
  • Migré hace unos años, antes de la 5.0, y no miré atrás. Para los archivos compose vale la pena evaluar el uso de quadlet
    Para una conversión rápida, se puede usar podman-compose directamente, o configurar docker compose para que apunte al socket de Podman[0]
    También existe podlet[1], que convierte archivos compose a quadlet nativo. Maneja bien por sí solo la mayoría de los archivos compose simples o de complejidad media y funcionan de inmediato. También se ha hablado de convertir esto en una biblioteca para que otras herramientas transformen archivos compose a quadlet de forma transparente, así que espero que aparezcan más herramientas similares en el futuro
    Si tienes aunque sea un poco de familiaridad con los archivos de unidad de systemd, escribir archivos Quadlet directamente tampoco es difícil. La mayoría de los argumentos de docker run o podman run tienen una correspondencia directa en quadlet, así que, una vez que te acostumbras al formato INI en lugar de YAML, es fácil mirar un archivo compose y crear un quadlet equivalente
    [0] https://www.redhat.com/en/blog/podman-docker-compose
    [1] https://github.com/containers/podlet
  • Hace 1 o 2 años migré todo a Podman rootless. Algunos contenedores tuvieron problemas de permisos al leer datos antiguos, porque se ejecutaban con otro UID
    Ese fue prácticamente el único problema que tuve, y también habría ocurrido al pasar de Docker con privilegios de root a Docker rootless. No me arrepiento en absoluto y no pienso volver jamás
  • Le tengo a Podman tanta gratitud como a git
    Podman resultó maduro y razonable. Si el contenedor de alguien depende de privilegios su, culpo a esa persona, no a Podman

• Lo que no me gusta de Podman es que pretende ser compatible con Docker, pero hay pequeñas diferencias que terminan mordiéndote después. Un usuario de un proyecto basado en Docker intenta ejecutarlo con Podman y al final viene a quejarse al proyecto

  • La mayoría de las diferencias no venían de la API del socket, ni del comportamiento lógico, ni de diferencias en la línea de comandos. Surgen sobre todo de que Docker asume que se ejecuta con privilegios de root, mientras que Podman no lo hace por defecto
    Así que corregir incompatibilidades entre Podman y Docker suele consistir en manejar esa suposición. Por ejemplo, agregar algunos flags al comando de Podman para cambiar cómo se mapean los espacios de nombres de usuarios entre el contenedor y el host
  • He usado Podman en Mac y Linux durante 3 años y, lamentablemente, esto siempre fue cierto. Estoy dispuesto a insistir hasta encontrar la causa raíz y reportar bugs, pero para mucha gente simplemente parecerá que está roto
    Lo más reciente fue que Netavark no coincidía con Docker en cómo recibe tráfico broadcast en puertos publicados
  • Sí. Por eso durante años me mantuve alejado de Podman. Ahora creo que tiene ideas inteligentes y, si usas RHEL, es la elección obvia, pero deberían ser más honestos en que requiere adaptación
    Especialmente si estás migrando de Docker con root a Podman rootless

• Me pregunto cómo está Podman hoy en día. En macOS uso OrbStack y parece mucho más rápido. No sé cómo cambiará el panorama si macOS 27 agrega contenedores Linux más nativos y de mejor rendimiento basados en microVM, parecido a WSL

  • No sé mucho de macOS, pero en Linux encaja de forma fluida con mi uso. Un detalle a tener en cuenta es que Podman Compose usa docker-compose como proveedor predeterminado
    No he probado el proveedor podman-compose, y el nombre es un poco distinto de una forma confusa respecto a Podman Compose. Podman Compose es una abstracción superior sobre docker-compose o podman-compose. Si hace falta, con Podman también se pueden ejecutar contenedores a través del motor de Docker
  • Tengo la misma pregunta y estoy en la misma situación. Lo probé en MacOS, pero para entender el primer problema que encontré tuve que meterme bastante profundo en los foros de Redhat. Cambiarme a OrbStack fue una decisión obvia, aunque desde el punto de vista de funcionalidades hay trade-offs claros

• Quadlet y los contenedores rootless son dos grandes razones para migrar de Docker a Podman

  • Rootless fue la razón por la que migré a Podman hace unos años. Es realmente fluido, y ya no tengo que preocuparme por problemas ambiguos de permisos ni errores de servicios

• Podman está bueno, pero no entiendo por qué ese color gris de texto. Se ve mal y, con una relación de contraste de 4.96:1, es difícil de leer; ni siquiera llega al nivel WCAG AAA

• Llevo unos 2 años corriendo mi servidor casero con podman + quadlets, y vi en las notas de la versión algunas cosas a tener en cuenta
  podman quadlet list se agregó en v5.6.0, y lista los quadlets y sus contenedores
  podman system migrate --migrate-db es un flag agregado en v5.8.0. Antes había visto una advertencia de deprecación del soporte de bolt DB, pero no había una herramienta para migrar a sqlite; ahora sí existe. O, si actualizas a podman 6.0.0, se encarga automáticamente

• Me interesa saber si alguien ha usado Podman para compilar imágenes destinadas a runtimes CRI, no a Docker.
  Si compilo una imagen con Podman, ¿se podrá ejecutar en cri-o, Docker y otros runtimes?
  Como docker build requiere sudo y eso se vuelve molesto en flujos de trabajo basados en agentes, estoy considerando compilar imágenes con Podman rootless.