I love Docker and its container ecosystem as much as the next expert. Between its simple commands, Compose functionality, and huge community support, Docker is easy for beginners to learn and reliable enough to serve veteran project building enthusiasts. But as someone who started with Docker and moved on to other container runtimes along my DIY project creation journey, I must admit that it has certain quirks that make it a bit complicated for advanced container hosting tasks.
In fact, after the transition to Proxmox A few years ago and when testing the pure usefulness of the LXC, I realized that my Attachable desktop The workstation was actually an unoptimized mess. Sure, it took me a while to get used to them, but native Linux containers have become the Docker replacement for everything from self-hosted workloads to wacky experiments with home servers.
Running a Windows-based Docker Desktop setup is more trouble than it’s worth
Running a bloated container runtime inside a resource-hogging operating system is not a good idea
As much as it pains me to admit this, I used to rely on Docker Desktop when I was a Linux-fearing teenager for my tinkering needs. And to tell you the truth, it’s not bad to run a couple of containers. But as my DIY projects began to accelerate, it made little sense to run everything on my daily driver. My mounted filesystems were all over the place, while my self-hosted stack of essential applications was siphoning off additional resources during my gaming sessions.
Even putting these issues aside, running containers inside something as bloated as Windows is already terrible from an efficiency perspective. And as I got used to the Docker terminal, the desktop UI started to feel unnecessary. I eventually deployed Proxmox to a spare machine, but my dependence on Docker still held me back for a while.
Moving to a VM-based Docker setup on Proxmox was an improvement
But I still wasn’t getting the most out of my hardware.
If you’ve ever used Proxmox, you probably know that it only supports Linux containers and virtual machines natively. However, there are several ways to get Docker containers up and running on the virtualization platform. Going the Docker route within LXC doesn’t sound terrible on paper, but considering that both the LXC and its nested Docker environment share the host kernel, all it takes is one rogue container to compromise the security of the node. Not to mention that UID mappings become overly complicated in a nested environment, and the same applies to network configurations for these Inception-style unprivileged containers. And no, running privileged containers was never an option in the first place, as they would cause more security vulnerabilities.
Switching to a virtual machine (one without a GUI) and relying on the non-desktop version of Docker seemed like a solid compromise and, to be honest, gave me the best of both worlds. This is how I used Docker during my first year as a Proxmox user, and as long as I had enough RAM and CPU resources on the host, I didn’t mind running an entire virtual machine just for Docker. But once I started repurposing dinosaur laptops, outdated mini PCs, and low-resource x86 SBCs in my Proxmox home lab, the added overhead of a virtual machine made this setup much less pragmatic. If I had stuck with my VM-based Docker instance, I probably would have declared my decade-old Lenovo laptop e-waste and tossed it somewhere, instead of using it as part of my “resurrected tech” pool like I do these days.
Finally, I switched to LXC
I quickly realized that they were much easier to use than I had anticipated.
As a newbie LXC user, running TurnKey templates in Proxmox seemed overly complex. After all, LXCs provide a complete Linux environment as a conventional virtual machine, which seemed much more complex than simple Docker applications (especially those deployed via Compose YAML files). But now that I’ve been using them for a while, I really appreciate how customizable they are. A Debian TurnKey template is all I need to configure everything from a server calls.cpp to a Tailscale subnet router without worrying about excessive resource hogging tendencies of virtual machines.
Thanks to the talented Proxmox community, it’s just as easy to get up and running. The Proxmox VE-Helper Scripts community repository is a goldmine for free software enthusiasts who want to play with quality-of-life tools without the added complexity of managing everything manually. It includes hundreds of single-line installation commands that can configure all aspects of a self-hosted application in a couple of minutes. Heck, I still rely on these scripts when I’m too tired to manually configure a service, and most of my container stack is built with PVE-Helper Scripts.
Docker isn’t terrible by any means, I just trust LXCs more
While I may seem too harsh on Docker, I’m actually grateful for this container runtime. Docker is what got me into the self-hosting ecosystem, and the storage-hogging services I’ve deployed on my TrueNAS node depend on this beginner-friendly runtime. Likewise, if building an obscure FOSS application from scratch seems too complicated, I would probably run it in a Docker environment. But for most of my self-hosting needs, LXCs provide enough utility to replace their Docker counterparts.
