Si llevas tiempo en esto de los contenedores, sabes que la pregunta ya no es «¿contenedores sí o no?» sino «¿cuál de los tres?». LXC, Docker y Podman resuelven problemas distintos con filosofías distintas, y elegir mal cuesta caro: o te quedas corto de aislamiento, o pagas una complejidad que no necesitas.
En esta guía comparo los tres desde la trinchera — no desde el marketing — y cierro con una tabla de decisión que puedes aplicar mañana mismo.
El malentendido de partida
Los tres usan las mismas primitivas del kernel: namespaces para aislar lo que el proceso ve, y cgroups para limitar lo que consume. La diferencia no está en la tecnología de base, sino en cuánto aíslas y quién orquesta el ciclo de vida.
- LXC aísla un sistema completo: tiene su propio init, sus servicios, su gestor de paquetes. Es una máquina virtual «de mentira».
- Docker aísla un proceso: una imagen, un entrypoint, un contenedor efímero. Trae daemon centralizado y una experiencia de desarrollo muy pulida.
- Podman aísla igual que Docker pero sin daemon: cada contenedor es un proceso hijo del usuario, compatible con OCI y con pods.
LXC: el sistema operativo completo
LXC arranca un /sbin/init dentro del contenedor. Eso significa que dentro corre systemd, cron, sshd y todo lo que esperarías de un servidor. Desde fuera lo administras casi como una VM: entras por consola, instalas paquetes, reinicias servicios.
# Crear un contenedor Debian con LXC
sudo lxc-create -n web01 -t download -- -d debian -r bookworm -a amd64
# Arrancarlo y entrar
sudo lxc-start -n web01 -d
sudo lxc-attach -n web01
# Límites de recursos
sudo lxc-cgroup -n web01 memory.max 2G
sudo lxc-cgroup -n web01 cpu.max "50000 100000"Cuándo gana: cuando necesitas un servidor entero con bajo consumo. Un LXC con Debian ocupa ~80 MB de RAM en reposo frente a ~400 MB de una VM equivalente, y arranca en menos de un segundo. En Proxmox VE es la opción por defecto para servicios ligeros.
Cuándo pierde: si necesitas portabilidad entre entornos, versionado de imágenes o despliegues inmutables. LXC no está pensado para eso.
Docker: el estándar de facto
Docker popularizó los contenedores porque resolvió la parte aburrida: construir imágenes reproducibles, distribuirlas en un registro y arrancarlas con un comando. Su arquitectura es cliente-servidor: el CLI habla con dockerd, que corre como root y gestiona todos los contenedores de la máquina.
# Construir y ejecutar
docker build -t miapp:1.0 .
docker run -d --name web -p 8080:80 --memory 512m miapp:1.0
# Ver consumo real
docker stats --no-streamCuándo gana: desarrollo local, CI/CD, equipos grandes, ecosistema enorme de imágenes oficiales y herramientas de terceros (Compose, Swarm, integraciones con Kubernetes).
Cuándo pierde: el daemon es un proceso root permanente escuchando en un socket. Es un blanco apetecible y una dependencia que, si se cae, se lleva todo por delante. En servidores de escritorio o entornos multiusuario, eso pesa.
Podman: Docker sin daemon
Podman ejecuta contenedores como procesos del usuario que los lanza, sin servicio central. Es compatible con las imágenes OCI, así que podman run nginx funciona igual que docker run nginx. La diferencia está debajo: no hay socket que atacar, y puedes correr contenedores rootless de verdad.
# Igual que Docker, pero sin daemon
podman run -d --name web -p 8080:80 nginx:alpine
# Un pod (varios contenedores que comparten red)
podman pod create --name mipod -p 8080:80
podman run -d --pod mipod nginx:alpine
podman run -d --pod mipod redis:7
# Generar una unidad systemd a partir del contenedor
podman generate systemd --new --name web > ~/.config/systemd/user/web.service
systemctl --user enable --now web.serviceCuándo gana: servidores donde no quieres un daemon root; entornos donde Docker está prohibido por política; quien quiere integración nativa con systemd; y quien quiere probar el modelo de pods antes de saltar a Kubernetes.
Cuándo pierde: algunas herramientas del ecosistema asumen el socket de Docker. Hay un shim (podman-docker) que lo emula, pero no es perfecto. Y en macOS/Windows la experiencia no es tan fluida como Docker Desktop.
Comparación directa
| Criterio | LXC | Docker | Podman |
|---|---|---|---|
| Qué aísla | Sistema completo | Un proceso | Un proceso |
| Init propio | Sí (systemd) | No | No |
| Daemon | No | Sí (root) | No |
| Rootless | Parcial | Limitado | Nativo |
| Imágenes OCI | No | Sí | Sí |
| RAM en reposo | ~80 MB | ~20 MB + daemon | ~20 MB |
| Arranque | < 1 s | ~1 s | ~1 s |
| systemd nativo | Sí | No | Sí (generate systemd) |
| Curva de aprendizaje | Media | Baja | Baja si sabes Docker |
Cómo decidir en 30 segundos
- ¿Necesitas un servidor completo con varios servicios dentro y quieres olvidarte de imágenes? → LXC.
- ¿Estás en desarrollo, CI/CD o necesitas el ecosistema y las imágenes oficiales? → Docker.
- ¿Es un servidor de producción y no quieres un daemon root? → Podman.
- ¿Vas a migrar después a Kubernetes? → Podman con pods. El modelo mental te prepara.
- ¿Todo corre en Proxmox VE y quieres eficiencia? → LXC, que ya viene integrado.
Migrar de Docker a Podman sin drama
La migración real es más sencilla de lo que parece porque comparten formato de imagen y sintaxis de CLI. El truco está en tres puntos:
- Alias temporal:
alias docker=podmanpara validar que tus comandos funcionan. - Docker Compose: usa
podman-composeodocker-composeapuntando al socket de Podman. Para proyectos simples funciona sin cambios. - Persistencia: reemplaza
--restart=alwayspor unidades systemd generadas conpodman generate systemd. Es más robusto y sobrevive a reinicios sin daemon.
Lo que nadie te dice
Los tres conviven perfectamente en la misma máquina. No tienes que elegir uno para siempre: puedes tener LXC para tus servicios de infraestructura, Podman para aplicaciones modernas y Docker para ese proyecto heredado que nadie quiere tocar. La decisión acertada no es ideológica, es por carga de trabajo.
Y si algo he aprendido administrando esto a diario: el contenedor más seguro es el que tiene menos piezas. Un LXC con systemd y fail2ban puede ser más robusto que un stack de seis contenedores con tres daemons, si el problema que resuelves es «necesito un servidor web».
En las próximas entregas de esta serie veremos cómo gestionar LXC desde Proxmox VE, cómo dar el salto a LXD/Incus y cómo respaldar contenedores sin perder datos ni dormir mal.
