Proxmox LXC frente a VM y Docker en 2026: qué conviene usar en cada caso

Cada cierto tiempo, la misma discusión resurge en la comunidad de Proxmox. Alguien plantea una pregunta honesta y práctica: ¿por qué no ejecutar simplemente Docker dentro de un contenedor LXC? Funciona, es rápido, consume menos memoria y muchísima gente lleva haciéndolo durante años sin el menor tropiezo.

Y enseguida llegan las réplicas de rigor: «No está soportado». «Usa una VM». «Se te va a romper en la próxima actualización». «Meter contenedores dentro de contenedores es buscarse problemas».

Avanzamos hasta 2026 y aquí seguimos, debatiendo lo mismo, desplegando lo mismo y saltándonos las reglas recomendadas en homelabs y servidores perimetrales de medio mundo. Incluso con nuevas funciones y una postura oficial algo más flexible por parte de Proxmox VE, la controversia sobre Docker en LXC se niega a desaparecer.

No es que la gente sea tozuda. Los compromisos técnicos son reales y las motivaciones de ambas partes siguen plenamente vigentes.

Dos plataformas, un kernel y cero paciencia mutua

El debate se resume en una tensión arquitectónica evidente. Proxmox es una plataforma de virtualización. Docker también lo es, solo que a un nivel diferente. Y ambas dependen estrechamente del kernel de Linux para llevar a cabo su trabajo.

Un contenedor LXC en Proxmox comparte el kernel del anfitrión, y los contenedores de Docker también esperan interactuar directamente con el kernel del sistema. Al instalar Docker dentro de un LXC, estás superponiendo dos soluciones que asumen estar en contacto directo con el núcleo.

La mayor parte del tiempo Linux es lo bastante flexible para que el invento funcione, hasta que un buen día deja de hacerlo.

Las actualizaciones del kernel, los ajustes en los perfiles de AppArmor, las transiciones de versión en cgroups o los retoques en controladores de almacenamiento no son casos aislados. Forman parte del mantenimiento rutinario para conservar un servidor seguro y al día. Cuando algo cambia en la base de Proxmox, a Docker ni le va ni le viene que esté corriendo dentro de un LXC. Del mismo modo, Proxmox no valida sus parches contra instancias de Docker anidadas en contenedores que oficialmente no respalda, y es en esa brecha donde nacen las historias para no dormir.

«Pero llevo años ejecutando Docker en LXC»

Escucharás este argumento a menudo, y normalmente es verdad.

Muchos usuarios llevan cinco, seis o hasta siete años corriendo Docker en contenedores LXC no privilegiados. Algunos han encadenado actualizaciones mayores de Proxmox sin un solo percance. Su conclusión parece obvia: el riesgo está exagerado.

El matiz está en que el éxito en este terreno no se reparte de forma equitativa. Si tus cargas son ligeras, tu almacenamiento es sencillo y no recurres a funciones rebuscadas del kernel, Docker en LXC puede parecer una roca. Pero en cuanto exiges passthrough de GPU, configuraciones avanzadas de red o controladores de disco en la frontera entre kernel y espacio de usuario, empiezan a asomar las grietas.

Esa falta de previsibilidad explica por qué Proxmox insiste en el mismo consejo. A muchos les funciona, pero cuando falla, lo hace de modos que Proxmox difícilmente puede diagnosticar o respaldar.

Escenario uno: «Solo LXC, nada de Docker»

La alternativa menos conflictiva es también la menos popular hoy en día: contenedores LXC puros, paquetes tradicionales del sistema, servicios administrados por systemd y quizás algo de automatización con Ansible.

Desde la óptica de Proxmox, este es el camino ideal. Los contenedores LXC son ciudadanos de primera clase, están probados y documentados, y las actualizaciones del kernel están pensadas para convivir con ellos sin problemas.

El inconveniente salta a la vista si llevas la última década viviendo en el universo de los contenedores. Muchas aplicaciones actuales ya no se distribuyen como software tradicional: llegan directamente como imágenes de Docker, sin repositorios apt ni guías claras de instalación, tan solo un archivo compose y un deseo de que todo encaje.

Reconstruir esas aplicaciones a mano en un sistema operativo limpio no es imposible, pero exige tiempo y mantenimiento continuo. Las dependencias evolucionan, la documentación queda obsoleta y, de repente, tu LXC minimalista se convierte en una distribución a medida que te toca mantener en solitario.

Escenario dos: Docker dentro de LXC

Este es el controvertido término medio y la razón por la que el debate no se apaga.

Sobre el papel, Docker en LXC no aporta un aislamiento superior. Ambos niveles aprovechan las mismas prestaciones del kernel: namespaces, cgroups y capabilities. No ganas más seguridad ni una velocidad apreciable. Lo que haces es duplicar la capa de abstracción. Las rutas se mapean dos veces, los puertos se redirigen por duplicado y la concordancia de identificadores UID y GID se transforma en un ejercicio de paciencia.

A pesar de todo, la gente lo sigue usando porque la comodidad es imbatible. Docker Compose es intuitivo, la documentación abunda, las copias de seguridad son directas y migrar un servicio a menudo se reduce a copiar una carpeta y levantar de nuevo el archivo compose.

El rendimiento y la seguridad son aquí preocupaciones secundarias. El riesgo auténtico es el desajuste progresivo de compatibilidad. Docker actualiza su motor, Proxmox renueva su kernel o sus perfiles de LXC y nadie se encarga de coordinar esos cambios entre ambas capas. La mayoría de las veces no explota nada. Otras veces, sí.

Y cuando algo falla, suele ser justo después de actualizar, dejándote a tu suerte.

Escenario tres: Docker en una VM

Esta es la opción sobria y predecible, y en entornos de producción lo predecible suele ganar la partida.

Una máquina virtual dispone de su propio kernel independiente, lo que mantiene satisfechos tanto a Docker como a Proxmox. Es mucho más difícil que una actualización provoque bloqueos extraños de permisos o incompatibilidades de funciones del kernel. La migración en caliente funciona, la alta disponibilidad responde y las consultas de soporte tienen sentido.

El peaje es el consumo de recursos. Incluso una VM ligera necesita memoria dedicada para su kernel, su proceso init y sus servicios en segundo plano. En un servidor potente eso apenas se nota. En un equipo modesto o en un homelab donde vigilas cada vatio, representa la diferencia entre poder alojar todos tus servicios o tener que elegir cuáles descartar.

El passthrough de GPU también se complica. Una VM suele acaparar el dispositivo salvo que lo particiones con cuidado, y no todo el mundo quiere meterse en esa complejidad.

Aun así, si la disponibilidad te importa más que exprimir hasta el último vatio, este es el esquema para el que Proxmox está verdaderamente diseñado.

Por qué las actualizaciones son el auténtico villano

Las roturas más habituales no se deben a catástrofes espectaculares, sino a detalles cotidianos. Un motor de contenedores altera la forma en que lee /proc. Un perfil de AppArmor se vuelve ligeramente más estricto. Un controlador de almacenamiento modifica su comportamiento por defecto.

Cada cambio resulta razonable por separado. Pero combinados entre capas superpuestas, pueden impedir por completo que los contenedores vuelvan a arrancar.

Por eso se repite tanto que «Docker en LXC se rompe con las actualizaciones». Lo que significa en realidad es que estás combinando dos sistemas con ritmos de desarrollo muy rápidos que no realizan pruebas cruzadas entre sí.

Si pospones las actualizaciones, mantienes buenas copias de seguridad y toleras caídas ocasionales, quizá ese riesgo te compense. Si necesitas un comportamiento intachable desde el primer minuto de una nueva versión, probablemente no sea tu mejor opción.

El comodín de las imágenes OCI

Las versiones recientes de Proxmox han incorporado soporte inicial para ejecutar imágenes OCI de forma directa, sin necesidad de levantar un demonio de Docker dentro de un LXC. Es una novedad discreta pero de enorme calado.

En lugar de anidar motores de ejecución, Proxmox toma la imagen OCI como entrada y la ejecuta directamente con su propia pila de contenedores. Eso elimina de un plumazo una capa completa de fricción: no hay socket de Docker ni runc corriendo dentro de LXC, solo Proxmox administrando el ciclo de vida del contenedor de forma nativa.

La propuesta es prometedora, aunque todavía le queda recorrido. No existe aún un sustituto maduro para Docker Compose, la orquestación es básica y las actualizaciones requieren prudencia. Hoy por hoy parece el anticipo de un futuro donde este debate por fin pierda fuerza, aunque aún no sea una base sobre la que todo el mundo pueda asentar su infraestructura.

Por qué el debate vuelve una y otra vez

Esta controversia sobrevive porque la respuesta correcta depende exclusivamente de tus prioridades.

Si valoras la eficiencia por encima de todo, los contenedores LXC, con o sin Docker, resultan increíblemente seductores. La memoria compartida es real, los arranques son inmediatos y el aprovechamiento de recursos es óptimo.

Si buscas estabilidad y soporte predecible, las máquinas virtuales ganan sin discusión. El aislamiento es limpio, el radio de impacto ante fallos es mínimo y las reglas de juego están claras.

Y si lo que buscas es rapidez y comodidad, Docker sigue siendo imbatible. Esa comodidad no se esfuma solo porque alguien te recuerde que la configuración no está oficialmente soportada.

Por eso los usuarios siguen mezclando fórmulas. Cada cual asume los riesgos que menos le preocupan e ignora los demás. Luego llega una nueva versión de Proxmox, algo cambia y la conversación vuelve a empezar de cero.

En 2026 disponemos de mejores herramientas, kernels más depurados y advertencias más claras, pero los compromisos de diseño siguen intactos.

Por esa razón el dilema nunca se cierra: según cómo gestiones tus servidores, todo el mundo tiene un poco de razón.