Podman vs Docker: ¿qué herramienta de contenedores elegir en 2026-2027?

Podman vs Docker es la decisión de contenedores a la que se enfrentan la mayoría de quienes autoalojan en 2026. Ambos ejecutan imágenes OCI, pero difieren en arquitectura, seguridad y ahora también en coste. Podman 6 (junio de 2026) abandonó las pilas de red heredadas e hizo del modo rootless el único camino. Docker Engine 29 (noviembre de 2025) convirtió el almacén de imágenes de containerd en el predeterminado para instalaciones nuevas. Esta guía analiza qué ha cambiado, qué significa para tus servidores y cuándo elegir cada uno.

¿Qué son los contenedores?

Los contenedores empaquetan tu aplicación con todo lo que necesita: código, runtime, librerías y configuración. Todo viaja junto y se ejecuta igual donde lo despliegues.

Podman vs Docker en 2026: qué ha cambiado

Ambas herramientas se mantienen activamente y publican versiones con regularidad. Los mayores cambios desde mediados de 2025:

• La gobernanza CNCF de Podman: Red Hat donó Podman Container Tools y Podman Desktop al CNCF Sandbox en enero de 2025 (anunciado en KubeCon NA 2024). La organización de GitHub es ahora podman-container-tools. Esto importa para la neutralidad a largo plazo. Podman ya no es solo un proyecto de Red Hat. El repositorio tiene ~32,7k estrellas en GitHub.
• El almacén de imágenes containerd de Docker: Engine 29 lo convirtió en el predeterminado en instalaciones nuevas. Usa el modelo de snapshots de containerd en lugar del driver de grafo heredado. Las instalaciones actualizadas conservan el driver heredado a menos que lo actives. La contrapartida: mejor compatibilidad con ecosistemas basados en containerd, pero potencialmente más uso de disco que overlay2 para conjuntos de imágenes idénticos. Moby (el proyecto upstream) tiene ~72k estrellas en GitHub.
• Las redes rootless maduraron: Podman eliminó slirp4netns por completo en 6.0 (pasta es el predeterminado, ofreciendo ~8-10 Gbps frente a los ~570 Mbps de slirp4netns). Docker Engine 29.5.0 convirtió gvisor-tap-vsock en el driver de red rootless predeterminado. El viejo peaje de «rootless es lento» ha desaparecido en gran parte.
• cgroups v1 en vías de extinción: Podman 6 eliminó el soporte de cgroups v1 por completo. Docker Engine 29 lo marcó como obsoleto (soporte al menos hasta mayo de 2029). Si aún ejecutas cgroups v1, es hora de planificar la migración.
• Docker Content Trust eliminado de la CLI: Engine 29 quitó las banderas content-trust de la CLI. La firma de imágenes se gestiona ahora mediante otros mecanismos (atestaciones de BuildKit).

Docker vs Podman: diferencias de arquitectura

Esta es la diferencia fundamental entre las dos herramientas.

Uso de recursos

Las cifras anteriores son aproximaciones. La sobrecarga del daemon de Docker se amortiza entre muchos contenedores en un servidor ocupado. Si ejecutas 50 contenedores, el coste del daemon es ruido. En un portátil o un VPS pequeño con dos o tres contenedores, el modelo de cero consumo en reposo de Podman ahorra memoria real.

Por qué importa la arquitectura más allá de los recursos

La distinción daemon frente a sin daemon no es solo cuestión de memoria. Afecta a:

• Comportamiento de arranque: el daemon de Docker debe estar en ejecución antes de que funcione cualquier comando de contenedor. Si el daemon se cae, toda la gestión de contenedores se detiene. Los comandos de Podman son independientes; que uno falle no afecta a los demás.
• Actualizaciones del sistema: actualizar Docker requiere reiniciar el daemon, lo que interrumpe brevemente toda la gestión de contenedores. Las actualizaciones de Podman son simples reemplazos de binarios. No hace falta reiniciar ningún servicio.
• Acceso root: el daemon de Docker necesita root por defecto. Esto significa que cualquier usuario que pueda ejecutar comandos docker tiene efectivamente root en el host (a través del socket). El modelo rootless de Podman hace que gestionar contenedores no requiera root en absoluto.

Seguridad: contenedores rootless y superficie de ataque

Podman gana en seguridad por defecto. Te explicamos por qué, y dónde ha remontado Docker.

El problema central es la arquitectura de daemon de Docker. El proceso dockerd se ejecuta como root por defecto y escucha en un socket Unix (/var/run/docker.sock). Cualquier proceso que pueda acceder a ese socket tiene control efectivo de root sobre el host. Por eso las guías de seguridad te dicen que nunca montes el socket de Docker dentro de contenedores. Es equivalente a darle root del host al contenedor.

Podman no tiene daemon. Cada comando podman es un proceso independiente que hace fork, ejecuta el contenedor y termina. No hay ningún proceso root persistente al que atacar.

Si ejecutas contenedores con usuarios no root dentro del contenedor (como deberías), consulta nuestra guía para añadir usuarios a contenedores Docker.

Ejemplos modernos de CVE

El viejo ejemplo de referencia era CVE-2019-5736 (escape de contenedor runc). Sigue siendo historia relevante, pero 2025-2026 produjo mejores ejemplos:

Problemas de Docker específicos de 2026: bugs de escape de docker cp (CVE-2026-41567/41568/42306, ejecución de código como root en el host mediante descompresión de archivos), problema de seccomp AF_ALG (CVE-2026-31431) y una serie de CVE de Docker Desktop que incluyen vulnerabilidades de Model Runner (CVE-2026-28400, CVE-2026-33990, CVE-2026-5817/5843).

Problemas de Podman específicos de 2026: CVE-2026-57231 de fuga de entorno (entradas Env malformadas filtran variables del host), escape de ADD/COPY en builds CVE-2026-44517 y el bug de truncado de Quadlet CVE-2026-19730 (corregido en 6.1.0).

Ambas herramientas tienen CVE. La diferencia: la arquitectura sin daemon y rootless por defecto de Podman limita lo que un atacante puede alcanzar. Un escape de contenedor en Podman te deja en un espacio de nombres de usuario, no como root en el host.

Qué significa esto en la práctica

Para un operador en solitario que ejecuta contenedores en un VPS, el modelo de seguridad importa más que cualquier CVE individual. Los CVE se parchean. La arquitectura permanece.

Con la configuración por defecto de Docker, un escape de contenedor le da al atacante root en el host porque el daemon se ejecuta como root. Con el modelo rootless de Podman, un escape de contenedor le da al atacante acceso a un espacio de nombres de usuario. Sigue siendo malo, pero significativamente menos malo que root en el host.

El modo rootless de Docker cierra esta brecha, pero no es el predeterminado y requiere configuración extra (uidmap, configuración de red, algunas funciones desactivadas). Si estás dispuesto a hacer el trabajo, Docker rootless es una opción real. Si quieres valores seguros por defecto sin configuración, Podman es la respuesta.

Rendimiento: qué dicen realmente los benchmarks

Esto es lo que sabemos realmente:

Las cifras de redes rootless son estimaciones de pruebas de la comunidad (sanj.dev, junio de 2026; discusiones en r/podman), no benchmarks de laboratorio. Tus resultados variarán según el hardware y la carga de trabajo.

El único punto de rendimiento que realmente importa a los operadores: el almacén de imágenes containerd de Docker Engine 29 puede usar más disco que overlay2 para las mismas imágenes. En un disco raíz de VPS de 40 GB, es algo a vigilar.

Velocidad de build

Ambas herramientas construyen imágenes lo bastante rápido como para que no notes la diferencia en el trabajo diario. Docker usa BuildKit (integrado en el daemon desde Engine 23). Podman usa Buildah (independiente, sin daemon). Ambos soportan builds multi-etapa, caché de capas y etapas de build paralelas.

Dónde importa la velocidad de build: pipelines de CI que construyen imágenes grandes con muchas capas. En la práctica, el cuello de botella suele ser la E/S de red (descargar imágenes base) o el tiempo de compilación, no la herramienta de build de contenedores en sí.

Densidad de contenedores

En un servidor ocupado con decenas de contenedores, la sobrecarga del daemon de Docker se amortiza hasta casi cero por contenedor. El modelo por comando de Podman hace que cada contenedor tenga un pequeño proceso conmon, pero son ligeros. A densidad alta de contenedores (más de 50), la diferencia es insignificante. La verdadera limitación es siempre la carga de la aplicación, no el runtime de contenedores.

Coste y licencias: Docker Desktop y Docker Hub

Esta es la sección que la mayoría de los artículos comparativos se saltan, y es la que más importa si pagas por algo. El modelo de licencias es la mayor diferencia entre las dos herramientas desde una perspectiva de negocio: Docker tiene uno, Podman no.

Precios de Docker (ago 2026)

Pro costaba 5 $ antes de la subida de precios de diciembre de 2024. Team pasó de 9 $ a 15 $. Los precios se mueven: verifica en docker.com/pricing antes de comprometerte.

Límites de pulls de Docker Hub: los cargos por consumo de pulls se cancelaron a partir del 1 de abril de 2025. Los planes de pago tienen pulls ilimitados. El nivel Personal gratuito tiene 200 pulls por 6 horas (la documentación dice esto; la página de precios dice «100 pulls/h»: hay una discrepancia, así que consulta la documentación). Los pulls sin autenticar están limitados a 100 por IPv4 por 6 horas.

Para quienes autoalojan un puñado de contenedores, estos límites rara vez son un problema. Donde se notan: pipelines de CI que descargan imágenes con frecuencia, o equipos que ejecutan muchos servicios que se reinician a menudo. La solución es simple: autentica tus pulls (duplica tu límite) o usa un espejo a través de GHCR o un registro autoalojado.

Docker también ofrece Docker Hardened Images (DHI): imágenes base mínimas con casi cero CVE, SBOM y procedencia SLSA L3. El nivel gratuito es útil para despliegues conscientes de la seguridad; el nivel Select de pago empieza en 5k $/repo (solo empresas).

Podman: totalmente open source (Apache-2.0), proyecto CNCF Sandbox, sin restricciones de licencia. Úsalo como quieras. Sin precios por asiento, sin umbrales de ingresos, sin límites de pulls. Si ejecutas contenedores en un VPS, el único coste es el propio servidor: un hosting VPS asequible como Hetzner u opciones de VPS económicas como Hostinger lo mantienen por debajo de 5 €/mes para una configuración pequeña.

Los precios de los VPS subieron en todo el mercado en 2026: si estás replanteándote un servidor alquilado, mira qué cambió y cuándo gana un mini PC.

Compose: Docker Compose frente a Podman Compose

Docker Compose es el estándar del sector para definir aplicaciones multi-contenedor. Es maduro, está bien documentado y está en todas partes. Si ejecutas varios servicios que necesitan comunicarse entre sí (app web + base de datos + caché + proxy inverso), Docker Compose es cómo la mayoría define ese stack.

La historia de compose en Podman ha mejorado. podman compose es ahora un wrapper que puede invocar el binario real de docker-compose (si está instalado) o recurrir a podman-compose (una reimplementación en Python). El proyecto podman-compose sigue las funciones de Docker Compose mediante una hoja de compatibilidad: los casos comunes funcionan, los casos límite pueden necesitar ajustes.

El consejo práctico: si estás en un servidor Linux con systemd, plantéate si necesitas compose en absoluto. Quadlet (cubierto en la siguiente sección) te da gestión de contenedores nativa de systemd sin la capa de compose. Para estaciones de trabajo de desarrollo, Docker Compose sigue siendo el camino de menor resistencia.

Podman Quadlet: contenedores como servicios systemd

Esta es la función que convierte a Podman en la elección correcta para servidores Linux autoalojados. Quadlet te permite definir contenedores como archivos de unidad de systemd: systemd gestiona el ciclo de vida (arranque, parada, reinicio al boot, logging) sin necesitar el daemon de Docker ni compose.

Si alguna vez has escrito un archivo de servicio de systemd, ya sabes cómo funciona Quadlet. Defines un archivo .container, systemd lo recoge y lo gestionas con systemctl como cualquier otro servicio.

Aquí va un ejemplo real:

# /etc/containers/systemd/myapp.container
[Unit]
Description=My nginx app

[Container]
Image=docker.io/library/nginx:1.27
PublishPort=8080:80
Volume=myapp-data:/usr/share/nginx/html
AutoUpdate=registry

[Service]
Restart=always

[Install]
WantedBy=default.target

Luego:

systemctl daemon-reload
systemctl start myapp
systemctl status myapp    # verify it's running
journalctl -u myapp -f    # follow logs

Lista todas las unidades Quadlet con podman quadlet ls.

Novedades en Podman 6: instalación rediseñada (sigue archivos en subdirectorios), claves UID=/GID=/Options= en volúmenes, clave AppArmor e ImageVolume= en 6.1. Si ejecutas paneles de servidor autoalojados o cualquier servicio de larga duración en una máquina Linux, merece la pena aprender Quadlet.

Quadlet frente a Docker Compose en producción

Para un operador en solitario que ejecuta servicios en un VPS Linux, la elección se reduce a qué gestiona el ciclo de vida:

• Docker Compose: ejecutas docker compose up -d y esperas que siga funcionando. Para persistencia al arranque, necesitas una unidad systemd que llame a compose, o una política de reinicio en cada contenedor. Los logs van al driver de logs de Docker.
• Quadlet: systemd posee el ciclo de vida del contenedor de forma nativa. Restart=always es una directiva de systemd. Los logs van a journald. La ordenación de arranque funciona con After= y Wants=. Sin daemon, sin binario compose, sin scripts wrapper.

Si ya usas systemd para todo lo demás en tu servidor (y deberías), los contenedores Quadlet encajan perfectamente. Un systemctl status más que consultar, un journalctl -u más para seguir logs. Ninguna herramienta nueva que aprender.

Actualización: Podman 6 es una migración, no un parche

Qué eliminó Podman 6

• BoltDB: reemplazado por SQLite (la auto-migración ocurre al reiniciar desde Podman 5.8+)
• slirp4netns: reemplazado por pasta (predeterminado desde 5.0; ahora es la única opción)
• CNI: reemplazado por Netavark (predeterminado desde 4.0; ahora es la única opción)
• cgroups v1: se requiere cgroups v2
• iptables: solo nftables
• Soporte de Mac Intel: quédate en Podman 5.x si tienes un Mac Intel
• Windows 10: se requiere Windows 11

Lista de comprobación previa a la actualización

Verificación tras la actualización

podman info --format '{{.Version}} {{.Host.Security}} {{.Host.NetworkBackend}}'
# expect: 6.x, rootless, netavark

podman system check
# storage/DB integrity check

stat -fc %T /sys/fs/cgroup
# should return: cgroup2fs

Podman Desktop 1.29 (julio de 2026) soporta Podman 6 y recomienda borrar los datos en actualizaciones de 5 a 6.

Cómo es la migración en la práctica

En Fedora o RHEL, la actualización suele ser una operación del gestor de paquetes:

# Fedora
sudo dnf upgrade podman

# Check the version
podman --version
# expect: podman version 6.x.x

La migración de BoltDB a SQLite ocurre automáticamente al reiniciar si vienes de Podman 5.8+. Si estás en una versión 5.x más antigua, actualiza primero a 5.8, reinicia y luego actualiza a 6.

El mayor punto de dolor en la práctica: podman volume prune. En Podman 5, eliminaba todos los volúmenes sin usar. En 6, coincide con el comportamiento de Docker: solo volúmenes anónimos. Usa podman volume prune --all para el comportamiento anterior, y --dry-run para previsualizar qué se eliminaría.

Migrar de Docker a Podman

Si pasas de Docker a Podman en un servidor Linux, la CLI es mayormente compatible. Los comandos básicos son idénticos: run, build, ps, images, exec, logs. Las diferencias aparecen en los detalles: redes, volúmenes e integración de herramientas.

La migración suele ser directa para configuraciones simples. Para entornos complejos con muchos servicios, pipelines de CI y herramientas que dependen de funciones específicas de Docker, reserva un día de pruebas.

# The simplest migration
alias docker=podman

# Test your containers
podman run -d --name test nginx
podman ps
podman logs test

Compatibilidad del socket

Muchas herramientas (Testcontainers, VS Code Dev Containers, scripts de CI) esperan un socket de Docker. Podman puede proporcionar uno:

systemctl enable --now podman.socket
# Option 1: symlink
ln -sf /var/run/podman/podman.sock /var/run/docker.sock
# Option 2: environment variable
export DOCKER_HOST=unix:///var/run/podman/podman.sock

Ojo con

Para una inmersión más profunda sobre el uso seguro de contenedores para cargas de trabajo de IA, consulta ejecutar herramientas CLI de IA de forma segura en Docker o Podman.

Compatibilidad con CI/CD

Tanto GitHub Actions como GitLab CI soportan Podman. GitHub Actions tiene jobs de contenedor de Podman, Buildah y Skopeo disponibles. Esto importa para la seguridad: con Podman no necesitas Docker-in-Docker (DinD) ni contenedores privilegiados en CI: cada paso de build se ejecuta como un proceso independiente. Sin daemon dentro de daemon, sin modo privilegiado, sin exposición del socket de Docker en tu pipeline.

Si ejecutas GitLab CI con Docker, el enfoque estándar usa un contenedor DinD privilegiado. Con Podman, puedes ejecutar builds rootless sin modo privilegiado. La contrapartida: necesitas configurar Podman en tu runner de CI, lo que añade configuración. Para la mayoría de equipos, Docker en CI ya funciona y el coste de migración no merece la pena a menos que la seguridad sea un requisito estricto.

Cargas de trabajo de IA: Docker Model Runner frente a Podman AI Lab

Ambas herramientas soportan ahora ejecutar modelos de IA localmente en contenedores, pero con enfoques diferentes. Es un área que avanza rápido: tanto Docker como Podman lanzaron funciones importantes de IA en 2025-2026, y el panorama seguirá cambiando. Si estás evaluando contenedores para cargas de trabajo de IA, la elección depende de tu hardware y de si ya estás invertido en un ecosistema.

Ambas son gratis y evolucionan rápido. Model Runner de Docker está más pulido para el flujo de trabajo «descarga un modelo, ejecútalo». Podman AI Lab es más simple si ya estás en Podman Desktop. Ninguna requiere suscripción de pago para inferencia local.

Cuál elegir para cargas de trabajo de IA

Si ejecutas LLM locales en una estación de trabajo Mac o Windows, Docker Model Runner es la opción más madura: los modelos empaquetados en OCI en Docker Hub y la API compatible con OpenAI facilitan la integración con herramientas existentes. La clave models: de Compose te permite definir modelos junto a tus servicios.

Si estás en Linux y ya usas Podman, AI Lab te da una experiencia autocontenida sin incorporar Docker Desktop. El soporte de GPU AMD en Podman 6 es un diferenciador real si usas hardware AMD: el soporte de --gpus de Docker ha sido históricamente prioritario para NVIDIA.

Para inferencia de IA en producción en un VPS, ninguna de las dos herramientas es la respuesta: usarías algo como Ollama con Docker Compose o un servidor de inferencia dedicado. Las funciones Model Runner y AI Lab son principalmente para desarrollo local y experimentación.

¿Qué herramienta de contenedores deberías elegir?

La decisión se reduce a tus prioridades: tamaño del ecosistema, valores de seguridad por defecto, coste de licencias y dónde ejecutas los contenedores.

Comandos habituales

Los comandos básicos son idénticos entre Docker y Podman. Es intencionado: Podman se construyó como reemplazo directo de la CLI de Docker.

# These work identically with docker or podman
docker run -d --name web nginx          # Background container
docker build -t myapp .                 # Build image
docker ps                               # List running containers
docker images                           # List images
docker exec -it web bash                # Shell into container
docker logs web                         # View container logs
docker compose up -d                    # Start compose stack

# Podman-specific
podman machine init                     # Create a VM (Mac/Windows)
podman machine start                    # Start the VM
podman machine stop                     # Stop the VM
podman pod create --name mypod          # Create a pod
podman pod ps                           # List pods
podman generate kube mypod > pod.yaml   # Export as Kubernetes YAML
podman quadlet ls                       # List Quadlet units
podman system check                     # Check storage integrity
podman system reset                     # Reset all Podman data (destructive)

Los comandos podman machine solo son relevantes en Mac y Windows: gestionan la VM de Linux en la que se ejecuta Podman. En Linux, Podman se ejecuta de forma nativa.

# Check Docker version and config
docker version --format '{{.Server.Version}}'
docker info --format '{{.Driver}} {{.FirewallBackend}}'

# Check Podman version and config
podman info --format '{{.Version}} {{.Host.Security}} {{.Host.NetworkBackend}}'
podman system check                     # Storage/DB integrity

Para la referencia completa de comandos, consulta más de 60 comandos de Docker que debes conocer.

Verificar tu configuración

Tras instalar o actualizar, verifica que todo funciona:

# Docker
docker version --format '{{.Server.Version}}'      # expect 29.x
docker info --format '{{.Driver}} {{.FirewallBackend}}'  # check storage driver and firewall

# Podman
podman info --format '{{.Version}} {{.Host.Security}} {{.Host.NetworkBackend}}'
# expect: 6.x, rootless, netavark
podman system check                                 # storage/DB integrity

Resolución de problemas y trampas

Estos son los problemas con los que los operadores se topan realmente en producción. No teóricos: provienen de informes de la comunidad, issues de GitHub y discusiones en foros.

{ "features": { "containerd-snapshotter": false } }

systemctl enable --now podman.socket
# Option 1: symlink (works but environment variable is cleaner)
ln -sf /var/run/podman/podman.sock /var/run/docker.sock
# Option 2: environment variable (preferred)
export DOCKER_HOST=unix:///var/run/podman/podman.sock

curl -s --unix-socket /var/run/podman/podman.sock http://localhost/_ping
# Should return: OK

systemctl daemon-reload
systemctl cat myapp.service   # verify the generated unit looks correct

Conclusión

Ambas herramientas funcionan. Ambas se mantienen activamente. Ambas ejecutan contenedores OCI. Las diferencias son reales pero no son bloqueantes: puedes lanzar software de producción con cualquiera de las dos.

Docker es la elección más segura para aprender, para desarrollo en Windows/Mac y para equipos que necesitan el mayor ecosistema. El coste de la licencia solo afecta a organizaciones grandes: para uso personal y de pequeña empresa, Docker Desktop es gratis. El ecosistema no tiene rival: cada proveedor de nube, cada sistema de CI, cada tutorial asume Docker primero.

Podman es la mejor elección para servidores Linux, despliegues conscientes de la seguridad y cualquiera que no quiera un daemon root ejecutándose 24/7. Quadlet lo hace especialmente bueno para servicios autoalojados gestionados por systemd. La gobernanza CNCF le da credibilidad a largo plazo más allá del patrocinio de Red Hat.

Yo uso Docker en mi Mac para desarrollo porque Docker Desktop es cómodo. Uso Podman en servidores Linux porque no quiero un daemon root en ejecución y Quadlet encaja en mi flujo de trabajo con systemd.

Elige lo que encaje en tu situación. Siempre puedes cambiar después: la compatibilidad OCI significa que tus contenedores funcionan en cualquiera de los dos motores. Lo importante es elegir uno, aprenderlo bien y lanzar tu software. El motor de contenedores es fontanería: a tus usuarios no les importa cuál usas.

¿Buscas aplicaciones en contenedores? Echa un vistazo a la sección de autoalojadas de toolhunt.net.