I used to think running each Arr app in its own LXC was a smart move. It felt clean. Minimal. Efficient. However, if you’ve ever tried to juggle Sonarr, Radarr, SABnzbd, and the rest across a handful of Proxmox containers, you know the cracks start showing up quickly. Trust me, I’ve been there, and it’s not worth the pain.

If you’re serious about your media setup, it’s time to move your Arr stack into a Docker environment inside a single Virtual Machine. Here’s why it matters.

Points that I’m Willing to Concede

• You can setup the Arr Suite in their own unprivileged LXCs. I did it and it worked. However, I didn’t like managing it.

• I know some of you run Docker in LXCs. That is a special kind of headache that I want nothing to do with. It also isn’t officially supported by Proxmox.

What We’re Working With

Proxmox is a virtualization platform that allows you to run multiple operating systems on a single physical machine, perfect for a homelab or media hoarders who want to consolidate services.

LXC containers are lightweight virtualized environments that share the host’s kernel. Think of them as isolated spaces that use fewer resources than full virtual machines.

Virtual machines (VMs) are complete, isolated operating systems that don’t share anything with the host.

The Arr suite includes applications like Sonarr (TV show automation), Radarr (movie automation), Lidarr (music automation), and SABnzbd (download client) that work together to automatically find, download, and organize your media library.

LXC Containers Look Great on Paper, But They Will Trip You Up Fast

Sure, LXCs are lightweight. They share the Proxmox host’s kernel and do not suck up much in the way of resources. That sounds ideal until you realize just how tightly integrated the Arr apps are.

Too Many Moving Parts: Seven LXCs means seven operating systems, seven update schedules, seven IP addresses, and seven chances for something to break. Docker bundles everything together. Less patching, fewer surprises.

Networking Gets Messy: Apps like Sonarr and Radarr need to talk to Prowlarr and your downloader constantly. Getting that cross-talk working between LXCs means manually configuring IP addresses, firewall rules, and routing between containers. Here is where Docker shines. It creates an internal network where services can find each other by name automatically. Instead of remembering that Sonarr lives at 192.168.1.100:8989, you tell it to connect to “sonarr:8989” and Docker handles the rest.

Storage and Permissions Are a Nightmare: When multiple LXCs attempt to access the same media folders, you might run into user ID and group ID issues. One container might create files that another cannot read or modify. With Docker, you map your storage once to the VM, and all containers share the same user context, eliminating permission headaches.

Unprivileged Containers Make Network Storage a Pain: If you are running unprivileged LXCs (which you should for security), accessing NFS or SMB shares becomes a special kind of hell. Unprivileged containers map user IDs differently than the host system, so your media files could potentially show up as owned by “nobody” or become completely inaccessible. You will spend hours tweaking UID maps, CIFS mount options, and NFS export settings to get basic file access working. Meanwhile, a VM with Docker mounts your network shares normally and passes them through to containers without the mapping headaches.

Config Drift Is Real: One LXC might get updated while another does not. Suddenly, one app fails, and you spend hours figuring out why version mismatches are breaking API calls between services. Docker Compose gives you a single source of truth, a YAML file that defines your entire stack with specific versions.

Docker in a VM: The Sweet Spot for Media Automation

Here is where things get easier.

One VM to Rule Them All: Instead of babysitting a small army of containers, you manage one Debian or Ubuntu VM. Update once. Patch once. Reboot once.

Docker Compose = Sanity: Everything is in a single docker-compose.yml file that handles every Arr app you need (Sonarr, Radarr, Lidarr, SABnzbd, etc.), their connections, volumes, ports, and environment variables, plus user IDs, and timezones are all centralized and clean. Spin up the stack with docker compose up -d, shut it down with one command docker compose down, and update the apps without touching the rest of the system docker compose pull.

True Isolation: VMs are completely fenced off from your Proxmox host. If something breaks, it will not leak into your main system. If you ever need to move the stack, just back up the VM and drop it in the new location.

Less Headache When Things Break: One place to look for problems. Use docker logs and get answers fast. No need to jump between different containers and hunt through logs scattered across multiple LXCs.

Better Community Support: Most media server guides today assume you are running Docker. That means more tutorials, more troubleshooting help, and fewer dead ends when you run into problems.

Efficient Use of Resources: A single VM with Docker may use slightly more memory than LXCs initially, but long term, it is more stable, more predictable, and easier to maintain. The small resource overhead is worth the massive reduction in complexity.

Stop Fighting. Start Watching.

LXCs are ideal for simple, fire-and-forget services that do not need to communicate with each other. But the Arr suite is not that. These apps need to work together seamlessly, and they need consistency across your entire stack.

Docker inside a VM gives you that consistency. This method provides you with the benefits of isolation and virtualization with the simplicity of containerized applications that can communicate with each other effortlessly.

So, skip the mess. Build your media automation stack inside a VM. Use Docker Compose. Spend less time debugging networking and permission issues, and more time enjoying your perfectly organized media library.

Set it up once. Watch it work. Enjoy your media.

Need a good mini-desktop to run Proxmox on?