Building a 19-Container Docker Stack on Proxmox VE

When I started building Atlas, my homelab server, the goal was simple: a media server and some basic monitoring. A year later, it's grown into something much bigger — a 19-container Docker stack running on a tiny Lenovo ThinkCentre M910q, handling everything from media streaming to security monitoring to AI agent infrastructure.

Here's how it's put together, what broke along the way, and what I learned fixing it.

## The Hardware

Atlas runs on a Lenovo ThinkCentre M910q Tiny — an Intel Core i7-6700T with 64GB of RAM (well, 32GB at the moment, more on that below) and a 1TB NVMe SSD internally for the Proxmox OS itself. All the bulk storage lives externally across three USB enclosures, managed by ZFS:

- **Cenmate dock** — 2x4TB + 2x1TB drives (one 4TB is currently detached, waiting to be resilvered back into the pool)

- **Inatek dock** — 2x1TB drives

- **UGREEN NVMe enclosure** — 1x1TB NVMe SSD

It's a tiny machine punching well above its weight class, with all the real storage living outside the box.

## The Stack

Nineteen containers might sound like a lot, but they break down into a few clear categories:

**Media & Requests**

Jellyfin runs the show as the media server, with Radarr and Sonarr handling automated movie and TV downloads, Prowlarr managing indexers, and Jellyseerr letting me (and whoever I share access with) request new content without touching the backend.

**Networking & Security**

Gluetun handles VPN tunneling for the download clients, keeping that traffic isolated from the rest of the network. Byparr handles Cloudflare-protected indexers that would otherwise block Prowlarr. Vaultwarden handles credential management for the homelab. Nginx Proxy Manager handles internal reverse proxying.

**Monitoring**

This is the part that actually keeps the whole thing alive. Grafana and Prometheus track metrics, Node Exporter and cAdvisor feed them host and container-level data, and Uptime Kuma watches every service from the outside, the way a user actually experiences it. When something goes down, I know before I'd otherwise notice.

**Automation**

n8n ties a lot of this together — webhook-triggered workflows that route alerts to Telegram, log incidents to Obsidian, and keep my AI agents in the loop.

**AI & Management**

Open WebUI gives me a clean chat interface for local LLMs, while Portainer makes managing all nineteen containers from one dashboard far less painful than the CLI alone.

## What Broke (And What I Learned)

The most painful lesson came from bad RAM. One of two 32GB SODIMM sticks developed bad pages, and because it was silently corrupting data under load rather than crashing outright, it took weeks of intermittent ZFS errors, Docker container crashes, and kernel panics before Memtest86 finally pointed to the actual cause. Drives I assumed were failing turned out to be completely healthy once I ran SMART tests after identifying the RAM — they'd just been victims of memory corruption the whole time.

The fix ended up being straightforward once identified: pull the bad stick, RMA it under warranty, and in the meantime run on a single good stick. Lesson learned — when you see "random" corruption across unrelated subsystems (ZFS, Docker, kernel), check your RAM before you start replacing hardware.

## Why This Setup Works

The real value of this stack isn't any single container — it's the combination. Grafana tells me when something's wrong. Uptime Kuma confirms it from the outside. n8n routes the alert to Telegram instantly. And because everything is backed up across multiple independent layers — local storage plus several offsite destinations — recovering from a failure is a matter of minutes, not days.

Building this taught me more about Linux, networking, and infrastructure debugging than any class could. If you're thinking about starting your own homelab, my advice is simple: start small, monitor everything, and back up more than you think you need to. You'll thank yourself the first time something actually breaks.