I've been running Docker containers inside a full Debian VM for almost a year. Initially, that looked fun until I needed fortnightly upgrade scripts and multiple services to keep Linux alive. Still, all of that worked, so I never questioned it.

I tried several Docker managers, including Portainer, Dockge, and a few others. But it still felt overkill. When I stumbled upon Lightwhale, an OS built specifically for Docker that runs entirely from RAM, I had to try it in my home lab. It was enough to make me rethink everything.

A Docker-only OS that refuses to be anything else

Immutable OS that boots from ISO

Lightwhale isn't a Docker dashboard for managing all containers. Nor is it a stripped-down Linux OS. It's built to run Docker containers and is an immutable Linux OS based on Buildroot. It live-boots from an ISO and loads its filesystem into memory.

I was amazed to find a fully functional Docker engine in a 200MB package, with no installer or configuration wizard. All I needed to do was boot from the ISO, SSH in, and the Docker Engine would be ready to spin up some containers. For starters, there's no package manager, since there's nothing necessary to run containers.

The root filesystem is immutable, but Lightwhale does allow configuration of persistent storage. Only later did I learn that the container data and configuration live on a completely separate volume that survives reboots. With nothing that can touch system files, there is nothing to patch or break.

Getting Lightwhale onto Proxmox is easy

Upload ISO and set persistent stack

I downloaded the Lightwhale OS directly on my Proxmox mini PC. After that, I created a new VM and attached a secondary virtual disk to it. Once I set the boot order to the Lightwhale ISO, I started it and found no setup wizard, timezone selector, partitioning screen, or bootloader prompt.

Since Lightwhale is immutable by default, it is apt for testing. Fortunately, there's a way to run a permanent stack, but you'll need to configure persistent storage. That's possible with two commands and a reboot. Lightwhale calls it 'setting a magic header,' which involves writing a specific sequence to the secondary disk.

On reboot, the system partition is automatically formatted with Btrfs and mounted as a data volume. That's where Docker's data lives permanently — all images, volumes, and Compose files. Though I learned that the OS is immutable by design, it's not exactly a throwaway environment just for testing.

Reaching NFS shares from other Proxmox VMs

Single host mount to benefit the whole stack

My Proxmox mini PC stores a variety of data, from a media library to several documents. I wanted Lightwhale's Docker containers to access those storage shares without duplicating data or reconfiguring disks.

While my first instinct was to map SMB shares, Lightwhale doesn't include the CIFS kernel module to handle them cleanly. Docker's built-in CIFS volume driver was no help either. It appears self-contained, but the host kernel handles the actual mount. The minimal Compose file returned a 'no such device' error, indicating that CIFS support was missing. The workaround includes using NFS, and a quick sudo modprobe nfs confirmed that it loads without issues.

It took me 2 minutes to install nfs-kernel-server and enable it on my VM, which already offers NFS shares. Since that point, both SMB and NFS coexist on the same path without any conflicts.

Since Lightwhale only exposes the /home directory as writable, that's where all the mount points live. I created a directory there and mounted the NFS shares. Once that worked, I edited /etc/fstab with the NFS share's details so it would reattach automatically on every boot.

Following that, I ensured that each container that needed to access the NFS share had a volume entry pointing to that host path. For example:

jellyfin:
volumes:
 - /home/op/mounts/media/usb/movies:/media/movies:ro 
 - /home/op/mounts/media/usb/shows:/media/shows:ro 
 - /home/op/mounts/media/usb/music:/media/music:ro

immich-server:
volumes:
 - /home/op/mounts/media/hdd/immich:/usr/src/app/upload:ro

With the NFS mount shared across containers, there's no need to duplicate anything or add a volume driver to each container separately.

Lightwhale runs the full home lab stack

OS never got in the way

The persistence and NFS mounts made it easy to run Docker containers on Lightwhale. With a single Docker command, I watched a full stack of containers come online — Pi-hole, Immich, Jellyfin, NetAlertX, ownCloud, Home Assistant, and Uptime Kuma. Spinning them down or back up takes only one command. No dependency installation is necessary.

That was quite different since Lightwhale deliberately avoids being like a regular host OS and gets out of the way. The Lightwhale OS itself runs in RAM, while the data lives on a separate Btrfs volume. The entire stack stays intact after a fresh boot and keeps maintenance overhead minimal—only when a container fails.

Running Lightwhale still has some limitations

Compose quirks and no ARM support

Lightwhale only works on x86-64 hardware. So you can't use it on Raspberry Pis or other ARM-based SBCs for now. Most importantly, there's no built-in web dashboard — no interface at first boot. You need to pick Portainer, Dockge, or other alternatives to manage the container stack.

Most Docker containers use a common bridge network, but Home Assistant and NetAlertX are exceptions. When you use network_mode: host in Docker, it won't let you join other containers sharing the same internal network. Instead, they run their own isolated network.

Planning to use network-attached storage? Don't expect SMB shares to work easily. Test NFS first.

Docker without housekeeping

Lightwhale is a useful, immutable Linux OS for spinning up Docker containers. But there's no way it's replacing a full Linux. On Proxmox running a home lab, it's a Docker host that removes a lot of the overhead I was carrying. With a single command to enable persistent storage and mount NFS shares, I can spin up all the containers with a single Compose file. The best part is I don't have to manage or upgrade it every few weeks.