Desde Proxmox VE 9.1, el propio almacenamiento de plantillas sabe descargar una imagen OCI — las mismas que usan Docker Hub, GHCR o un registro privado —, desempaquetarla con skopeo por debajo y registrarla como plantilla de contenedor. El resultado es un LXC normal y corriente, gestionado igual que cualquier otro, con el aislamiento y el arranque ligero de siempre, pero cuyo proceso principal es justo el que define la imagen — sin que haga falta levantar una VM entera solo para tener un daemon Docker dentro. Para servicios de un solo contenedor, es la diferencia entre reservar una VM completa o un LXC de unos pocos cientos de MB.
Cómo ejecutar imágenes OCI de Docker Hub directamente como LXC en Proxmox VE, sin contenedor Docker de por medio
27 de septiembre de 2026por Álvaro Fraguas Bravo
- 1
Paso 1: Localizar el storage de plantillas
En la interfaz web de Proxmox, ve a Datacenter → [tu nodo] → [tu storage] (el que tenga marcado el contenido "Container template", normalmente
local). Ahí aparece una pestaña nueva, CT Templates, junto a las plantillas LXC clásicas. - 2
Paso 2: Descargar la imagen OCI
Dentro de CT Templates, pulsa Pull from OCI Registry. En el campo Reference escribe el nombre de la imagen — si no indicas un registro delante, Proxmox asume Docker Hub por defecto. Por ejemplo, para una imagen genérica de Nginx:
nginx:latest
Elige el tag (versión) que quieras y confirma. Proxmox descarga la imagen con skopeo, la desempaqueta y la registra como una plantilla de contenedor más, junto a las plantillas LXC de siempre.
- 3
Paso 3: Usar un registro distinto a Docker Hub
Para tirar de GHCR, de la galería pública de ECR o de un registro privado propio, antepón el host del registro a la referencia. Por ejemplo, para una imagen de GHCR:
ghcr.io/usuario/imagen:latest
Si el registro es privado, Proxmox pedirá credenciales antes de completar la descarga.
- 4
Paso 4: Crear el LXC a partir de la plantilla OCI
Crea un contenedor nuevo (Create CT) igual que siempre, pero elige la plantilla OCI recién descargada en vez de una plantilla LXC clásica de Debian o Ubuntu. Asigna los recursos (RAM, vCPU, disco) según lo que pida la imagen, no según lo que pediría un sistema operativo completo — aquí solo corre el proceso de la imagen, no una distro entera encima.
- 5
Paso 5: Verificar que el proceso corre como PID 1
Arranca el LXC y entra por consola o SSH. El proceso que define la imagen OCI (el ENTRYPOINT/CMD original) tiene que estar corriendo como PID 1 del contenedor — no dentro de un Docker anidado, porque aquí el runtime es LXC de principio a fin:
ps -ef | head -5
- 6
Paso 6: Qué imágenes no van a funcionar igual
No todas las imágenes OCI están pensadas para correr fuera de un daemon Docker. Las que dependen de montar
/var/run/docker.sock, de variables de entorno inyectadas por Docker Compose, o de funcionalidades que solo ofrece el propio daemon (ciertos modos de red, o --privileged con capacidades concretas), pueden no arrancar igual dentro de un LXC. Conviene revisar el Dockerfile o la documentación de la imagen antes de dar por hecho que va a funcionar sin retoques.
Conclusión
Para comprobar que la migración es real y no solo aparente, reinicia el nodo (o al menos el LXC) y confirma que el servicio vuelve a arrancar solo, sin intervención manual. Compara además el consumo de RAM en reposo frente a la misma imagen corriendo dentro de Docker sobre una VM: esa diferencia es la que justifica no reservar una VM completa para un solo contenedor.
