Hasta hace poco, ejecutar cargas de Docker sobre Proxmox significaba elegir entre dos caminos conocidos: una VM dedicada con el motor Docker dentro —la opción limpia y bien aislada— o el demonio Docker anidado dentro de un LXC con nesting=1, popular por densidad pero con sus aristas. Ambos siguen siendo válidos. Pero desde Proxmox VE 9.1 (noviembre de 2025), y ya plenamente disponible en la 9.2 que es la versión actual, hay un tercer camino que cambia el planteamiento: descargar una imagen OCI directamente de un registro y ejecutarla como un contenedor nativo, sin VM y sin demonio Docker de por medio.
Conviene entender bien qué es y qué no es, porque es fácil confundirlo con “meter Docker en un LXC”. No es eso. Es otra cosa, y para algunos casos es mejor.
OCI (Open Container Initiative) es el formato estándar de imagen de contenedor: lo mismo que empaqueta y distribuye Docker Hub, GHCR, Amazon ECR o cualquier registro compatible. Lo que Proxmox VE incorpora es la capacidad de tirar de ese formato directamente y convertirlo en una plantilla de contenedor LXC utilizable.
El flujo, desde la interfaz web, es deliberadamente simple. En el almacenamiento del nodo aparece la opción “Pull from OCI Registry” (pestaña de imágenes OCI / plantillas CT). Introduces la referencia de la imagen —por ejemplo docker.io/library/caddy o simplemente caddy, y Proxmox asume Docker Hub por defecto—, consultas las etiquetas disponibles, eliges la versión y la descargas. Proxmox baja las capas de la imagen y las fusiona en un único sistema de ficheros raíz, dejándolo como una plantilla a partir de la cual creas el contenedor con el asistente habitual de “Create CT”.
El resultado es un contenedor LXC corriente, gestionado con las mismas herramientas de siempre (pct, snapshots, backups, migración, cuotas de CPU y memoria), pero cuyo contenido viene del ecosistema de imágenes de contenedor en lugar de las plantillas de sistema clásicas de Proxmox. Sin segunda capa de hipervisor, sin un Ubuntu mínimo arrancado solo para hospedar un demonio, sin VM.
Aquí está el matiz importante, y es donde el marketing simplista lleva a error. Según la imagen, Proxmox provisiona una de dos cosas:
Las application containers están en technology preview, tanto en la 9.1 que las estrenó como en la 9.2 actual. Eso no es un detalle menor: significa que es una capacidad funcional y muy prometedora, pero que Proxmox aún está puliendo y que conviene tratar con cabeza en producción.
Hay una consecuencia directa de cómo funciona el mecanismo, y es la que decide si esto encaja con tu flujo de trabajo: no hay actualización in situ.
Cuando Proxmox crea el contenedor, fusiona todas las capas de la imagen en un solo sistema de ficheros raíz. Ese aplanamiento es justo lo que rompe el modelo de capas de OCI, que es el que permite a Docker hacer un docker pull y aplicar solo la diferencia. Aquí no: para llevar un contenedor a una versión nueva de la imagen, descargas la imagen actualizada y recreas el contenedor. No actualizas el que ya tienes en marcha.
Esto cambia cómo tienes que diseñar el despliegue:
-v de Docker, configurado en la pestaña de discos), de modo que recrear el contenedor para actualizarlo no se lleve por delante tus datos.pct enter <vmid>.docker run. Es de las cosas que el estado de preview explica.Ninguna de estas es un defecto fatal. Son las consecuencias lógicas de una primera iteración, y conviene conocerlas antes de apoyar un servicio crítico encima.
Merece la pena dejarlo claro porque circula mucha confusión. La novedad de Proxmox no consiste en ejecutar el demonio de Docker dentro de un contenedor con nesting. Es ejecutar la imagen directamente como contenedor, traduciéndola a la pila LXC. No hay dockerd corriendo, no hay socket de Docker, no hay docker compose.
¿Y cuándo quieres entonces el método clásico de Docker dentro de una VM o un LXC con nesting=1? Cuando necesitas la semántica completa de Docker: pilas de docker compose con varios servicios entrelazados, redes definidas por Docker, actualizaciones frecuentes con pull incremental, o cualquier tooling que hable con el socket de Docker. Para eso, el motor Docker en una VM dedicada sigue siendo hoy la opción pragmática, y la más aislada.
La novedad OCI brilla en el caso contrario: un servicio, una imagen, que quieres correr con la mínima sobrecarga y gestionar con las herramientas de Proxmox que ya usas para todo lo demás.
| Factor | App container OCI (PVE 9.2) | LXC clásico con Docker (nesting=1) | VM con motor Docker |
|---|---|---|---|
| Qué ejecuta | La imagen como contenedor LXC | El demonio Docker dentro del LXC | El demonio Docker dentro de la VM |
| Aislamiento | Contenedor (kernel compartido) | Contenedor (kernel compartido) | Completo (kernel propio) |
| Sobrecarga | Mínima | Baja | Moderada (capa de hipervisor) |
docker compose / socket | No | Sí | Sí |
| Actualizar | Recrear el contenedor | docker pull incremental | docker pull incremental |
| Madurez | Technology preview | Estable | Estable |
| Encaje ideal | Un servicio por imagen | Stacks Docker densos | Cargas que exigen aislamiento fuerte |
La conclusión honesta: la VM con Docker sigue siendo la elección más segura cuando necesitas aislamiento real —bases de datos, cargas con requisitos de kernel distintos, o cualquier cosa donde una fuga de contenedor sería un problema serio. El contenedor OCI nativo es la opción elegante cuando lo que quieres es desplegar un servicio del ecosistema de imágenes con la mínima ceremonia y operarlo como un invitado más de Proxmox.
En los cloud privados que operamos sobre Proxmox, la sobrecarga importa. Levantar una VM Ubuntu o Debian completa solo para hospedar un único contenedor siempre fue un peaje que se pagaba a regañadientes: 200 MB o más de RAM en reposo, un sistema operativo invitado que parchear, un arranque de decenas de segundos. El contenedor OCI nativo recorta ese peaje a la sobrecarga de un LXC, manteniendo la procedencia estándar de la imagen y la gestión unificada de Proxmox.
Para homelabs y equipos pequeños, eso es densidad real sin renunciar a backups con Proxmox Backup Server, snapshots o alta disponibilidad. Y encaja con cómo vemos evolucionar la plataforma: Proxmox no está copiando a Docker, está integrando el formato de Docker en su propia pila de contenedores, que es una decisión de ingeniería distinta y, a nuestro juicio, más coherente con el resto del producto.
La recomendación práctica, mientras sea technology preview: pruébalo en un servicio sin estado o de bajo riesgo, separa los datos en volúmenes desde el primer día, y reserva las cargas críticas para cuando la funcionalidad madure o para una VM con Docker si necesitas la semántica completa. La dirección es la correcta; el momento de apoyar producción encima es cosa de cada quien.
¿Puedo ejecutar imágenes de Docker Hub directamente en Proxmox VE 9.2? Sí. Desde la interfaz web, “Pull from OCI Registry” descarga la imagen de Docker Hub (u otro registro OCI como GHCR o ECR) y la convierte en una plantilla con la que creas un contenedor LXC. No necesitas instalar el motor Docker.
¿Es lo mismo que ejecutar el demonio Docker dentro de un LXC?
No. No hay dockerd ni socket de Docker: la imagen se traduce a un contenedor LXC y se ejecuta directamente. Si necesitas docker compose o el socket de Docker, sigue usando el motor Docker en una VM o en un LXC con nesting=1.
¿Cómo actualizo un contenedor creado desde una imagen OCI? Descargas la imagen actualizada y recreas el contenedor; no hay actualización in situ porque las capas se fusionan en un único sistema de ficheros. Por eso conviene mantener los datos en volúmenes separados.
¿Está listo para producción? Las application containers OCI son technology preview en la 9.1 y la 9.2. Funcionan, pero Proxmox las sigue puliendo. Para cargas críticas, espera a que maduren o usa una VM con Docker.
¿Qué diferencia hay entre system container y application container? El system container es un LXC completo con init (systemd) y árbol de procesos; el application container es ligero y orientado a un único servicio, con red gestionada por el host. El segundo es la novedad en preview.
Fuentes oficiales: Proxmox VE 9.1 — nota de lanzamiento, Proxmox VE 9.2 — nota de lanzamiento y la documentación de Linux Container (pct).
Proxmox VE 9.2 estrena versión oficial para ARM64 (AArch64), la primera fuera de x86-64 en la historia del producto. Misma base de código, mismos repositorios y mismo soporte, con NVIDIA Grace y NVIDIA Vera como plataformas certificadas de salida. Repasamos qué hardware cumple los requisitos, qué funciones se quedan en x86 y qué cambia (poco, de momento) para quien ya tiene un clúster en producción.
Haces backup de la VM cada noche y duermes tranquilo. Hasta que restauras y la base de datos arranca corrupta o pierde las últimas transacciones. Un snapshot de disco no es lo mismo que un backup consistente de una base de datos. Explicamos la diferencia entre backup consistente por caída, por sistema de ficheros y por aplicación, y cómo conseguir el bueno en Proxmox con el agente invitado, hooks y volcados nativos.
Una red IP enrutada abajo, los servicios de cada cliente encapsulados arriba y BGP distribuyendo dónde está cada MAC. Qué resuelve EVPN-VXLAN, cómo encajan underlay y overlay, qué detalles rompen un fabric (la MTU, siempre la MTU) y cuándo no compensa montarlo.