Programación · DevOps · Contenedores
Docker vs Podman: ¿qué motor de contenedores, y cuándo?
Respuesta rápida: Docker y Podman hacen el mismo trabajo de fondo — construir y ejecutar contenedores — y usan el mismo formato de imagen, así que una imagen construida con uno se ejecuta en el otro. La diferencia principal es la arquitectura: Docker ejecuta los contenedores mediante un daemon central de larga duración (dockerd) que suele correr como root, mientras que Podman es sin daemon y rootless por diseño, lanzando cada contenedor como un simple proceso hijo. Sus líneas de comandos son lo bastante parecidas como para que alias docker=podman cubra casi todo el uso diario. Elige Podman cuando quieras prescindir del daemon root y tener una integración estrecha con systemd; quédate con Docker cuando dependas de Docker Desktop, de un flujo de Compose maduro o de un ecosistema más amplio.
Si empiezas con cualquiera de los dos, conviene entender primero qué son Docker y los contenedores. Esta guía parte de ahí y se centra en lo que distingue a los dos motores.
Arquitectura: con daemon vs sin daemon
Docker se basa en un modelo cliente-servidor. El comando docker que escribes es un cliente que habla con un servicio en segundo plano, el daemon de Docker (dockerd), que en realidad crea y ejecuta tus contenedores. Ese daemon corre de forma continua y, en la configuración por defecto, como root. Es cómodo — un solo servicio lo gestiona todo — pero también es un único proceso privilegiado que posee todos los contenedores del host.
Podman toma otro camino. No hay daemon central: cuando ejecutas un contenedor, Podman lo hace fork y luego exec directamente como proceso hijo de tu shell, usando las mismas primitivas de Linux (namespaces, cgroups). Cada contenedor es solo un árbol de procesos normal. Ese modelo sin daemon significa que no hay un servicio root siempre activo que comprometer, y que un fallo en un contenedor no pasa por un daemon compartido.
Contenedores rootless y seguridad
Esa diferencia de arquitectura lleva a la diferencia de seguridad que más importa. Podman se diseñó para correr en rootless: un usuario sin privilegios puede construir y ejecutar contenedores sin root, usando user namespaces para mapear los UID del contenedor al host. Docker también puede correr en rootless, y lo soporta desde hace años, pero su instalación por defecto sigue centrada en el daemon root, así que rootless es un modo opcional más que la base.
No tener un daemon root reduce la superficie de ataque: no hay un servicio privilegiado en segundo plano al que una fuga de contenedor pudiera apuntar para tomar el control del host. Para servidores multiusuario y runners de CI, esa propiedad de «sin daemon root» es una razón concreta y real para pasarse a Podman. No es magia — los contenedores siguen necesitando una configuración cuidadosa — pero la postura por defecto es más conservadora.
Mismas imágenes, CLI casi idéntica
Esto es lo que hace indoloro el cambio: ambas herramientas siguen los estándares OCI (Open Container Initiative) para imágenes y ejecución. Una imagen construida con Docker corre bajo Podman y viceversa, y ambas descargan de los mismos registros (Docker Hub, GitHub Container Registry, Quay y otros). No existe un formato de imagen exclusivo de Docker o de Podman.
Las líneas de comandos son deliberadamente parecidas. podman run, podman build, podman ps y podman pull reflejan a sus equivalentes de Docker, con las mismas opciones comunes. Mucha gente simplemente pone un alias:
alias docker=podmany conserva sus costumbres. Los Dockerfiles funcionan tal cual bajo Podman también. La CLI no es idéntica al 100 % en todos los casos límite, pero para construir y ejecutar a diario es lo bastante parecida como para que la memoria muscular se transfiera.
Pods: la agrupación al estilo Kubernetes de Podman
Podman toma su nombre del pod — un concepto que toma prestado de Kubernetes. Un pod es un grupo de contenedores que comparten recursos como un namespace de red, de modo que se comunican entre sí por localhost como si estuvieran en la misma máquina. Podman puede crear y gestionar esos pods directamente, lo que acerca el desarrollo local a cómo corren las cosas en un clúster de Kubernetes. Docker no tiene una primitiva «pod» nativa en el mismo sentido; los montajes multicontenedor se componen con las redes de Compose en su lugar.
Integración con systemd
Como los contenedores de Podman son procesos hijos normales en lugar de hijos de un daemon, encajan de forma natural en systemd, el gestor de servicios de Linux. Históricamente podías ejecutar podman generate systemd para producir un archivo de unidad por contenedor; el enfoque actual recomendado es Quadlet, que permite describir los contenedores en archivos declarativos de estilo unidad que systemd gestiona directamente — arrancándolos al inicio, reiniciándolos ante fallos y siguiéndolos como cualquier otro servicio. Para servidores que ya usan systemd para todo lo demás, es una forma limpia de mantener los contenedores bajo el mismo supervisor sin un daemon extra.
Compose: docker compose vs podman
Muchos proyectos se apoyan en Compose para levantar varios contenedores desde un solo archivo YAML. Docker incluye docker compose (el plugin Compose v2) como herramienta de primera clase y bien mantenida. Podman también soporta flujos de Compose: puede trabajar con la herramienta aparte podman-compose, y además ofrece un socket con el que el utillaje estándar de Compose puede hablar, de modo que archivos compose.yaml existentes suelen correr con poco o ningún cambio. En la práctica, la experiencia de Compose de Docker es la más madura y pulida de las dos, lo que explica que los equipos con uso intensivo de Compose a veces se queden en Docker.
Licencia de Docker Desktop vs modelo open source de Podman
En Windows y macOS, Docker se usa normalmente a través de Docker Desktop. Docker Desktop es gratuito para uso personal, educación y pequeñas empresas, pero requiere una suscripción de pago para organizaciones grandes (por encima del umbral de tamaño publicado por Docker). Ese cambio de licencia es una consideración real de presupuesto y cumplimiento para las empresas más grandes.
Podman es totalmente open source y gratuito, sin licencia por puesto. Su compañero de escritorio, Podman Desktop, también es open source. Para las organizaciones que quieren evitar una licencia de escritorio comercial — o simplemente prefieren una pila open source de extremo a extremo — esa diferencia importa tanto como cualquier diferencia técnica.
Entonces, ¿cuál usar?
| Criterio | Docker | Podman |
|---|---|---|
| Arquitectura | Daemon central (dockerd) | Sin daemon (fork/exec por contenedor) |
| Rootless | Soportado, opcional | Rootless por diseño (por defecto) |
| Formato de imagen | OCI | OCI — intercambiable con Docker |
| CLI | CLI de referencia | Casi idéntica (alias docker=podman) |
| Pods | Sin primitiva pod nativa | Pods nativos (estilo Kubernetes) |
| systemd | Corre bajo el daemon | Unidades nativas vía Quadlet |
| Compose | docker compose (maduro) | podman-compose / Compose vía socket |
| Licencia de escritorio | Docker Desktop de pago para orgs grandes | Open source, gratis (Podman Desktop) |
No hay un ganador universal. Elige Podman cuando quieras prescindir del daemon root, tener contenedores rootless por defecto, una gestión systemd/Quadlet nativa, o evitar la licencia de Docker Desktop. Quédate con Docker cuando dependas de Docker Desktop, de un flujo de Compose maduro, o de la amplitud de su ecosistema y documentación. Como ambos hablan OCI, también puedes mezclarlos — construir con uno, ejecutar con el otro — o probar Podman sin tirar tus imágenes y Dockerfiles existentes. Y si más adelante necesitas orquestar muchos contenedores en varias máquinas, eso es tarea de Kubernetes, que se sitúa por encima de los dos.