I've been using Proxmox for about six months now, though I've been following the project for much longer. I had a bare-metal TrueNAS instance that I never got around to migrating away from, but I finally bit the bullet at the start of last summer and began the painstaking process of moving all my self-hosted services over. In that time, I discovered something somewhat unusual on the surface: deploying multiple Linux Containers (LXCs) to host Docker made significantly more sense than using a single virtual machine.

Before breaking down the reasoning, I'll clarify exactly what I mean. For many, a single virtual machine running a Linux distribution (like Ubuntu or Debian) to host Docker is the standard way to go. It has benefits: there is a single Docker daemon managing all your containers, and your self-hosted applications share defined resources and a single kernel.

However, after deploying numerous LXCs on Proxmox focused on single services, I discovered that segregating multiple Docker setups works incredibly well. Each LXC has its own Docker daemon, and applications are segmented across different LXCs based on logical groupings.

It might seem redundant at first glance, but this nested architecture provides a crucial abstraction layer with significant advantages.

Individual Docker LXCs make segmenting services easier

Resources are separated rather than shared

Like a virtual machine, LXCs can be assigned memory limits, storage quotas, CPU cores, and more, all at the hypervisor level. You provide hard resource boundaries in a way that Docker simply can't match. For example, if you don't give the LXC access to a specific storage medium, it is practically impossible for the Docker container running within to know it exists, let alone touch it.

Consider a resource-intensive application (such as CPU transcoding on Jellyfin or Plex). If you run critical self-hosted services like your reverse proxy and authentication on the same machine, you risk resource contention. By segmenting these across separate LXCs, each running Docker, you can guarantee that the media server's transcoding operations won't starve your authentication system of resources, even during peak usage.

In a single Docker VM, all containers compete for the same pool of resources. While Docker provides resource limits via cgroups, having multiple LXCs gives you an additional, more robust layer of isolation at the hypervisor level.

This also reduces the so-called "blast radius" when something goes catastrophically wrong. If a Docker container escapes its constraints, or if the Docker daemon itself crashes or becomes corrupted, you want to limit the scope of damage.

With multiple LXCs, a compromised Docker daemon only affects a single LXC's worth of containers. Furthermore, a misconfigured container that consumes all available storage only affects what's available to that specific LXC. This applies to updates as well. If you want to update the underlying operating system, upgrade Docker, or do maintenance, you don't need to take down your entire stack. You can update less critical services first, giving yourself room for error before tinkering with the services you rely on most.

Finally, there's a security element when it comes to networking, too. Different applications have different network access needs and security requirements, and with multiple LXCs, you can do things like:

• Create separate network bridges
• Apply different firewall rules
• Isolate services from the internet

While not impossible, this is much harder to achieve through Docker networking alone within a single VM, as all containers share the host's network namespace and routing tables.

It's both easier to organize and more flexible

Logically separated services are easier to understand

From a mental model standpoint, individual LXCs provide clear logical separation. This lines up well with the philosophy of how Proxmox encourages users to organize services. I have multiple Docker Compose stacks separated into different LXCs logically. For example, one LXC may contain a stack related to media, and another for automation.

All of this simplifies documentation and makes it easier to shut down or start up services based on current needs, as I can easily see them from the Proxmox web UI. A single VM with a dozen Docker Compose files is a cognitive task in itself (even if you use something like Portainer), whereas LXCs provide a service boundary immediately visible in the Proxmox interface.

The same applies to backups and hardware access. I can back up individual LXCs more frequently because every service boundary is also a backup boundary. This is a major plus compared to the all-or-nothing approach a massive VM requires. I can give an LXC access to specific hardware (like a GPU, or a network share mounted on the host) without that resource being available to all the Docker containers I run, and I can experiment with different setups without breaking everything at once.

Is it wasteful? Not really. LXCs are lightweight because they share the host's kernel. Yes, technically, an LXC can add a small amount of RAM overhead, but that is negligible compared to running multiple VMs to achieve the same isolation, or even compared to the resource usage of the applications themselves.

In terms of complexity, I suppose it's technically more complex to manage at first, but it ends up being extremely intuitive. It reduces the cognitive load of troubleshooting, and you can even use tools like Terraform or Ansible to manage your setups in the future. Even networking between containers is pretty easy, so that's not an issue, either.

There are scenarios where a single virtual machine is a better choice. A small deployment with just a couple of containers is likely easier with a VM, especially if you have limited resources. Additionally, if you prefer to keep things simple or use dynamic container creation, a virtual machine is definitely a better fit for that use case. The same goes for portability, as a single VM is easier to migrate than a collection of LXCs.

The key aspect for me is that LXC and Docker solve different problems and operate at different layers of abstraction. LXCs provide system-level isolation and resource management, while Docker provides application-level containerization and orchestration. Using both together creates a more robust and logically organized infrastructure. There's no "wrong" answer, but if you're stuck deciding between an LXC or a VM for your Docker host, hopefully, this helps you make your decision!