--- title: "Podman vs Docker: ¿qué herramienta de contenedores elegir en 2026-2027?" description: "Podman vs Docker 2026: seguridad, diseño rootless, precios y licencias, rendimiento y soporte de IA. Elige el motor de contenedores adecuado para tu stack hoy." date: 2024-07-17 categories: ["self-hosting"] tags: ["docker","podman","containers"] --- import Button from "@components/widgets/Button.astro"; import Notice from "@components/widgets/Notice.astro"; import ListCheck from "@components/widgets/ListCheck.astro"; import Accordion from "@components/widgets/Accordion.astro"; import Tabs from "@components/widgets/Tabs.astro"; import Tab from "@components/widgets/Tab.astro"; **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. - **Consistentes**: mismo comportamiento en tu portátil y en producción - **Rápidos**: arrancan en segundos - **Ligeros**: comparten el SO del host, sin necesidad de una VM completa - **Aislados**: las apps no se pisan entre sí Los contenedores usan el kernel del SO anfitrión pero mantienen todo lo demás separado. Obtienes aislamiento sin la sobrecarga de ejecutar un sistema operativo completo para cada aplicación. - **VM**: SO completo por instancia, pesadas, lentas de arrancar - **Contenedores**: SO compartido, ligeros, arranque rápido ## Podman vs Docker en 2026: qué ha cambiado **Podman 6.0** (24 de junio de 2026): versión mayor. BoltDB eliminado (solo SQLite), slirp4netns eliminado (pasta por defecto), CNI eliminado (solo Netavark), cgroups v1 eliminado, iptables eliminado, soporte para Mac Intel y Windows 10 retirado. Podman es ahora un proyecto **CNCF Sandbox**. Última versión: 6.1.0 (ago 2026). **Docker Engine 29** (10 de noviembre de 2025): el almacén de imágenes de containerd es el predeterminado en instalaciones nuevas, backend nftables experimental, cgroup v1 obsoleto, Docker Content Trust eliminado de la CLI. Último parche: 29.7.2 (5 de agosto de 2026). Docker Desktop ~4.86. **Cambio clave**: ambas herramientas convergen en cgroups v2, nftables y redes rootless. La brecha entre ellas es más estrecha que nunca, pero los modelos de licencias y seguridad siguen divergiendo. 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](/es/limpiar-docker-overlay2/) 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. - **Cliente**: escribes comandos `docker` - **Servidor**: el daemon se ejecuta en segundo plano como root (por defecto) - **Cómo funciona**: el cliente le pide al daemon que lo haga todo **Bien**: centralizado, gestiona múltiples clientes, ecosistema maduro **Mal**: siempre consume recursos, necesita root por defecto, punto único de fallo - **Sin daemon**: los comandos se ejecutan directamente mediante fork-exec - **Por comando**: cada invocación de `podman` es su propio proceso - **Resultado**: nada persistente en ejecución cuando no lo estás usando **Bien**: cero recursos en reposo, sin punto único de fallo, rootless por defecto **Mal**: algunas funciones de Docker funcionan diferente, ecosistema más pequeño ### Uso de recursos | Cuándo | Docker | Podman | |----------|--------|--------| | En reposo | ~50-100+ MB (daemon) | ~0 MB (sin daemon persistente) | | En ejecución | Daemon + contenedores | Contenedores + procesos conmon/pause de corta duración | | CPU | Siempre algo de base | Solo cuando hay comandos activos | 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. **Configuración por defecto**: - El daemon se ejecuta como root - Comprometer el daemon es comprometer el sistema - `docker cp` ha tenido históricamente bugs de escape al host **Existe el modo rootless** (desde Engine 20.10): - No es el predeterminado en servidores Linux - Requiere configuración extra (uidmap, slirp4netns/pasta) - Engine 29.5.0 convirtió gvisor-tap-vsock en el driver de red rootless predeterminado, una mejora real - Algunas funciones siguen limitadas en rootless (Swarm, ciertos modos de red) **Rootless por defecto**: - Ejecuta contenedores como usuario normal desde el primer momento - Sin proceso root persistente que explotar - Mapeo de espacios de nombres de usuario: el root del contenedor se mapea a tu usuario normal **Ventaja de arquitectura**: - Sin daemon = sin objetivo root siempre activo - Cada comando está aislado. Un contenedor comprometido no te entrega el daemon Podman es más seguro por defecto. Docker se puede reforzar con el modo rootless, pero requiere configuración extra y tiene contrapartidas. Para un operador en solitario en un VPS Linux, el modelo rootless por defecto de Podman es una cosa menos que configurar correctamente. Si ejecutas contenedores con usuarios no root dentro del contenedor (como deberías), consulta [nuestra guía para añadir usuarios a contenedores Docker](/add-users-to-docker-container/). ### 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: La familia de escapes por escritura en `/proc` de runc de 2025 (CVE-2025-31133, CVE-2025-52565, CVE-2025-52881) afectó **tanto** a Docker como a Podman. Comparten el runtime runc. Corregido en Docker Engine 28.5.2 y Podman 5.7.0. La conclusión: cuando un componente de runtime compartido tiene una vulnerabilidad, la arquitectura (daemon root frente a rootless) determina el radio de impacto. **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 No existe un benchmark único y autorizado para Docker frente a Podman en 2026. Las pruebas de la comunidad muestran que las diferencias son pequeñas a escala de un solo contenedor. Elige en función de seguridad, funciones y coste, no por diferencias de tiempo de arranque que no vas a notar. Esto es lo que sabemos realmente: | Métrica | Docker | Podman | Notas | |--------|--------|--------|-------| | Arranque | ~1-1,5 s | ~0,8-1 s | Podman gana por poco; la diferencia es insignificante para servicios de larga duración | | Velocidad de build | Rápida (BuildKit) | Comparable (Buildah) | Ambos soportan multi-etapa y caché | | Memoria en reposo | ~50-100+ MB (daemon) | ~0 MB (sin daemon) | Importa en un VPS pequeño, no en servidores ocupados | | Redes rootless | ~5-8 Gbps (gvisor-tap-vsock) | ~8-10 Gbps (pasta) | Ambos muy por delante del viejo slirp4netns (~570 Mbps) | | Uso de disco | Mayor con el almacén de imágenes containerd (predeterminado en Engine 29) | Overlay estándar | [Trampa real en discos pequeños](/es/limpiar-docker-overlay2/) | 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. Docker Desktop es **gratis** para: uso personal, educación, open source no comercial y pequeñas empresas (**menos de 250 empleados Y menos de 10 M$ de ingresos anuales**). Si superas cualquiera de los dos umbrales, necesitas una suscripción de pago. Docker Engine y la CLI son Apache-2.0 y siempre gratis: solo necesitas licencia para Desktop (la GUI + gestor de VM). ### Precios de Docker (ago 2026) | Plan | Precio | Pulls de Docker Hub | Desktop incluido | |------|-------|-----------------|-----------------| | Personal | 0 $ | 200 pulls/6 horas | Sí (límites del nivel gratuito) | | Pro | 9 $/usuario/mes (anual) | Ilimitados | Sí | | Team | 15 $/usuario/mes (anual) | Ilimitados | Sí | | Business | 24 $/usuario/mes | Ilimitados | Sí | 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](https://www.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](https://go.bitdoze.com/hetzner) u [opciones de VPS económicas como Hostinger](https://go.bitdoze.com/hostinger-vps) 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](/es/subidas-precios-vps/)._ - **¿Ejecutas contenedores en un VPS?** El motor siempre es gratis en ambas herramientas. La licencia de Docker Desktop solo importa en estaciones de trabajo. - **Consejo de CI/CD**: autentica tus pulls de Docker Hub en CI (`docker login`): los límites anónimos son más estrictos. O descarga a través de GHCR o de un [registro autoalojado](/best-self-hosted-panels/) para evitar por completo los límites de Hub. - Un **hosting VPS económico** como [Hetzner](https://go.bitdoze.com/hetzner) o [Hostinger](https://go.bitdoze.com/hostinger-vps) mantiene bajos tus costes de alojamiento de contenedores: la elección del motor no afectará a tu factura de hosting. ## 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. - Maduro, completo, estándar del sector - `docker compose up -d` simplemente funciona con la mayoría de archivos - Soporte de gestión de secretos (ver [gestión de secretos en Docker Compose](/es/secretos-docker-compose/)) - Funciona con Docker Desktop en todas las plataformas - `podman compose` puede invocar el `docker-compose` real: lo mejor de ambos mundos - podman-compose cubre los casos comunes; los archivos complejos pueden necesitar ajustes - En hosts Linux con systemd, **Quadlet** es la alternativa recomendada (ver siguiente sección) - Sin dependencia de daemon: cada invocación de compose es independiente Si tienes archivos de Docker Compose complejos con contextos de build, múltiples redes o funciones avanzadas, pruébalos con `podman compose` antes de cambiar. Usar el wrapper con el binario real de docker-compose evita la mayoría de problemas. Para servidores Linux con systemd, Quadlet suele encajar mejor que cualquiera de las dos herramientas compose. ## 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: ```ini # /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: ```bash 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`. systemd gestiona el ciclo de vida del contenedor: políticas de reinicio, ordenación de arranque, agregación de logs vía journald, sin un daemon persistente ni sobrecarga de compose. Así es como se ejecutan contenedores en producción en un VPS Linux. Docker no tiene equivalente nativo (usarías generadores de systemd de terceros o unidades systemd para compose). 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](/best-self-hosted-panels/) 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 Podman 6 no es una actualización directa desde 5.x. Elimina varios subsistemas por completo. Si ejecutas Podman 5 en servidores de producción, lee esto antes de actualizar. La actualización se parece más a pasar de Python 2 a 3 que a un parche rutinario: la superficie de la API cambió, los backends heredados desaparecieron y algunos flujos de trabajo necesitan ajuste. ### 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 - Confirma cgroups v2: `stat -fc %T /sys/fs/cgroup` debería devolver `cgroup2fs` - Detén todas las VM de `podman machine` antes de actualizar - En Hyper-V: ejecuta `podman machine reset` antes de la actualización - Busca referencias a CNI o slirp4netns en tus configuraciones - La semántica de `podman volume prune` cambió (ahora como Docker: solo volúmenes anónimos; usa `--all` para el comportamiento anterior; `--dry-run` para previsualizar) - Las VM de `podman machine` en Linux deben **recrearse** tras la actualización (los montajes de volúmenes ahora usan systemd) ### Verificación tras la actualización ```bash 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: ```bash # 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. ```bash # 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: ```bash 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 - `host.docker.internal` (Docker) frente a `host.containers.internal` (Podman): nombres de host diferentes para alcanzar el host desde dentro de un contenedor - Publicación de puertos rootless: los puertos por debajo de 1024 necesitan configuración extra (o ejecutarse como root) - Permisos de volúmenes con espacios de nombres de usuario/uidmap: los archivos creados por root dentro del contenedor pueden aparecer con un UID alto en el host - Los archivos compose con funciones avanzadas pueden necesitar ajustes para podman-compose - Audita los scripts que tengan rutas de `docker.sock` fijadas antes de cambiar 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](/es/docker-podman-entorno-seguro-ia/). ### 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. - GA desde septiembre de 2025 - LLM empaquetados como artefactos OCI en Docker Hub - Backend llama.cpp con API compatible con OpenAI (`http://localhost:1234/v1`) - Funciona en Docker Desktop (Apple Silicon, NVIDIA, ARM) y en Linux vía Docker CE - Soporte de la clave de nivel superior `models:` en Compose - Mayor productización: los modelos son artefactos Docker de primera clase - Extensión de Podman Desktop - Se distribuye con Podman Desktop: totalmente autocontenido - Podman 6.0 añadió soporte de GPU AMD a `--gpus` (antes solo NVIDIA) - Sin instalación adicional más allá de Podman Desktop - Menos productizado que el enfoque de Docker, pero sin dependencia de proveedor Ambas herramientas soportan GPU NVIDIA. Podman 6 añadió soporte de GPU AMD vía `--gpus`, lo cual es significativo si usas hardware AMD. Para inferencia local práctica, también puedes [autoalojar Ollama con Docker Compose](/es/ollama-docker-instalacion/): funciona con ambos motores. 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](/es/ollama-docker-instalacion/) 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.