Hay una conversación que tengo con regularidad cuando alguien nuevo llega al mundo del homelab. Me preguntan: “¿uso Docker o mejor una VM?” Y la respuesta correcta suele ser “depende”, pero durante mucho tiempo me faltó mencionar una tercera opción que uso bastante: Incus.
Incus es un gestor de contenedores de sistema. No contenedores de aplicación como Docker, sino contenedores que ejecutan un Linux completo, con su propio systemd, sus propios procesos en background, su init, su cron. Desde dentro parece una VM normal. Desde fuera consume una fracción de los recursos.
Empiezo por el principio.
La historia, brevemente#
LXD fue el proyecto original de Canonical para dar una experiencia de usuario decente sobre LXC (Linux Containers). Funcionaba bien, pero tenía sus problemas: estaba atado a Ubuntu, el desarrollo era lento, y la comunidad no tenía mucho control sobre la dirección del proyecto.
En 2023, algunos de los contribuidores principales hicieron un fork y crearon Incus bajo el paraguas de Linux Containers. El objetivo era simple: tomar lo bueno de LXD, quitarle las dependencias innecesarias de Ubuntu, y abrir el desarrollo de verdad.
Hoy Incus está disponible en Debian, Alpine, Arch, Fedora y muchas otras distribuciones. Ya no necesitas Ubuntu para ejecutarlo. Eso para mí fue el detonante para probarlo.
Por qué usarlo en vez de Docker para según qué cosas#
No estoy diciendo que Incus reemplaza a Docker. Son herramientas distintas para problemas distintos.
Docker es genial cuando quieres ejecutar una aplicación aislada con sus dependencias. Arrancas un contenedor, hace su cosa, lo paras. Ideal para servicios web, bases de datos, aplicaciones que tienen una imagen en Docker Hub.
Incus es otra historia. Lo usas cuando quieres un entorno Linux completo pero sin el coste de una VM. Casos donde me resulta útil:
Entornos de desarrollo aislados. A veces necesito probar algo en Debian 12 que no quiero instalar en mi máquina. Con Incus lanzo un contenedor Debian, instalo lo que necesito, trasteo, y cuando termino lo borro. El contenedor arranca en menos de dos segundos.
Servicios que necesitan systemd. Hay software que simplemente no funciona bien en Docker porque espera un entorno de sistema completo. Cosas que gestionan servicios con systemd, que necesitan un journald real, que hacen cosas raras con los cgroups. En un contenedor Incus funcionan exactamente igual que en una VM.
Testing de configuraciones de red. Puedo crear múltiples contenedores con Incus, configurarles interfaces de red, conectarlos entre ellos, y simular topologías de red complejas. Todo sin salir de mi servidor principal.
Proyectos que no merecen una VM entera. Tengo un servidor con 64GB de RAM y a veces quiero alojar algo pequeño que no justifica una VM completa. Un contenedor Incus consume 50-100MB de RAM básica frente a los 512MB mínimos de una VM.
Instalación en Debian/Ubuntu#
La forma más sencilla en Debian o Ubuntu reciente es con los paquetes del repositorio oficial:
| |
Después de instalar, necesitas inicializar:
| |
El asistente te hace preguntas sobre el pool de almacenamiento (recomiendo ZFS si puedes), la red (crea un bridge por defecto), y si quieres clustering. Para empezar, las respuestas por defecto funcionan perfectamente.
También tienes que añadir tu usuario al grupo incus para no tener que usar sudo constantemente:
| |
Primeros contenedores#
Lanzar un contenedor Ubuntu 24.04:
| |
Acceder al contenedor:
| |
Ya estás dentro. Es un Ubuntu completo. Puedes instalar paquetes, configurar servicios con systemd, hacer lo que necesites. La diferencia con SSH a una VM es casi imperceptible desde dentro.
Listar los contenedores:
| |
Verás el nombre, estado, IP y recursos consumidos. Normalmente algo así:
| |
Para parar y borrar:
| |
Imágenes disponibles#
Incus tiene un repositorio de imágenes bastante completo. Para ver qué hay:
| |
Hay imágenes de Ubuntu, Debian, Alpine, Fedora, Arch, OpenSUSE, CentOS Stream y muchas más. También hay imágenes para ARM64, por si tienes Raspberry Pi o mini PCs ARM en tu homelab.
La sintaxis para las imágenes es images:distro/version o ubuntu:version para el servidor de imágenes oficial de Canonical:
| |
Gestión de red#
Por defecto, Incus crea un bridge llamado incusbr0 y los contenedores reciben IPs en ese rango privado. Pueden salir a internet a través de NAT, pero no son accesibles directamente desde tu red local.
Para que un contenedor tenga una IP de tu red local (útil si quieres acceder a él desde otros dispositivos), puedes cambiar la interfaz de red al crear el contenedor:
| |
Yo tengo configurado un perfil que asigna dos interfaces: una en la red de Incus para gestión y otra en mi red local para acceso directo. Así puedo llegar al contenedor desde cualquier dispositivo de casa sin redireccionamientos raros.
Perfiles: configuración reutilizable#
Los perfiles son una de las cosas más útiles de Incus. Básicamente son configuraciones predefinidas que puedes aplicar al crear contenedores.
Ver los perfiles disponibles:
| |
Por defecto tienes el perfil default. Puedes crear los tuyos:
| |
Y aplicarlos al lanzar contenedores:
| |
Tengo perfiles para distintos casos: uno con más CPU/RAM para builds, otro con red local para servicios que necesito accesibles, otro mínimo para experimentación.
Snapshots y backups#
Una de las ventajas sobre VMs tradicionales: los snapshots son casi instantáneos y ocupan muy poco espacio gracias a las capacidades de copy-on-write de ZFS o btrfs.
Crear un snapshot:
| |
Restaurar:
| |
Listar snapshots:
| |
Exportar un contenedor como backup:
| |
Restaurar desde backup:
| |
VMs también (sí, también)#
Incus no es solo contenedores. También puede gestionar VMs KVM con la misma interfaz de comandos. La diferencia al lanzar una VM:
| |
El flag --vm indica que quieres una VM real, no un contenedor. Desde fuera, la experiencia es idéntica: los mismos comandos de gestión, la misma interfaz, los mismos perfiles. Por dentro, es una VM completa con kernel propio.
Esto me resulta útil cuando necesito probar algo que requiere un kernel específico o cuando necesito aislamiento total. Puedo tener contenedores y VMs gestionados con la misma herramienta.
Incus vs Proxmox: ¿cuándo uso cada uno?#
Tengo Proxmox en mi cluster principal y uso Incus en algunos nodos específicos. No son excluyentes.
Proxmox es mejor cuando:
- Necesitas una interfaz web completa
- Gestionas muchas VMs de distintos tipos
- Quieres clustering con alta disponibilidad
- Necesitas migraciones en caliente
Incus es mejor cuando:
- Quieres algo ligero en un nodo pequeño (mini PC, Raspberry Pi, etc.)
- Necesitas muchos contenedores de sistema sin overhead
- Prefieres gestión por línea de comandos o API
- Quieres integración en scripts de automatización
En mi mini PC que tengo como nodo secundario uso Incus porque Proxmox solo en ese nodo sería exagerado. Arranca más rápido, consume menos recursos en idle, y para lo que necesito en ese nodo (unos cuantos contenedores de pruebas) funciona perfectamente.
La interfaz web: Incus UI#
Si prefieres no vivir en la terminal, Incus tiene una interfaz web opcional. No viene instalada por defecto, pero puedes activarla:
| |
Y acceder en https://tu-servidor:8443. La interfaz no es tan completa como la de Proxmox, pero para el día a día es suficiente: ver contenedores, arrancarlos, parar, ver logs, acceder a la consola.
Rendimiento real#
Algunos números aproximados de mi experiencia, en un servidor con procesador de 8 núcleos y 32GB de RAM:
Un contenedor Ubuntu 24.04 en idle consume alrededor de 80-120MB de RAM. Arrancar desde cero tarda entre 1 y 3 segundos. Con una VM Debian mínima en Proxmox estamos hablando de 512MB mínimo y 8-15 segundos de arranque.
En ese mismo servidor puedo tener cómodamente 20-30 contenedores Incus en activo antes de que empiece a notarse en memoria. Con VMs equivalentes, llegaría a 8-10 como mucho.
El rendimiento de CPU es prácticamente igual al bare metal porque no hay hypervisor entre el contenedor y el procesador. Para cargas de trabajo intensivas en CPU, los contenedores de sistema son más eficientes que las VMs KVM.
Lo que no te va a gustar#
Honestamente, Incus tiene sus limitaciones.
El aislamiento de seguridad es menor que el de una VM. Comparten el kernel del host. Si hay una vulnerabilidad de kernel que permite escapar del contenedor, un atacante podría afectar al host. Para servicios expuestos a internet o entornos que requieren aislamiento fuerte, prefiero VMs.
La compatibilidad de imágenes es más limitada que Docker Hub. No vas a encontrar miles de aplicaciones empaquetadas listas para usar. Tienes distribuciones Linux, y dentro montas lo que necesites. Es más trabajo que docker run nginx.
No tiene el ecosistema de Docker Compose, Portainer, ni nada parecido. Es más “primitivo” en ese sentido. La gestión es más manual.
Y si ya tienes Proxmox en tu homelab, añadir Incus encima puede ser redundante a menos que tengas un caso de uso específico.
Mi flujo típico de uso#
Cuando necesito experimentar con algo nuevo, mi flujo es: creo un contenedor con la distro que necesito, hago mis pruebas, y si funciona bien y quiero convertirlo en algo más permanente, o lo dejo como está (si es algo pequeño) o creo una VM en Proxmox para darle más formalidad.
Para proyectos temporales o entornos de CI donde necesito builds limpios, Incus es perfecto. Cada build puede arrancar desde una imagen limpia, y el tiempo de arranque de 2 segundos no afecta al pipeline.
También lo uso para aprender distribuciones que no conozco. ¿Quiero ver cómo funciona Alpine Linux por dentro? incus launch images:alpine/3.19 prueba-alpine, me meto dentro, trasteo durante una tarde, y lo borro. Sin instalaciones, sin discos que formatear.
Para empezar esta semana#
Si tienes un servidor Debian o Ubuntu en tu homelab y quieres probar Incus, la barrera de entrada es baja. La instalación lleva 10 minutos, y con los comandos básicos que he puesto puedes tener tu primer contenedor en marcha en menos de 5.
No hace falta comprometerse con nada: puedes tenerlo instalado, usarlo cuando necesites un entorno temporal, y si no te convence borrarlo y ya está. El overhead en el servidor host cuando no hay contenedores activos es mínimo.
Lo que sí te recomendaría: dale una oportunidad antes de descartar la idea porque “ya tienes Docker”. Son herramientas distintas que resuelven problemas distintos, y hay casos en los que Incus simplemente encaja mejor.