I run around two dozen services in my homelab — media stack, a personal cloud, monitoring, DNS, a reverse proxy, an automation hub, the lot. The number of Docker containers involved is zero. Not "mostly zero." Zero. And before you close the tab: this is a deliberate choice, not a knowledge gap. Here's the reasoning, the tradeoffs, and the honest caveat.
What I do instead
Every service runs as a native install inside its own unprivileged LXC container on Proxmox, managed by systemd, the same way it'd run on a bare metal box. Each container is a tiny Debian system that does exactly one job. The reverse proxy is a container. The database is a container. The media server is a container. Storage lives on ZFS and gets bind-mounted in where needed.
So to be clear: there is containerization here. It's just LXC (system containers) instead of Docker (application containers). That distinction is the whole post.
Why this, and not Docker
One mental model, top to bottom
Inside an LXC container, things are exactly where a sysadmin expects them. The service is installed with the normal package manager or a release binary. It's started by systemd. Its logs are in the journal. Its config is in /etc. There's no compose file, no layered image, no entrypoint script, no "exec into the container to see what's actually happening." If I can administer a Debian box — and I can — I can administer every service I run, using muscle memory I already have.
Proxmox-native everything
Because each service is a Proxmox guest, I get the platform's whole toolbox for free: live resource graphs per service, snapshots, and backups handled by Proxmox Backup Server — deduplicated, verified, restorable to a point in time. A service and its entire environment back up and restore as one unit. No volume-mount archaeology, no "did I remember to persist that directory."
Transparency over convenience
Docker is fantastic at "make this run in 30 seconds without understanding it." That's a genuine strength — and for me, a quiet downside. When something breaks at 1 a.m., I don't want a black box; I want to read the actual config, tail the actual log, and restart the actual service. Running things natively means there's never a layer between me and the software. I understand every service I host, because I had to install it like an adult.
No daemon, no surprises
Unprivileged LXC has a strong isolation story, and there's no big root-owned daemon brokering everything. Each container is just a confined process tree the kernel keeps in its own little world. It suits a setup where I'd rather reason about plain processes than about an orchestration layer's networking and storage abstractions.
The honest tradeoffs
This is not a "Docker bad" post. It costs me real things:
- More setup per service. There's no
docker compose up. I write the install, the systemd unit, the bind mounts. Onboarding a new service is an afternoon, not a minute. (I lean on Ansible to make it repeatable.) - No instant upstream images. When a project ships a Docker image and nothing else, I'm the one figuring out the native install. Sometimes that's friction.
- It doesn't scale like containers do. If I were running hundreds of ephemeral workloads, this would be madness. I'm running two dozen long-lived services on two nodes. Different problem.
Docker optimizes for "get it running fast and move on." I'm optimizing for "understand it completely and run it for years." Both are valid. They're just different goals.
Who should copy this (and who shouldn't)
If your goal is to try a lot of software quickly, use Docker — it's the right tool and I'd recommend it without hesitation. If your goal is to deeply understand and own a stable set of services, and you already enjoy thinking in terms of Linux systems rather than images, the native-LXC path is worth a serious look. The reward isn't speed. It's that there is no part of your stack you can't open up and read.
I'm not anti-Docker. I'm pro-knowing-exactly-what-my-machines-are-doing. For a homelab that runs my actual apartment, that trade has been worth every extra afternoon.
Comments