Llevo tiempo usando Podman como motor de contenedores en varios de mis
proyectos personales, desplegados en un VPS propio, y a estas alturas
ya no me planteo volver a Docker salvo que el proyecto lo exija por
compatibilidad con alguna herramienta específica.
Qué es y por qué existe
Podman es un motor de contenedores compatible con la especificación
OCI, desarrollado originalmente por Red Hat, pensado como alternativa
directa a Docker. La diferencia de fondo está en la arquitectura:
Docker depende de un demonio corriendo permanentemente en segundo
plano con privilegios de root, mientras que Podman es "daemonless" —
cada contenedor se ejecuta como un proceso hijo normal, sin ese proceso
central con permisos elevados vigilando todo.
Esto no es un detalle técnico menor. Significa que Podman puede correr
contenedores en modo "rootless" de verdad, como usuario normal sin
privilegios de administrador, algo que en Docker históricamente ha
sido más una función añadida a posteriori que el diseño original.
Podman cumple lo que promete: compatibilidad casi total con el ecosistema Docker, pero con una arquitectura más segura por diseño.
Rootless de verdad, no de nombre
El modo rootless es la razón principal por la que lo prefiero. En
un servidor donde conviven varios proyectos de distintos usuarios o
niveles de confianza, tener contenedores corriendo sin necesidad de
que un demonio con privilegios de root esté siempre despierto reduce
mucho la superficie de ataque si algo sale mal dentro de un contenedor.
No es una promesa de marketing: se nota en la práctica al auditar qué
procesos tienen qué permisos en el sistema.
Compatibilidad con Docker: casi total, con matices
La compatibilidad de comandos es prácticamente 1:1 — podman run,podman build, podman ps funcionan igual que sus equivalentes de
Docker, y hasta se puede crear un alias docker=podman para no
cambiar ni el hábito. docker-compose tiene su equivalente directo
en podman-compose, aunque en mi experiencia el soporte de compose
es el punto donde más fricciones puntuales he encontrado — algunas
opciones avanzadas de compose no se comportan exactamente igual, y
toca revisar la documentación con más cuidado que con Docker.
Integración con systemd: el verdadero superpoder
Lo que más valoro del ecosistema Podman es Quadlet, la integración
nativa con systemd para gestionar contenedores como si fueran servicios
del sistema. En vez de depender de scripts propios o de Docker Compose
para que un contenedor arranque solo, se reinicie si falla, y sea
gestionable con los comandos habituales de systemctl, Quadlet lo
resuelve de forma nativa y sin capas extra. Para cualquiera que ya
viva en el mundo de administración de sistemas Linux, esto encaja de
forma mucho más natural que el enfoque de Docker.
Lo que hay que tener en cuenta
No todo es perfecto: hay operaciones puntuales (sobre todo con volúmenes
en modo rootless y permisos de UID/GID entre el host y el contenedor)
que requieren entender un poco mejor cómo funciona el mapeo de usuarios
por debajo — con Docker root, esto simplemente no era un problema
porque todo corría como root de forma implícita. La curva de aprendizaje
inicial es algo mayor si vienes de Docker sin haber tocado nunca el
concepto de rootless containers.
La comunidad y documentación, aunque buena, sigue siendo más pequeña
que la de Docker — para problemas muy específicos, a veces hay que
tirar más de la documentación oficial que de foros o Stack Overflow,
donde Docker todavía domina en volumen de respuestas.
Actualización: Podman 6.0 (julio 2026)
↻ Actualización
Podman 6.0 llegó a finales de junio de 2026, y a diferencia de muchas versiones mayores que solo pulen lo existente, esta se atreve a soltar lastre de verdad: elimina por completo cgroups v1, slirp4netns, soporte de iptables, CNI y BoltDB — tecnología que ya estaba marcada como obsoleta desde las series 4.x y 5.x.
Lo más relevante para quien hace IA local: soporte nativo de GPUs AMD para tareas de IA y procesamiento gráfico dentro de contenedores — hasta ahora este terreno estaba mucho más volcado hacia NVIDIA.
También destaca: la red rootless pasa a usar Pasta por defecto, el estado interno migra de BoltDB a SQLite, Quadlet mejora su integración con systemd (menos errores de configuración), y se activa el aislamiento de red por defecto entre contenedores.
Esta versión corrige además CVE-2026-57231, un fallo donde una imagen maliciosa con entradas Env malformadas podía filtrar variables de entorno del host hacia contenedores basados en esa imagen.
Ojo antes de actualizar: no es un simple apt upgrade. Requiere Buildah 1.44.0+, Skopeo 1.23+, y Netavark/Aardvark 2.0+ en conjunto. Además, se elimina el soporte para Macs Intel, Windows 10, y cualquier sistema en cgroups v1 — trátalo como una migración real, con tiempo de por medio, no como una actualización de rutina.
