Podman: contenedores sin daemon ni root

Actualizado: 2026-05-03

Podman^[1] es la alternativa a Docker que más ha madurado en los últimos años. Promovido por Red Hat y empaquetado por defecto en RHEL y Fedora, es una opción técnicamente sólida — especialmente si la prioridad es la seguridad o se trabaja en entornos donde un daemon corriendo como root supone un problema.

Puntos clave

• La diferencia arquitectónica clave: Podman ejecuta contenedores como procesos hijos directos del usuario, sin daemon central.
• El modo rootless es la ventaja de seguridad principal: un contenedor que escapa no obtiene root del host.
• La compatibilidad CLI con Docker es prácticamente total; los puntos de diferencia están en Compose y Swarm.
• Buildah, Skopeo y Podman son tres herramientas separadas donde Docker usa una sola — modularidad con ventajas para CI.
• La estrategia de coexistencia más práctica: Podman en desarrollo y CI, Docker en producción si ya está consolidado.

La diferencia arquitectónica

Docker tiene un daemon (dockerd) que corre como root y a través del cual pasan todos los comandos del CLI. Podman, en cambio, ejecuta los contenedores como procesos hijos directos del usuario que invoca el comando. No hay servicio central.

Las consecuencias de este cambio son cuatro:

• Sin punto único de fallo. Si el daemon muere, mueren todos los contenedores. En Podman, cada contenedor es independiente.
• Rootless por defecto. Podman puede ejecutar contenedores sin privilegios de root usando user namespaces. Docker lo soporta desde 2020, pero requiere configuración adicional.
• Integración con systemd. Podman puede generar units de systemd para gestionar contenedores como servicios del sistema. Sin necesidad de restart: always ni un orquestador.
• Auditoría más limpia. Cada contenedor aparece en ps con el usuario que lo lanzó, no como hijo del daemon.

Compatibilidad con Docker

La compatibilidad CLI es prácticamente total:

alias docker=podman

Para la mayoría de comandos básicos (run, build, pull, push, exec, logs), Podman es drop-in. También consume Dockerfile sin modificaciones, soporta el mismo formato de imágenes OCI y usa los mismos registries (Docker Hub, Quay, GHCR).

Tres diferencias relevantes:

• Compose. podman-compose existe pero no tiene el polish de Docker Compose. Para stacks complejos con múltiples servicios, la experiencia no está al mismo nivel, aunque mejora en cada release.
• Swarm. Podman no tiene equivalente. Si se depende del modo Swarm de Docker, no es una sustitución directa.
• Docker Desktop. Existe Podman Desktop, igualmente open-source, pero con un ecosistema de extensiones menor.

El argumento de seguridad

Si se trabaja en sectores regulados, el modo rootless es probablemente la razón principal para considerar Podman. Tres ventajas concretas:

• Un contenedor que escapa no obtiene root del host, solo los privilegios del usuario que lo lanzó.
• Sin un daemon expuesto en /var/run/docker.sock que cualquier proceso con acceso a ese socket pueda controlar.
• Auditoría más granular — cada podman run aparece como una syscall del usuario real, trazable en logs de auditd.

Para un entorno de desarrollo donde varios desarrolladores comparten un servidor, esto reduce drásticamente la superficie de ataque. Para un servidor de producción donde solo corre el propio stack, la diferencia es menor pero no nula.

Buildah, Skopeo y la separación de responsabilidades

Red Hat separó las funciones que Docker concentra en un único binario en tres herramientas distintas:

• podman: ejecuta contenedores.
• buildah^[2]: construye imágenes (más flexible que docker build, con soporte para scripts sin Dockerfile).
• skopeo^[3]: copia imágenes entre registries e inspecciona sin descargar.

Esta modularidad tiene ventajas prácticas: para una pipeline CI que solo necesita construir imágenes, instalar buildah pesa menos que Docker entero. Y skopeo permite inspeccionar imágenes remotas sin descargarlas — útil para pipelines de validación de firmas y SBOMs.

Casos donde Podman es la elección obvia

Cinco escenarios donde Podman gana claramente:

• Entornos sin acceso a root. Servidores corporativos donde cada usuario tiene su sandbox.
• Workstations de desarrollo en RHEL/Fedora. Ya viene preinstalado, integración natural.
• Pipelines CI rootless. Algunos runners de Gitea, GitLab y Jenkins evitan privilegios elevados.
• Sistemas que ya usan systemd intensivamente. Generar units para contenedores se siente nativo.
• Auditoría regulatoria. Cuando “un daemon corriendo como root” no pasa la revisión de seguridad.

Cuándo seguir con Docker

Cuatro casos donde no conviene migrar:

• Producción con Swarm. No hay sustituto directo.
• Equipos con muchas integraciones a Docker Desktop. La migración no es trivial.
• Compose stacks complejos en producción. La paridad de podman-compose no es total todavía.
• Cuando el ecosistema del equipo está maduro en Docker y la ganancia de cambiar no compensa la fricción.

Convivencia razonable

Una opción intermedia que funciona bien en la práctica: usar Podman en estaciones de desarrollo y CI, mantener Docker en producción si ya está consolidado. La compatibilidad de imágenes es total — lo que buildah construye corre en Docker sin problema. Esto da los beneficios de seguridad donde más impactan (entornos compartidos) sin migrar producción de golpe.

Para comenzar un proyecto nuevo, vale la pena probar Podman desde el principio. Viniendo de un ecosistema Docker establecido, no hay urgencia para migrar.

La integración con Trivy y Grype para escaneo de imágenes funciona igual que con Docker — ambas herramientas son agnósticas al motor de contenedores. El enfoque rootless de Podman complementa bien los principios de SLSA nivel 3 al reducir el impacto de un compromiso del entorno de build. Para servicios Rust con axum, Podman con buildah es una alternativa ligera a Docker para el pipeline de imágenes.

Conclusión

Podman ya no es “el experimento de Red Hat” — es una alternativa real con ventajas claras en seguridad y arquitectura. La compatibilidad con Docker es alta pero no completa, y conviene conocer los límites antes de prometer migraciones globales. Para casos de uso específicos — rootless, auditoría, entornos sin daemon — es la mejor opción disponible. Para producción con Swarm, sigue sin ser un sustituto.

1. Podman
2. buildah
3. skopeo