Almost every service you might want to host at home is distributed as a Docker image. In a homelab with a hypervisor, however, the question is not whether to use Docker but where to run it. There are three routes: directly on the host, inside an LXC container, or in a virtual machine. Each has consequences for security, backups and ease of maintenance.
Option 1: Docker on the hypervisor host
Installing Docker directly on the Proxmox VE system or another hypervisor seems the simplest route, but it is the one to avoid.
- Network interference: Docker creates its own firewall rules and bridge interfaces, which can clash with the hypervisor's network management.
- Mixed updates: the host system should stay as clean as possible and aligned with what the vendor intends.
- No boundary: a problem in a container, or its compromise, directly affects the machine that hosts everything else.
The hypervisor host should do one thing only: host virtual machines and system containers.
The case is different for a server without a hypervisor, such as a mini PC running a Linux distribution dedicated to services. There, Docker on the host is the normal choice.
Option 2: Docker inside an LXC container
LXC containers are light: they share the host kernel, start in an instant and use little memory. Running Docker inside them is possible by enabling options such as nesting, and it is common in homelabs.
Advantages:
- minimal RAM use compared with a VM;
- direct access to host folders through mount points;
- easy sharing of a GPU for transcoding.
Drawbacks to know about:
- two layers of containers on the same kernel: isolation is weaker than with a VM;
- compatibility: some storage combinations, particularly Docker storage drivers on certain host file systems, have caused problems in the past and may need specific configuration;
- host kernel updates can affect the containers without warning;
- the Proxmox documentation recommends running Docker in a virtual machine rather than an LXC container.
Option 3: Docker in a virtual machine
A VM with a minimal Linux distribution and Docker installed is the cleanest solution.
- Strong isolation: the VM has its own kernel; a problem stays contained.
- Complete, consistent backups: the VM backup includes system, configuration and volumes, and restores as a single unit.
- Snapshots before updates: update, check, and if something goes wrong roll back in seconds.
- Portability: the VM moves to another host or is recreated from a template.
The cost is a little more memory, usually a few hundred megabytes for the VM's operating system: on current hardware a modest price.
One VM or many?
Once you have chosen a VM, you still need to decide how to group services:
| Layout | Pros | Cons |
|---|---|---|
| One VM with every service | simple to manage | one reboot stops everything |
| VMs per area (media, home, tools) | contained failures, separate resources | more systems to update |
| One VM per service | maximum isolation | wasted resources and effort |
In my work I find grouping by area balanced: one VM for media services, one for home automation, one for admin tools such as monitoring and the reverse proxy. Critical services, such as the password manager, often deserve a VM of their own.
Data and volumes
Whatever you choose, data must have a clear home:
- configuration in versioned Compose files, kept in a repository;
- data volumes in known paths, not in automatically created anonymous volumes;
- large archives, such as photos and videos, on a NAS mounted over NFS or SMB, so the VM stays small;
- databases on fast local disk, never on network shares with uncertain performance.
For databases, a live VM backup is useful but not always enough: add a periodic dump, which guarantees a consistent copy regardless of the file system's state at the moment of the snapshot.
Management and updates
Tools such as Portainer or Dockge offer a web interface for managing containers, while services such as Watchtower can update images automatically. Automatic updates are handy for unimportant services but risky for those where a new major version may change the data format. For these, pin the version in the Compose file, update it deliberately and take a snapshot first.
In short
- Do not install Docker on the hypervisor host.
- In LXC it uses little memory but isolates less and can cause compatibility problems.
- In a virtual machine it offers isolation, snapshots and consistent backups at a modest cost.
- Grouping services by area is a good compromise between simplicity and failure containment.
- Volumes in known paths, versioned Compose files and database dumps complete the picture.
