El 24 de junio de 2026 el proyecto Podman publicó la versión 6.0, y no es un release más de mantenimiento: de un saque saca cinco capas que sostuvieron a los contenedores en Linux durante casi una década. CNI, iptables, slirp4netns, cgroups v1 y BoltDB quedaron afuera. Si corrés contenedores rootless en producción, esta es la actualización que te obliga a mirar debajo del capó antes de tocar nada.
Podman 6.0 es la nueva versión mayor del motor de contenedores sin daemon de Red Hat, liberada el 24 de junio de 2026. Elimina de forma definitiva cinco dependencias heredadas —el plugin de red CNI, el backend de firewall iptables, la pila de red rootless slirp4netns, cgroups v1 y la base de estado BoltDB— y las reemplaza por Netavark, nftables, Pasta, cgroups v2 y SQLite, que ya venían siendo los defaults desde versiones anteriores.
¿Qué exactamente saca Podman 6.0 y por qué ahora?
Podman 6.0 remueve cinco componentes que estaban deprecados hacía tiempo, y en todos los casos ya existía un reemplazo que era el default. La decisión no rompe funcionalidad: rompe compatibilidad con configuraciones viejas que seguían apoyadas en esas capas. Según la página de cambios del proyecto Fedora, cada eliminación tiene su sustituto directo y documentado.
- CNI sale, entra Netavark. El viejo stack de red basado en plugins CNI ya no existe; Netavark (más Aardvark para DNS) es el único backend de red soportado. Era el default desde Podman 4.0.
- iptables sale, entra nftables. Netavark deja de programar reglas con iptables. Como dice el changelog de Fedora, nftables "es el default desde Fedora 41". Solo te afecta si tenías reglas manuales atadas a iptables.
- slirp4netns sale, entra Pasta. La pila de red rootless clásica desaparece. Pasta la reemplaza y ya era el default rootless desde Podman 5.0. El flag global
--network-cmd-path, que solo usaba slirp4netns, también se fue. - cgroups v1 sale, queda cgroups v2. "Podman 6.0 ya no soportará cgroups v1; todo el código y los tests relacionados serán removidos", según la página de cambios de Fedora. El sistema tiene que estar en cgroups v2 (default en cualquier distro moderna).
- BoltDB sale, queda SQLite. La base de estado BoltDB, reemplazada por SQLite como default desde Podman 4.8, ya no se soporta. Al arrancar, Podman 6 intenta migrar automáticamente la base a SQLite.
El patrón es claro: no es innovación agresiva, es limpieza de deuda. Todo lo que se elimina venía con warnings desde hacía más de un año y con caminos de migración documentados desde Podman 4.0. Es la misma tendencia que vimos en Kubernetes —nuestra nota "Kubernetes 1.35 deja afuera cgroup v1, ipvs y containerd 1.x" cubre el mismo movimiento del lado del orquestador—. El ecosistema entero está jubilando cgroups v1 y iptables al mismo tiempo.
¿Por qué esto obliga a repensar rootless en producción?
Porque en un setup rootless los detalles de red y cgroups no son opcionales: son el mecanismo con el que tus contenedores hablan con el mundo sin privilegios de root. Si tu automatización, tus scripts de deploy o tus imágenes base todavía asumen slirp4netns o esperan poder tocar iptables, Podman 6.0 no te va a avisar en el momento oportuno: te va a fallar cuando ya actualizaste.
Los puntos concretos que un equipo con cargas rootless en producción tiene que revisar antes de saltar:
- Dependencia explícita de slirp4netns. Buscá en tus
containers.conf, unidades systemd y scripts cualquier referencia aslirp4netnso al flag--network-cmd-path. Con Podman 6 eso deja de existir; Pasta maneja el reenvío de puertos y el NAT rootless con otra semántica. - Reglas de firewall manuales sobre iptables. Si scripteaste reglas iptables alrededor de las redes de Podman, migralas a nftables. Netavark ya no las va a mantener por vos.
- Nodos viejos en cgroups v1. Distros legacy o kernels con
systemd.unified_cgroup_hierarchy=0quedan afuera. Verificá constat -fc %T /sys/fs/cgroup/: si devuelvecgroup2fs, estás en v2. - Bases BoltDB sin migrar. La migración automática a SQLite es una operación de una sola vía. Un rollback a 5.x después de migrar no es trivial.
¿Cómo migro de BoltDB a SQLite sin romper el estado?
La migración BoltDB → SQLite es automática al primer arranque de Podman 6, pero el camino recomendado es escalonado, no directo. La reportería de Linuxiac lo resume así: "cuando Podman 6 arranca en un sistema que todavía usa una base BoltDB, intenta automáticamente migrar la base a SQLite".
El detalle importante que agrega el changelog de Fedora: conviene pasar primero por Podman 5.8 y reiniciar antes de saltar a la 6. Es decir, el orden sensato es:
- Actualizá a Podman 5.8 primero. Es el escalón intermedio que deja la base en un estado limpio.
- Reiniciá o reiniciá el servicio antes de migrar. Así no arrastrás contenedores con estado colgado en la base vieja.
- Frená los contenedores en ejecución. Migrar con procesos vivos apoyados en la base es pedir problemas.
- Hacé backup del directorio de estado. La migración es de una sola dirección; sin backup no hay vuelta atrás.
¿Qué versiones de las herramientas del stack necesito?
Podman 6.0 exige un conjunto de versiones alineadas de todo el stack de contenedores, no solo del binario principal. De acuerdo con la guía de actualización de ComputingForGeeks, Podman v6.0.0 debe usarse con:
- Buildah v1.44.0 para construir imágenes.
- Skopeo v1.23 para mover imágenes entre registries.
- Netavark y Aardvark v2.0.0 para la red y el DNS de contenedores.
- Archivos de configuración de common/v0.68.0 del repositorio container-libs.
Si usás los paquetes de tu distro (Fedora 45+, RHEL 9+, Ubuntu 22.04+), estas versiones vienen resueltas por el gestor de paquetes. Si compilás o pineás versiones a mano, este es el punto donde un desalineamiento te va a morder.
¿Hay algo nuevo además de las eliminaciones?
Sí: Podman 6.0 suma soporte para GPUs de AMD. Según Linuxiac, "Podman 6.0 agrega compatibilidad con GPU de AMD a la opción --gpus usada con podman create y podman run". Es una ganancia concreta para quien corre cargas de inferencia o cómputo sobre hardware AMD, que hasta ahora tenían un camino más artesanal.
La contracara: se dejó de soportar Podman corriendo sobre Intel Macs y Windows 10. Si tu equipo de desarrollo todavía tiene máquinas con esos entornos usando Podman Machine, esas quedan clavadas en 5.x.
¿Qué puedo hacer hoy para prepararme?
Lo primero, antes de actualizar nada, es correr una auditoría en un nodo de staging con la configuración real de producción. La decisión, como la plantea la cobertura del release, es binaria: auditás y actualizás, o te quedás en Podman 5.x. No hay término medio si tocás alguna de las cinco capas removidas.
# ¿Estás en cgroups v2?
stat -fc %T /sys/fs/cgroup/ # cgroup2fs = OK
# ¿Qué backend de red usás?
podman info --format '{{.Host.NetworkBackend}}' # deberia decir netavark
# ¿Qué base de estado?
podman info --format '{{.Host.DatabaseBackend}}' # sqlite = OK, boltdb = pendiente
# Buscar dependencias de slirp4netns en tu config
grep -r "slirp4netns\|network-cmd-path" ~/.config/containers/ /etc/containers/Si las tres primeras líneas ya te devuelven cgroup2fs, netavark y sqlite, tu migración a 6.0 va a ser prácticamente transparente. Si aparece boltdb, iptables manual o referencias a slirp4netns, ahí tenés tu lista de tareas antes de tocar el dnf upgrade.
Preguntas frecuentes sobre Podman 6.0
¿Cuándo salió Podman 6.0?
Podman 6.0 se liberó el 24 de junio de 2026 como versión mayor del motor de contenedores.
¿Podman 6.0 me obliga a reconstruir mis imágenes?
No. Las imágenes OCI no cambian. Lo que cambia es el entorno de ejecución (red, firewall, cgroups, base de estado), no el formato de las imágenes ni tus Dockerfiles/Containerfiles.
¿Puedo volver a Podman 5.x si algo sale mal?
Podés, pero con cuidado: una vez que la base migró de BoltDB a SQLite, el rollback no es directo. Hacé backup del directorio de estado antes de actualizar para tener una vía de vuelta.
¿Tengo que cambiar de slirp4netns a Pasta manualmente?
No hace falta cambiar nada si ya venías con los defaults: Pasta es el default rootless desde Podman 5.0. Solo actuás si tu configuración forzaba slirp4netns de forma explícita.
¿Netavark reemplaza también a las reglas iptables que escribí a mano?
No. Netavark ahora programa con nftables, pero cualquier regla iptables que hayas creado por fuera de Podman tenés que migrarla vos a nftables; el proyecto no las convierte automáticamente.
¿Sirve Podman 6.0 en un servidor cloud con Ubuntu o Debian actual?
Sí. Cualquier distro moderna (Ubuntu 22.04+, RHEL 9+, Fedora 45+, Debian actual) ya viene con cgroups v2 y nftables por default, así que el salto a 6.0 en un servidor cloud típico tiene una carga de migración mínima.
La conclusión práctica
Podman 6.0 no es un release para instalar a ciegas un viernes a la tarde, pero tampoco es una ruptura dramática si venís al día. Todo lo que saca estaba deprecado y todo tiene reemplazo probado. El trabajo real no es aprender tecnología nueva —Netavark, Pasta, SQLite y cgroups v2 ya corrían bajo tus contenedores— sino confirmar que ninguna parte de tu automatización sigue apoyada en las capas viejas. Auditá en staging, revisá las tres líneas de podman info, migrá la base con backup y recién ahí actualizá producción.
Si administrás tus contenedores rootless en un servidor cloud propio, este es el momento ideal para hacer esa auditoría con calma, antes de que la próxima actualización del sistema te traiga Podman 6 sin que lo hayas decidido vos.
Cloud Serversby Donweb
Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.
- Performance que te sorprenderá
- Rápida escalabilidad y sin limitaciones
- Arquitectura de alta disponibilidad
- Soporte experto y ejecutivos de cuenta
- Pagos en tu moneda y facturación local
