Docker vs LXC en Proxmox: cuál elegir para empezar

Esta mañana Docker decía 12 contenedores, once en marcha. También había 31 volúmenes y 50 imágenes ocupando 30,27 GB. La máquina estaba a 53 °C, templada en la tapa, y el ventilador ni se distinguía del zumbido del switch que tengo al lado. El problema no era rendimiento. Era recordar qué narices había dejado allí cuatro semanas atrás.

El culpable estaba a la vista: un n8n parado desde hace un mes, 7,133 GB de imágenes reclamables y 3,325 GB en volúmenes sin uso. Ese pequeño vertedero explica mejor Docker vs LXC en Proxmox que muchas tablas. Los dos aíslan procesos usando el kernel del host. Ninguno evita que tengas que poner orden.

Yo elegí Docker para desplegar aplicaciones. Elegiría LXC cuando necesitase administrar un Linux separado dentro de Proxmox. Si hace falta otro kernel, un dispositivo delicado o una frontera más dura, salto a una máquina virtual. No intento que una herramienta gane las tres carreras.

Lo que vi hoy en el host Docker

Tomé estas salidas el 2 de septiembre de 2026, sin parar ni limpiar nada para que el dibujo saliera más bonito:

ServerVersion=29.3.0 StorageDriver=overlay2 CgroupVersion=2 Containers=12 Running=11
volumes=31
up 2 hours, 27 minutes
temp_mC=53000

El detalle de disco fue menos fotogénico:

TYPE            TOTAL  ACTIVE  SIZE      RECLAIMABLE
Images          50     12      30.27GB   7.133GB (23%)
Containers      12     11      63.11MB   60.83MB (96%)
Local Volumes   31     6       3.458GB   3.325GB (96%)
Build Cache     68     0       2.475GB   0B

No he borrado esos gigas para presumir de una terminal verde. Antes toca averiguar qué volumen guarda algo recuperable. docker system prune tiene el tacto de una escoba industrial: útil, pero no distingue un resto olvidado de una base de datos que alguien dejó sin contenedor.

La raíz usa ext4 sobre LVM y Docker almacena las capas con overlay2. Hay seis redes locales además de bridge, host y none; algunas vienen de stacks ya retirados. Es cómodo desplegar con Compose, pero la comodidad aplaza decisiones. Los restos llegan después.

Docker empaqueta la aplicación

Docker encaja cuando quiero declarar una aplicación con su imagen, variables, volúmenes y red, y repetir ese despliegue. El ejemplo real es Immich: servidor, base de datos, Redis y aprendizaje automático forman un stack. Hoy ocupaban 793,6 MiB, 98,76 MiB, 20,35 MiB y 383,9 MiB, respectivamente, en una lectura instantánea.

La ventaja no es que «pese poco». Algunas imágenes son enormes. Lo que compro con Docker es una unidad de despliegue: puedo fijar versión, reconstruir el contenedor y conservar los datos fuera de su capa desechable. La documentación de Docker sobre contenedores insiste en esa separación entre imagen, contenedor y datos persistentes.

También me gusta Compose porque deja el servicio en un fichero revisable. Eso no lo vuelve automático. En este host conviven políticas always y unless-stopped; n8n permanece parado porque Exited (0) fue una decisión anterior, no un fallo que Docker deba curar. Si no recuerdas esa intención, el orquestador parece caprichoso cuando en realidad obedece al pie de la letra.

LXC me sirve cuando quiero un Linux separado

Un contenedor LXC en Proxmox se parece más a una máquina ligera. Tiene su userspace, paquetes, usuarios, red y ciclo de vida. Lo administras como sistema. Esa es su virtud y la factura escondida: otro apt update, otro SSH, otro fichero de configuración y otra instancia que inventariar.

Lo usaría para un servicio que espera una distribución completa, para separar responsabilidades o para una aplicación que se lleva mal con el modelo de imagen inmutable. La documentación de Proxmox Container Toolkit explica que LXC comparte el kernel del host y distingue contenedores privilegiados y no privilegiados. Un LXC no es una VM diminuta.

Hay una manía que evitaría: crear un LXC por aplicación y, dentro de cada LXC, instalar Docker. Puede servir si buscas una frontera administrativa concreta, pero como receta apila dos inventarios, dos redes y dos lugares donde perseguir permisos. El primer sábado parece ordenado. En enero ya no recuerdas qué capa expone el puerto.

La diferencia no está en una tabla de RAM

Docker y LXC comparten kernel; el consumo real depende mucho más del servicio, su caché y su base de datos que de la etiqueta pegada al contenedor. En mi lectura, el blog usaba 12,27 MiB y el aprendizaje automático de Immich 383,9 MiB. Ambos eran Docker. Convertir el segundo en LXC no haría desaparecer el modelo cargado en memoria.

La diferencia que sí noto cada mes es operativa:

• Docker me pide cuidar imágenes, Compose, secretos, redes y volúmenes.
• LXC me pide cuidar sistemas: paquetes, usuarios, plantillas, snapshots y configuración interior.
• Una VM añade kernel y firmware virtual, a cambio de una frontera más clara.

Tres líneas bastan. El error es elegir por una cifra tomada con el servicio vacío y olvidar el trabajo que habrá cuando toque restaurarlo.

Qué pondría en cada sitio

Para una aplicación mantenida como imagen, empezaría por Docker. Immich, un proxy o un panel encajan si sus datos persistentes están definidos y la copia se ha probado. La guía sobre qué merece la pena autoalojar pone el filtro antes del compose up, que es donde se ahorran más disgustos.

Para un servidor Linux que necesito tratar como unidad, usaría LXC. Un entorno con paquetes propios o un servicio heredado que espera tocar /etc son ejemplos razonables. Preferiría un contenedor no privilegiado mientras el caso no exija lo contrario.

Reservaría la VM para Windows, otro kernel, passthrough sensible o una carga cuyo compromiso no quiero compartir con el host. El comparador de mini PC para virtualización deja filtrar por RAM y núcleos antes que por el logotipo de la CPU. Y un snapshot no sustituye la regla 3-2-1 del homelab: es rápido volver atrás, pero no es una copia fuera de la máquina.

Mi elección para empezar

Si el objetivo es servir aplicaciones en casa, empezaría con Docker sobre un Linux sencillo. Un host, un Compose por stack, versiones fijadas y una libreta corta que diga dónde viven los datos. Ya da trabajo de sobra.

Si el objetivo es aprender Proxmox, levantaría un LXC no privilegiado y una VM pequeña para entender la diferencia. Después metería Docker donde haya aplicaciones, no como papel pintado dentro de cada contenedor.

Hoy mi host Docker funciona bien con once servicios levantados. Lo que necesita no es migrar a LXC por deporte. Necesita revisar siete gigas de imágenes y tres gigas de volúmenes antes de que el polvo digital tape las etiquetas. Bastante menos épico. Bastante más útil.

Mediciones ejecutadas el 2 de septiembre de 2026 en un Intel N100 de Homelabista. docker stats y docker system df son lecturas puntuales; no son benchmarks de Docker frente a LXC. No se ejecutó LXC en este host y no se atribuyen cifras propias a Proxmox.

Antes de publicar el servicio, comprueba también por qué UFW puede no bloquear un puerto de Docker y cómo verificarlo desde fuera. Elegir Docker o LXC no sustituye esa comprobación de acceso.