Configuring systemd-nspawn for Linux Container Isolation

Configuring systemd-nspawn for Linux Container Isolation

Imagine you need an isolated environment for CI builds on a server with strict security policies. Docker daemon is prohibited due to SELinux or airgap, and a full KVM VM consumes too many resources (RAM, CPU, disk). systemd-nspawn is a built-in systemd tool that solves this without installing additional packages or a separate daemon. We have used it for over 5 years in production on dozens of projects and guarantee stable isolation with minimal overhead. Resource savings can be substantial, reducing computing costs by up to 40% compared to Docker — saving up to $200 per month per server. Our company has 5+ years of experience in containerization and has completed over 50 projects, ensuring reliable and optimized solutions. With typical monthly savings of $200, the investment of $500 for setup pays back in under 3 months.

systemd-nspawn works based on namespaces and cgroups v2, managed via systemctl and machinectl. Unlike chroot, it isolates PID, IPC, UTS, and mounts. With PrivateUsers=yes, it also uses user namespaces, allowing container startup without root. It is lighter than Docker (no daemon, registry, overlayfs), faster than LXC, and ideal for: isolated builds, testing installation scripts, chroot environments, and resource-constrained IoT devices.

Why systemd-nspawn is Faster than Docker

nspawn does not require a separate daemon — the container starts as a child process of systemd. Startup time: ~0.5 seconds compared to 3-5 seconds for Docker (including image pull). RAM savings: up to 200 MB per server by eliminating dockerd, containerd, and registry.

Performance Comparison

The table shows: nspawn is 4-10x faster at startup and requires no daemon, critical for airgapped environments and CI runners with limited resources.

Step-by-Step Guide: Create and Configure a Container

1. Install base system. Use debootstrap for Debian/Ubuntu in /var/lib/machines/:

   debootstrap --arch=amd64 jammy /var/lib/machines/mycontainer http://archive.ubuntu.com/ubuntu/ 

2. Start container. Interactively: systemd-nspawn -D /var/lib/machines/mycontainer. For full boot with systemd init: --boot.
3. Configure options. Create file /etc/systemd/nspawn/mycontainer.nspawn:

   [Exec] PrivateUsers=yes [Network] VirtualEthernet=yes [Files] Bind=/opt/app:/app 

4. Network access. Enable IP forwarding on host and configure NAT:

   iptables -t nat -A POSTROUTING -s 192.168.163.0/24 -j MASQUERADE 

   For automatic setup, use systemd-networkd with IPMasquerade=yes.
5. Resource limits. Via systemd unit override:

   systemctl edit [email protected] 

   Add CPUQuota=50%, MemoryMax=1G, MemorySwapMax=0.
6. Autostart. Run machinectl enable mycontainer — the container will start at boot.

How to Set Up Networking for the Container?

With VirtualEthernet=yes, a veth pair is created: one end in the container (typically host0), the other on the host named ve-. For external access, NAT via iptables or IPMasquerade in systemd-networkd is required. Alternatively, use a bridge network: create a bridge (e.g., br0) and specify Bridge=br0 in the .nspawn file (requires additional DHCP setup on the bridge).

Network Connection Comparison

Snapshots and Cloning via btrfs

If the filesystem is btrfs, machinectl clone creates instant snapshots without copying data. This is convenient for CI: dozens of isolated environments can be deployed in seconds.

# Clone container for testing
machinectl clone mycontainer mycontainer-test

# Rollback changes
machinectl clone mycontainer-backup-latest mycontainer

CI Integration

nspawn containers integrate easily with GitLab CI or Jenkins: each job gets a fresh snapshot, and the container is removed after completion. CPU load during parallel builds is controlled via CPUQuota — for example, 25% per job.

Deliverables (What's Included)

Our engineers, with over 5 years of DevOps experience and 50+ successful container deployments, perform:

• Infrastructure audit: assess isolation needs, btrfs compatibility, current security policies.
• Container creation: choose distribution, configure .nspawn, optimize for load.
• Network setup: NAT, bridge, firewall rules, DNS (systemd-resolved).
• CI integration: automatic snapshot cloning for jobs, cleanup after completion.
• Documentation and training: runbook for management, templates for typical tasks.
• Support: 2 weeks after deployment (bug fixes, fine-tuning).

Timelines: from 1 day for a basic container to 3 days for multi-container setup with CI. Cost is calculated individually; typical setup starts at $500. Get a consultation — we will assess your project.

Why Choose systemd-nspawn?

• No extra daemons: no Docker daemon, registry, overlayfs. Save up to 200 MB RAM per server.
• Reliability: works even on broken systems if systemd is alive.
• Speed: container starts in 0.5 seconds vs 3-5 seconds for Docker.
• Simplicity: one configuration file, familiar management via systemctl.

If your need is an isolated environment without a Docker daemon, systemd-nspawn is the optimal solution. Order configuration — we will implement it to your requirements.

Contact us to discuss integration — we will select the optimal configuration. systemd documentation: https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html