systemd-nspawn: contenedores Linux sin Docker

systemd-nspawn: contenedores Linux sin la capa de Docker

Un contenedor Alpine corriendo bajo systemd-nspawn ocupa 16 MB en disco. Un Fedora con sus paquetes base, 507 MB. La diferencia supera el orden de magnitud y resume por qué una parte del mundo del self-hosting mira esta tecnología como alternativa a Docker cuando el objetivo es aislar un servicio —por ejemplo, un LLM propio— sin arrastrar toda la maquinaria de un runtime de contenedores.

Para un founder esto no es un detalle de sysadmin. Es la diferencia entre correr tu propio modelo en un VPS económico o pagar por una instancia más grande; entre compartir la GPU del host entre varios servicios o necesitar una máquina por servicio.

¿Qué es systemd-nspawn y en qué se diferencia de Docker?

Según la guía publicada en quantum5.ca, systemd-nspawn es una tecnología de contenedores ligera basada en namespaces del kernel Linux, no muy distinta de Docker. La diferencia central está en la gestión de imágenes: en vez de describir cómo construir imágenes con Dockerfile y distribuir imágenes precompiladas de solo lectura listas para ejecutar, nspawn se usa típicamente con un sistema de archivos raíz (rootfs) escribible, lo que lo hace funcionar más parecido a una máquina virtual. Quien haya usado chroot para correr software de otra distro Linux encontrará la comparación más rápida: es un chroot con esteroides.

¿Y esto cómo se aplica en tu negocio?

En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.

👥 Probar 7 días

El autor de la guía lo usa, concretamente, para aislar sus LLM autoalojados que corren sobre Ollama y Open WebUI. Estos son los escenarios donde, según su experiencia, nspawn resulta especialmente útil:

Cuando quieres correr software con cierto grado de aislamiento en un VPS donde no puedes crear una máquina virtual completa porque no hay virtualización anidada disponible.
Cuando necesitas compartir acceso a hardware, como una GPU.
Cuando no quieres cargar con el overhead de la virtualización.
Cuando quieres acceder directamente a archivos del sistema anfitrión sin recurrir a virtiofs.
Cuando normalmente usarías Docker pero no puedes o no quieres.

Ese último punto tiene una traducción económica concreta. La propia documentación de Docker establece que el uso comercial de Docker Desktop en empresas con más de 250 empleados o más de US$10M de ingresos anuales requiere una suscripción paga. Para una startup que acaba de cruzar ese umbral, cada puesto de trabajo de ingeniería suma a la factura. Nada de eso aplica si tu aislamiento corre sobre el systemd que ya tienes instalado.

Cómo se construye el rootfs: debootstrap, dnf y Alpine

nspawn no trae un gestor de imágenes que te arme las imágenes por ti, así que hay que crear el rootfs a mano. La convención es dejarlos bajo /var/lib/machines/[hostname]. Cada familia de distros tiene su herramienta:

Debian y derivados (Ubuntu): debootstrap. Con sudo debootstrap --include=systemd,dbus,locales,bash-completion,curl bookworm /var/lib/machines/debian se levanta un rootfs listo para arrancar.
Derivados de RHEL y Fedora: se instala dnf y rpm, se inicializa la base de datos RPM con rpm --initdb y se usa dnf --installroot contra el repositorio de Fedora. En el ejemplo de la guía, el contenedor de Fedora 41 instala 137 paquetes.
Alpine Linux: el script habitual, alpine-chroot-install, resulta peligroso para este caso de uso. El autor documenta que hace bind del directorio actual dentro del chroot sin avisar —y casi le hace borrar todo su directorio home al correr un rm -rf— además de montar /dev, /proc y /sys, lo que puede terminar aplicando chown a los dispositivos del host. Por eso creó su propio fork, alpine-nspawn-install, que elimina esos comportamientos.

Cuánto pesa cada contenedor en disco

La comparación del propio autor, medida con du -sh:

Debian: 338 MB
Fedora: 507 MB
Alpine: 16 MB

Vale la pena matizar el caso de Fedora: dnf dejó 260 MiB de caché en /var/cache/dnf, y Debian baja a 305 MiB si se quitan paquetes prescindibles como los locales. Para ponerlo en perspectiva, Linux Journal sitúa la instalación base de Alpine en unos 130 MB en un contexto de nodos ligeros para Kubernetes. En cualquier caso, el rootfs es solo el piso del consumo de disco, no el techo.

Arrancar el contenedor con aislamiento de usuarios

El primer arranque se hace con un solo comando:

sudo systemd-nspawn -D /var/lib/machines/[name] -M [name] --private-users=pick --private-users-ownership=chown

Los argumentos importan. -D apunta al directorio del rootfs; -M define el nombre de la máquina, que también se usa como hostname dentro del contenedor; --private-users=pick activa namespaces de UID y GID reservando un bloque de 65536 UIDs y GIDs; y --private-users-ownership=chown ajusta la propiedad del rootfs para que en arranques futuros se sigan usando los mismos identificadores.

Eso da una shell de root, pero no es una forma de desplegar el contenedor a largo plazo: no hay proceso init. Para gestión continua se crea /etc/systemd/nspawn/[name].nspawn en formato INI y se opera con machinectl:

machinectl start [name] para arrancar en segundo plano.
machinectl login [name] para consola y machinectl shell root@[name] para una shell directa.
machinectl enable [name] para que arranque junto con el sistema.

Un detalle que suele morder: en distros sin systemd, como Alpine, hay que agregar KillSignal=SIGTERM a la sección [Exec], porque la señal por defecto (SIGRTMIN+3) solo la entiende systemd y el init de OpenRC no se detendría correctamente.

Networking: red del host, bridge o NAT

Hay tres caminos y la elección depende de tu infraestructura. Compartir la red del host (VirtualEthernet=no) es lo más simple y lo menos aislado. Un bridge (Bridge=br_test) te da IP propia en tu red, algo viable si tienes varias IPs o controlas el router. Y NAT es la salida cuando en el VPS solo dispones de una IP: se crea un bridge sin puerto físico, se publican reglas iptables con MASQUERADE o SNAT y se habilita net.ipv4.ip_forward=1.

Para IPv6, la guía recuerda pedir a tu proveedor una delegación /64, algo que la mayoría de los proveedores de VPS competentes puede hacer.

Compartir carpetas del host y la GPU

La sección [Files] del archivo .nspawn permite montar rutas del host dentro del contenedor: Bind= para lectura y escritura, BindReadOnly= para solo lectura y el modificador norbind para no arrastrar los montajes que cuelgan de esa ruta. Esta es la pieza que hace posible el caso de uso con LLM: el contenedor accede al hardware del host sin las capas intermedias que exigiría una máquina virtual.

NixOS y el soporte OCI: el ecosistema empuja en la misma dirección

No es una tecnología aislada. XDA Developers explica que los contenedores de NixOS se apoyan justamente en systemd-nspawn, se declaran dentro de configuration.nix y se gestionan con systemctl y machinectl. Entre sus ventajas menciona la comodidad de respaldar un solo archivo de configuración; entre sus contrapartes, que los contenedores corren con privilegios de root y que el enfoque queda atado al ecosistema NixOS.

El movimiento más relevante viene del propio systemd. heise reportó que, en la conferencia «All Systems Go!» de Berlín, el desarrollador Lennart Poettering presentó el formato mstack para gestionar imágenes OCI directamente y correrlas como contenedores nspawn. Desde la versión 260, systemd puede descargar imágenes OCI con importctl pull-oci y ejecutarlas con systemd-nspawn --mstack=. Según heise, Poettering dejó claro que systemd no busca competir de frente con Docker o Podman, que brillan por su gestión, sino posicionar a nspawn como un backend capaz de reemplazar al runtime de contenedores.

¿Qué significa esto para tu startup?

Si self-hosteas modelos o servicios y pagas infraestructura, hay decisiones concretas que puedes tomar esta semana.

Audita el costo de tus herramientas de contenedores. Si tu equipo superó los 250 empleados o los US$10M de ingresos anuales, revisa cuánto pagas por licencias de Docker Desktop y cuántos de esos puestos realmente construyen imágenes. El aislamiento sobre el systemd que ya viene en el sistema operativo es una alternativa sin costo para servicios autoalojados.
Prueba Alpine como base de tus contenedores de servicio único. Un rootfs de 16 MB frente a 338 MB de Debian cambia el tamaño de tus backups, la velocidad de tus snapshots y el costo de disco. Eso sí, recuerda el KillSignal=SIGTERM si no usas systemd dentro del contenedor.
Si tu cuello de botella es una GPU en un VPS sin virtualización anidada, nspawn es la ruta más corta. No necesitas una VM completa ni virtiofs: el contenedor ve el hardware del host y puedes montar solo las carpetas que necesita con BindReadOnly=.
Automatiza el networking desde el día uno. Las reglas iptables y los sysctl de forwarding hay que aplicarlos en cada arranque del host. Dejarlo manual es la forma más rápida de perder una tarde depurando por qué un contenedor se quedó sin red tras un reinicio.

Conclusión

systemd-nspawn no va a reemplazar a Docker en tu pipeline de CI/CD ni en el despliegue de microservicios con muchas dependencias. Su terreno es otro: aislar uno o pocos servicios pesados en una máquina que ya controlas, con acceso a hardware real, rootfs de tamaño mínimo y sin sumar un runtime nuevo a la ecuación. Para startups que autoalojan modelos de IA o servicios internos sobre VPS, esa combinación —aislamiento razonable, cero licencias y control total del sistema de archivos— es difícil de igualar.

Fuentes

¿te gustó o sirvió lo que leíste?, Por favor, comparte.

WhatsApp X LinkedIn

¿Y esto cómo se aplica en tu negocio?

En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.

👥 Probar 7 días