Mr.PlanB Logo
    Volver al blog
    Podman
    Docker
    Contenedores
    DevOps
    Rootless
    Compose

    Podman vs Docker: mejor sobre el papel, pero pierde en la práctica

    3 de noviembre de 2025
    6 min de lectura

    Sobre el papel, Podman cumple con todos los requisitos para liderar el futuro de los contenedores: contenedores rootless, ausencia de un demonio en segundo plano consumiendo recursos y una integración más estrecha con systemd para quienes necesitan control a nivel de sistema operativo. Es seguro, es de código abierto y está diseñado siguiendo principios modernos. Entonces, ¿por qué Docker, su hermano más veterano, pesado y discutiblemente más desordenado, sigue dominando el mundo de los contenedores?

    Si alguna vez te has atrevido a mencionar Podman en un foro de desarrolladores, probablemente hayas recibido alguna variante de esto: "Sí, Podman está bien, pero Docker simplemente funciona". Esa frase resume todo el problema.

    La ventaja del pionero va más allá del marketing

    Docker irrumpió con fuerza allá por 2013, y fue mucho más que una herramienta nueva: definió la forma en que el sector entendía los contenedores. La industria se apresuró a adoptarlo y se construyeron plataformas enteras a su alrededor. Tutoriales, documentación, flujos de trabajo de CI/CD y herramientas de orquestación se diseñaron pensando expresamente en Docker. Incluso hoy, la gente habla de "contenedores Docker" con la misma naturalidad con la que llama "Kleenex" a los pañuelos de papel.

    Para cuando Podman vio la luz en 2019, Docker ya se había arraigado en los cimientos de infinidad de sistemas. Esa ventaja de seis años se convirtió en una posición dominante, y no puedes derribar una posición consolidada solo con buenas intenciones y mejores valores por defecto.

    La ilusión de la compatibilidad

    Uno de los argumentos iniciales de venta de Podman era su compatibilidad con Docker. En teoría, podías crear un alias de docker apuntando a podman y seguir trabajando sin notar la diferencia.

    En la práctica, las cosas no son tan sencillas. La experiencia real cuenta una historia distinta. Es cierto que Podman puede ejecutar muchos Dockerfiles y configuraciones de Compose, pero los usuarios se topan una y otra vez con casos límite que hacen que la transición diste de ser transparente. Como señaló un usuario decepcionado: "Lo intenté, pero Podman demostró ser mucho más problemático y menos estable. Quizá en un par de años". Otro añadió: "Hay pequeñas variaciones, no demasiadas, pero suficientes para convertirse en una molestia".

    ¿Qué tipo de variaciones? Para empezar:

    • Podman Compose es un proyecto totalmente independiente de Docker Compose, y no siempre está al día ni resulta plenamente compatible
    • Problemas con el orden de inicio de los contenedores, el comportamiento de red y las políticas de reinicio
    • Dificultades de integración con GPU o rutas de almacenamiento alternativas

    En cuanto te desvías mínimamente del camino habitual, vuelves de lleno al territorio de tener que depurarlo todo por tu cuenta.

    Diagram comparing the promise of aliasing docker to podman with the real edge cases users hit, such as Podman Compose gaps, startup order, networking and GPUs.

    Documentación: Docker es la opción por defecto

    Una de las fuerzas invisibles más potentes que mantienen a Docker en la cima es la documentación.

    Cuando prácticamente cada archivo README de GitHub, blog de desarrollo o aplicación de código abierto te pide que "ejecutes este archivo Docker Compose", sigues la ley del mínimo esfuerzo. La madurez de Docker se traduce en una inmensa cantidad de recursos, desde entradas de blog y respuestas en Stack Overflow hasta tutoriales en YouTube, listos para ayudarte a resolver tu problema exacto.

    Mientras tanto, Podman sigue pareciendo el alumno nuevo de la clase. Incluso cuando funciona a la perfección, la falta de documentación integrada exige más búsquedas en Google, más conjeturas y más método de prueba y error.

    Como afirmó sin rodeos un usuario: "La mayoría de las guías están escritas para Docker. Si utilizas lo que usa todo el mundo, es mucho más fácil conseguir ayuda".

    Compose frente a Quadlets: la brecha en el flujo de trabajo

    Si Docker Compose es esa pequeña casa acogedora en la que has vivido durante años, los Quadlets de Podman son como esa cabaña prefabricada, ecológica y modular en medio del bosque: resultan interesantes e innovadores, pero todavía no tienes claro cómo adaptarte a vivir en ella.

    Compose te permite definir servicios, volúmenes, redes y dependencias en un único archivo YAML que es ordenado, legible y autodocumentado. Incluso en proyectos individuales, los desarrolladores suelen quedarse con Compose simplemente para no tener que memorizar comandos interminables de Docker.

    Podman, por el contrario, se apoya de lleno en la integración con systemd. Los Quadlets son archivos de unidad de systemd que definen contenedores y pods para convertirlos en ciudadanos de primera clase en el sistema operativo. Eso es magnífico para operaciones, pero cuesta vendérselo a los desarrolladores, que solo quieren levantar un entorno y ponerse a programar de inmediato.

    Como bromeó un usuario: "Escribir archivos Quadlet es una pesadilla. Necesitas un archivo para cada contenedor, volumen, red y pod… todos en el mismo directorio. Compose simplemente funciona".

    Podman está pensado para ops, Docker para desarrolladores

    Esta división puede explicar la mayor parte de la brecha.

    Docker piensa primero en el desarrollador y asume todo el control. Configura la red, los registros y el ciclo de vida de los contenedores, ejecuta un demonio con privilegios de root y te dice: "Tranquilo, yo me encargo de todo". Para un desarrollador que no desea pelearse con cortafuegos o políticas de seguridad del sistema, eso es una victoria clara.

    Podman sitúa las operaciones en primer lugar y respeta el entorno del host. No anula las opciones de configuración de tu sistema y se integra a la perfección con SELinux y systemd. Está diseñado para encajar en el sistema en vez de adueñarse de él.

    Diagram contrasting Podman as an ops first tool that respects the host with Docker as a dev first tool that takes control and installs easily.

    Ese es el inconveniente para los usuarios ocasionales. Los desarrolladores no buscan necesariamente integrarse con protocolos de seguridad empresarial. Buscan arrancar contenedores sin fricción, comandos sencillos y una configuración mínima.

    Si no utilizas Fedora, Arch o RHEL, donde Podman viene preinstalado y cuenta con soporte completo, instalarlo y actualizarlo también puede ser tedioso. En distribuciones basadas en Debian, Podman suele estar desactualizado en los repositorios principales, y obtener versiones recientes implica superar varias trabas. Con Docker, añades un único repositorio y ya estás listo para trabajar.

    Estabilidad por encima de la ideología

    Podman cumple muchos requisitos en el plano ideológico. Funciona sin demonio y en modo rootless, evitando los riesgos de seguridad que Docker arrastra desde sus inicios más caóticos. Si te preocupa de verdad la seguridad del sistema y el aislamiento estricto de recursos, Podman resulta muy atractivo.

    Sin embargo, la mayoría de los usuarios no gestionan temas de seguridad nacional ni normativas estrictas en sus homelabs. Ejecutan Nextcloud, Plex o Home Assistant, y prefieren ver una película en streaming sin cortes a mitad de reproducción antes que pulir sus políticas de SELinux.

    Como resumió un usuario: "Docker es una roca y no he encontrado ningún motivo para cambiar".

    Conclusión

    Podman es objetivamente mejor en ciertos aspectos, con valores por defecto más seguros, integración a nivel de sistema y una arquitectura moderna. Pero el mundo real funciona tanto a base de soporte, estabilidad y simplicidad como de especificaciones técnicas.

    Por ahora, Docker sigue ganando por inercia: porque la gente lo conoce, porque funciona y porque, para la mayoría, algo suficientemente bueno basta y sobra.

    Si Podman quiere destronar de verdad a Docker, necesita algo más que ventajas teóricas. Requiere:

    • Mayor compatibilidad
    • Mejor documentación
    • Mayor soporte de la comunidad
    • Más tiempo

    En este momento, ser "mejor" sobre el papel no basta mientras Docker lleve más de una década jugando a largo plazo, y ganando.