Podman 6.0: cambios y breaking changes 2026

Si administrás un servidor con contenedores y todavía no usás Podman, es probable que tarde o temprano te lo cruces: es el motor sin daemon que Red Hat impulsa como reemplazo directo de Docker, y la pieza sobre la que se construyen hoy las instalaciones de RHEL en producción. La versión 6.0, publicada a fines de junio de 2026, es una de las más agresivas en años: no agrega tanto como saca. Jubila BoltDB, los Intel Macs, cgroups v1, CNI, iptables y slirp4netns de una sola pasada. Si tenés contenedores corriendo, conviene entender qué se va antes de tipear apt upgrade.

Podman 6.0 es la nueva versión mayor del motor de contenedores sin daemon de Red Hat, lanzada en junio de 2026. Es un reemplazo de Docker compatible con su CLI, pensado para correr contenedores rootless en servidores Linux. Esta versión elimina la base de datos BoltDB y migra automáticamente a SQLite, descarta el soporte para Intel Macs, cgroups v1, CNI, iptables y slirp4netns, y suma soporte para GPUs AMD.

¿Qué es Podman y por qué no tiene daemon?

Podman 6.0: qué cambia (y qué rompe) en tu cloud server

Antes de hablar de los cambios, aclaremos el primer punto del título, porque es el que más se malinterpreta: el "chau daemon" no es una novedad de 6.0. Podman nunca tuvo un daemon. Esa es justamente su diferencia de fondo con Docker, y es arquitectónica, no cosmética.

Docker usa un modelo cliente-servidor: cuando escribís docker run, el CLI no crea nada, le manda una petición a un proceso de fondo privilegiado (dockerd) que corre como root y es dueño de todos los contenedores. Podman no tiene ese proceso central. Cada contenedor arranca como un proceso hijo de la sesión que lo lanzó. No hay servicio de fondo permanente ni socket privilegiado escuchando en el sistema.

Eso tiene dos consecuencias prácticas:

Rootless de verdad y por default. Podman usa user namespaces para mapear tu UID del host a root dentro del contenedor. El proceso "cree" que es root para instalar paquetes, pero en el host es un usuario común. Si alguien logra un escape del contenedor, cae como usuario sin privilegios, no como root.
Se lleva bien con systemd. Como no hay daemon intermediario, un contenedor lanzado por una unit de systemd es hijo directo de systemd, con su supervisión, logging y manejo de ciclo de vida real.

Si venís de Docker, esto ya lo cubrimos en la nota "Comparativa Docker vs Kubernetes" y en "¿Por qué todos piden DOCKER?"; sirven como lectura complementaria para ubicar dónde encaja Podman.

¿Qué se rompe al pasar a Podman 6.0?

Esta es la parte que importa para un servidor en producción. Podman 6.0 es una versión de limpieza: saca código viejo que arrastraba compatibilidad. Estos son los cambios que pueden romperte algo:

BoltDB se va: ahora la base es SQLite

Podman guarda el estado de tus contenedores (qué existe, sus redes, sus volúmenes) en una base de datos local. Hasta acá podía ser BoltDB. En 6.0 BoltDB deja de estar soportado: la primera vez que arrancás Podman 6 sobre un sistema que todavía usa BoltDB, intenta migrar la base a SQLite automáticamente.

La migración es de una sola dirección. Una vez que pasaste a SQLite, no hay vuelta atrás a BoltDB. Si algo sale mal, no podés simplemente "downgradear" la base.
Hacé backup antes de actualizar. Respaldá tu directorio de almacenamiento (en rootless suele ser ~/.local/share/containers y la config en ~/.config/containers) antes de tocar la versión. Es barato y te cubre.

Chau Intel Macs (y Windows 10)

Esto pega más del lado del desarrollo que del servidor, pero conviene saberlo: se eliminó el soporte para correr Podman sobre Intel Macs, y también se descartó Windows 10. En macOS el provider por default pasó a ser libkrun. Si tu equipo desarrolla con Podman Machine en una Mac vieja con chip Intel, te vas a quedar clavado en la rama 5.x. En el servidor Linux esto no te afecta.

La red se moderniza: Netavark, nftables y Pasta

Acá hay tres remociones que pueden morder si tenés configuración de red a mano:

CNI deja de existir, queda Netavark. Si todavía usabas el stack de red CNI, en 6.0 ya no está; el stack moderno (Netavark + Aardvark para DNS) es el único camino.
iptables sale, entra nftables. Las reglas de firewall que generaba Podman ahora se apoyan en nftables. Si tenés scripts o reglas propias atadas a iptables, revisalas.
slirp4netns se retira, lo reemplaza Pasta. Para el networking rootless, Pasta pasa a ser el motor por default.

cgroups v1: se terminó

Podman 6.0 ya no corre sobre sistemas con cgroups v1. Hace falta cgroups v2 sí o sí. La mayoría de las distros modernas (Ubuntu 22.04+ en adelante, por ejemplo) ya vienen con v2 por default, así que en un Cloud Server actualizado no debería ser un problema; pero si mantenés un servidor viejo, verificalo antes.

¿Y qué suma de nuevo Podman 6.0?

No todo es recortar. Las novedades concretas:

GPUs AMD. La opción --gpus ahora soporta GPUs AMD en podman run y podman create, no solo NVIDIA.
Mejoras en Podman Machine. Nuevo comando podman machine os update, importación de certificados CA con --import-native-ca y comandos de máquina que operan sobre VMs de cualquier provider.
IPs estáticas múltiples por contenedor y mejor compatibilidad de aislamiento de red con Docker.

¿Cómo actualizo a Podman 6.0 en mi servidor?

El detalle clave: Podman 6.0 no funciona solo. Tiene dependencias de versión que tenés que respetar o vas a tener errores raros. Necesita acompañarse de Buildah 1.44, Skopeo 1.23, y Netavark/Aardvark 2.0, además de los archivos de configuración del release common/v0.68.

Los pasos razonables en un servidor Ubuntu:

Verificá tu versión actual con podman --version y revisá si estás sobre cgroups v2: stat -fc %T /sys/fs/cgroup/ debería devolver cgroup2fs.
Respaldá tu storage y tu config de contenedores antes de tocar nada (ver arriba). La migración BoltDB→SQLite es automática pero irreversible.
Actualizá los paquetes juntos. Tené en cuenta que los repos oficiales de las distros suelen ir atrás de la última versión: puede que apt todavía no te ofrezca 6.0 ni los Buildah/Skopeo en las versiones requeridas. Verificá qué versión te instala antes de asumir que tenés la 6.0.
Arrancá un contenedor de prueba después de actualizar para confirmar que la migración de base de datos se hizo sin perder nada.

Una nota de compatibilidad para quien empaqueta o compila: el import path cambió de github.com/containers/podman/v5 a go.podman.io/podman/v6 tras la migración del proyecto a la organización CNCF.

Pros y contras reales de Podman 6.0

Sin folleto. Lo bueno y lo que duele:

A favor: menos superficie de ataque. Sin daemon root permanente y con rootless por default, el modelo de seguridad es genuinamente más sólido que el de un Docker tradicional.
A favor: integración nativa con systemd. Para servidores que ya viven en systemd, los contenedores se manejan como cualquier otro servicio.
A favor: limpieza técnica. Sacar CNI, iptables, slirp4netns y cgroups v1 reduce deuda y deja un stack más coherente (Netavark/Pasta/nftables).
En contra: es una versión que rompe. No es un upgrade transparente. Si tenés automatización atada a iptables, redes CNI o BoltDB, hay trabajo de migración.
En contra: el ecosistema va atrás. Vas a depender de que tu distro empaquete Podman 6.0 y las versiones correctas de Buildah/Skopeo/Netavark. Mezclar versiones es una fuente de bugs.
En contra: corta hardware viejo. Intel Mac, Windows 10 y cgroups v1 quedan afuera. Para algunos equipos eso significa quedarse en 5.x.

¿Para quién es Podman 6.0 y cuándo NO conviene?

Te conviene si administrás servidores Linux modernos (cgroups v2), querés contenedores rootless por seguridad, ya usás systemd para orquestar servicios, o estás en el ecosistema Red Hat/Fedora donde Podman es el estándar de facto.

No te conviene apurarte si tu servidor todavía corre cgroups v1, si tenés infraestructura de red atada a CNI o iptables que no podés migrar ya mismo, o si dependés de Intel Macs para desarrollo local. En esos casos, quedate en la rama 5.x estable, planificá la migración y recién después saltá. En producción, nunca actualices una versión mayor el mismo día que sale.

Veredicto: ¿vale la pena Podman 6.0?

Sí, pero con calendario, no por impulso. Podman 6.0 es una buena versión: madura el proyecto, lo deja más limpio y refuerza lo que siempre fue su mejor argumento, la arquitectura sin daemon y rootless. Pero es explícitamente una release de breaking changes: el valor está en lo que saca, y eso exige que pruebes en un entorno de staging antes de tocar producción. Si arrancás un proyecto nuevo en un Cloud Server al día, empezá directo en 6.0. Si tenés contenedores en producción sobre 5.x, hacé backup, levantá una réplica de prueba, validá la migración a SQLite y la red con Netavark, y recién ahí actualizá el servidor real.

Preguntas frecuentes sobre Podman 6.0

¿Cuándo salió Podman 6.0?

Podman 6.0 se publicó a fines de junio de 2026. Es la versión mayor que reemplaza a la rama 5.x.

¿Podman 6.0 borra mis contenedores al migrar de BoltDB a SQLite?

No debería: la migración de BoltDB a SQLite es automática al primer arranque y conserva el estado. Aun así, es irreversible, así que respaldá tu directorio de almacenamiento antes de actualizar.

¿Sigo pudiendo usar Podman en una Intel Mac?

No con Podman 6.0: se eliminó el soporte para Intel Macs. Si necesitás Podman en ese hardware, tenés que quedarte en la rama 5.x.

¿Podman 6.0 necesita cgroups v2?

Sí. Podman 6.0 ya no soporta cgroups v1; necesitás cgroups v2. Las distros Linux modernas ya lo traen por default, pero verificalo en servidores viejos.

¿Tengo que actualizar Buildah y Skopeo junto con Podman 6.0?

Sí. Podman 6.0 requiere Buildah 1.44, Skopeo 1.23 y Netavark/Aardvark 2.0. Mezclar versiones viejas con Podman 6.0 genera errores.

¿Podman 6.0 reemplaza a Docker?

Funcionalmente puede: Podman es compatible con la CLI de Docker y corre sin daemon ni root. La migración no es automática, pero para la mayoría de los casos de un servidor Linux, los comandos y los Containerfile/Dockerfile son intercambiables.

Fuentes: Linuxiac — Podman 6.0 Lands with Breaking Changes, Fedora Project Wiki — Changes/Podman6, LWN.net — Podman 6.0 released y Red Hat — What is Podman.

Podman 6.0: qué cambia (y qué rompe) en tu cloud server

¿Qué es Podman y por qué no tiene daemon?