My Current Software Stack: 20+ Docker Containers on a Mini PC
A deep dive into every service running on my NiPoGi mini PC — from Home Assistant and Zigbee2MQTT to Authentik and WireGuard, all orchestrated with Docker Compose.
On this page
In the hardware post, I covered the physical devices. Now it’s time to look at the other half of the equation: the software that ties everything together. Every service listed here runs as a Docker Compose container on the same NiPoGi mini PC — a Celeron J4125 with 8 GB of RAM and 128 GB of storage. Yes, all of it. On that one little box.
Let me walk you through every container, what it does, why I chose it, and where the cracks are starting to show.
Container Management
🐳 Dockge
Dockge is how I manage all my Docker Compose stacks. Built by the same developer behind Uptime Kuma, it provides a clean web UI for creating, editing, starting, and stopping docker-compose.yml files — without touching the terminal. Each stack gets its own directory and its own compose file, which makes organization straightforward.
What makes Dockge stand out compared to Portainer:
- Compose-native — it works directly with
docker-compose.ymlfiles on disk, not an abstraction layer - Lightweight — minimal resource footprint, important when you’re running 20+ containers on 8 GB of RAM
- Simple UI — no enterprise features you’ll never use, just compose management done well
Every service described below is a stack in Dockge.
Smart Home Core
🏠 Home Assistant
Home Assistant is the brain of the entire smart home. It connects to every device — Zigbee sensors, WiFi plugs, IR blasters, radiator valves — and provides a unified interface for monitoring, automation, and control. I run it as a Docker container (not Home Assistant OS), which gives me full control over the host system but comes with trade-offs I’ll discuss later.
Key integrations:
- Zigbee2MQTT for all Zigbee devices (via MQTT)
- BTicino switches and blinds via the Legrand/Netatmo cloud integration
- Netatmo radiator valves
- Broadlink IR control for AC and TV
- Shelly energy monitoring via local API
- Matter for the Tapo smart plugs via Matter Hub
- ESPHome for the Everything Presence Lite sensors
The automation engine is where Home Assistant truly shines. Climate control, lighting scenes, presence-based actions, security alerts, energy dashboards — it all lives here.
📡 Zigbee2MQTT
Zigbee2MQTT bridges the Zigbee network to MQTT, making every Zigbee device accessible to Home Assistant (and any other MQTT consumer). It connects to the Sonoff CC2652P USB dongle and manages the entire Zigbee mesh — device pairing, network mapping, firmware updates, and message routing.
Why Zigbee2MQTT over ZHA (Zigbee Home Automation, the built-in HA integration):
- Broader device support — more devices supported out of the box with specific converters
- Decoupled from Home Assistant — if HA restarts, the Zigbee network stays up
- Web UI for diagnostics — network map, device logs, and manual message sending
- Active community — new device support lands quickly
It runs with an Eclipse Mosquitto MQTT broker in the same compose stack.
🔗 Matter Hub
The Python Matter Server acts as a Matter controller, enabling Home Assistant to communicate with Matter-compatible devices — in my case, the five Tapo Matter smart plugs. Matter is still maturing, but having native local control over these plugs without any vendor cloud is the promise of this protocol.
📱 Broadlink Manager
A web interface for managing the two Broadlink RM4 Mini IR blasters. It makes learning and testing IR codes much easier than doing it through Home Assistant directly. Once codes are captured, they’re used in HA automations to control the AC units and bedroom TV.
Networking & Security
🛡️ Pi-hole
Pi-hole is the network-wide DNS sinkhole that blocks ads, tracking domains, and telemetry at the DNS level. Every device on the network — phones, laptops, smart TVs, IoT devices — benefits from it without needing any client-side software.
Configuration highlights:
- Custom blocklists tuned for Italian ad networks and smart TV telemetry
- Local DNS records for all internal services (e.g.,
ha.local→ Home Assistant) - Conditional forwarding for proper reverse DNS resolution of local devices
- Serves as the primary DNS server for the entire network
🌐 Nginx Proxy Manager
Nginx Proxy Manager provides reverse proxy with automatic SSL certificate management via Let’s Encrypt. Every internal service gets a clean subdomain (ha.mydomain.com, dockge.mydomain.com, etc.) with HTTPS — no more remembering ports.
Key features:
- Automatic Let’s Encrypt SSL with DNS challenge via Cloudflare
- Access lists to restrict certain services to local network only
- Proxy hosts for all Docker services with WebSocket support
- Simple UI — no hand-editing nginx config files
☁️ Cloudflare Tunnel (cloudflared)
Cloudflared creates an encrypted tunnel between my home network and Cloudflare’s edge network. This allows secure remote access to selected services without opening any ports on the router — no port forwarding, no exposed attack surface.
Only specific services are exposed through the tunnel: Home Assistant, Nginx Proxy Manager’s dashboard, and a few others that need remote access. Everything else stays local-only.
🔐 Authentik
Authentik is a full-featured identity provider (IdP) and single sign-on (SSO) solution. It sits in front of services that don’t have their own authentication or where I want centralized identity management.
What it provides:
- SSO with OIDC/OAuth2 and SAML — one login for multiple services
- 2FA/MFA support — TOTP and WebAuthn for all accounts
- Application proxy — can protect services that have no auth by placing Authentik in front
- User management — centralized user directory, useful when I eventually let family members access specific services
Setting up Authentik was the most complex deployment in the entire stack, but the security benefit is worth it.
🔒 WireGuard
WireGuard provides VPN access to the home network when I’m away. It’s dramatically simpler and faster than OpenVPN — the entire configuration is a few lines, and the protocol overhead is minimal.
Use cases:
- Accessing internal services from mobile or laptop when traveling
- Secure DNS — routing DNS queries through Pi-hole even on public WiFi
- Full tunnel mode — all traffic routed through home for privacy when on untrusted networks
Monitoring & Observability
📊 Uptime Kuma
Uptime Kuma monitors every service and device on the network. It checks HTTP endpoints, TCP ports, DNS resolution, and ping responses — and sends alerts via Telegram when something goes down.
Monitoring targets include:
- All Docker containers (HTTP health checks)
- Router and mesh nodes (ping)
- External services and domains (HTTP/HTTPS)
- DNS resolution (Pi-hole health)
📈 Beszel
Beszel is a lightweight server monitoring tool that tracks CPU, memory, disk, network, and temperature metrics. It provides historical graphs and alerts when resource thresholds are crossed. On a machine with only 8 GB of RAM running 20+ containers, knowing where resources are going is critical.
🏠 Homarr
Homarr is the dashboard — the landing page for everything. It displays all services with their icons, status indicators, and direct links. Rather than bookmarking dozens of IP:port combinations, Homarr gives me a single pane of glass for the entire stack.
I actually run two instances — one for the full admin dashboard and another as a simplified view for quick access to the most-used services.
Development & File Management
💻 Code Server
Code Server is VS Code in the browser. It gives me a full development environment accessible from any device — useful for editing Home Assistant YAML configurations, tweaking Docker Compose files, or writing scripts directly on the server without SSH.
Having a browser-based IDE means I can make quick config changes from a tablet or even a phone in a pinch.
📁 File Browser
File Browser provides a clean web UI for browsing, uploading, downloading, and managing files on the server. It’s the lightweight alternative to a full NAS interface when I just need to quickly grab or upload a file.
🔧 Zone Configurator
A web-based text editor originally designed for Home Assistant configuration files. It provides syntax highlighting for YAML and a file tree view — useful as a lightweight alternative to Code Server when I only need to make a small configuration change.
Additional Services
🚀 SpeedTest
A self-hosted speed test tool running on the local network. It lets me measure LAN throughput between devices — useful for diagnosing network bottlenecks and verifying that the Xiaomi mesh is performing as expected (spoiler: the 1 Gbit ethernet limitation is real).
🤖 Open WebUI
Open WebUI is a self-hosted interface for interacting with large language models. I use it for experimenting with local AI models — running small LLMs for quick queries, code assistance, and general experimentation. On the Celeron J4125 it’s painfully slow with anything beyond tiny models, but it works for testing the concept before investing in better hardware.
📡 Everything Presence Lite — Firmware Installer
Not a Docker container per se, but a bookmarked web tool for flashing and updating firmware on the Everything Presence Lite mmWave sensors via ESPHome. These sensors receive periodic firmware updates that improve presence detection accuracy and add new features.
📻 SONOFF Zigbee Dongle Firmware
Similarly, this is a reference link for the Sonoff Zigbee coordinator firmware. Keeping the CC2652P firmware up to date ensures the best Zigbee mesh stability and support for new device types.
The Full Stack at a Glance
| Category | Service | Purpose |
|---|---|---|
| Container Management | Dockge | Docker Compose UI |
| Smart Home | Home Assistant | Automation platform |
| Smart Home | Zigbee2MQTT + Mosquitto | Zigbee bridge + MQTT broker |
| Smart Home | Matter Hub | Matter device controller |
| Smart Home | Broadlink Manager | IR code management |
| Networking | Pi-hole | DNS ad blocking |
| Networking | Nginx Proxy Manager | Reverse proxy + SSL |
| Networking | Cloudflare Tunnel | Secure remote access |
| Security | Authentik | Identity provider / SSO |
| Security | WireGuard | VPN access |
| Monitoring | Uptime Kuma | Service uptime monitoring |
| Monitoring | Beszel | Server resource monitoring |
| Dashboard | Homarr (x2) | Service dashboard |
| Development | Code Server | Browser-based VS Code |
| Files | File Browser | Web file manager |
| Development | Zone Configurator | HA config editor |
| Utility | SpeedTest | LAN speed testing |
| AI | Open WebUI | Local LLM interface |
That’s 20+ containers sharing 8 GB of RAM and a Celeron J4125 CPU. The fact that it all runs — and runs reasonably well — is a testament to how lightweight most of these services are when containerized.
The Elephant in the Room: Home Assistant as a Container
This is the single biggest pain point of my current setup, and it deserves an honest discussion.
Running Home Assistant as a Docker container instead of Home Assistant Operating System (HAOS) means you get full control over the host machine — I can run all these other services alongside it, manage the OS directly, and have complete flexibility. But it comes at a cost.
What I’m missing
- Add-ons — HAOS has a built-in add-on store with one-click installs for services like Zigbee2MQTT, Node-RED, Mosquitto, and dozens more. As a container, I have to deploy and manage each of these separately via Docker Compose. Every update, every configuration change, every port mapping — it’s manual.
- Backups — HAOS provides full automated snapshot backups that include the OS, configuration, and all add-ons. With the container approach, I have to script my own backup strategy, making sure to capture all the compose stacks, volumes, and configuration files.
- Supervisor — the HAOS Supervisor manages service health, restart policies, and system updates. Without it, I rely on Docker’s restart policies and Dockge for management — functional, but not as integrated.
- Hardware discovery — HAOS handles USB device passthrough (like the Zigbee dongle) more gracefully. In Docker, you need to explicitly map
/dev/ttyUSB0or/dev/serial/by-id/...and hope the device path doesn’t change after a reboot.
What’s actually breaking
The 8 GB RAM limit is the real killer. Here’s a typical memory snapshot:
| Service | Approx. RAM |
|---|---|
| Home Assistant | ~800 MB |
| Zigbee2MQTT + Mosquitto | ~150 MB |
| Authentik (server + worker + PostgreSQL + Redis) | ~1.2 GB |
| Pi-hole | ~100 MB |
| Nginx Proxy Manager | ~80 MB |
| Uptime Kuma | ~120 MB |
| Beszel | ~80 MB |
| Homarr (x2) | ~200 MB |
| All others combined | ~800 MB |
| OS + Docker overhead | ~1.5 GB |
| Total | ~5 GB |
That looks manageable on paper, but the moment Home Assistant runs a complex automation sequence, or Authentik processes an auth flow, or all services decide to garbage-collect at the same time — RAM spikes above 7 GB and things start swapping. The 128 GB SSD doubles as swap space, and that SSD is already near capacity with container images and volumes.
The next step: HAOS on dedicated hardware
For the new homelab build, I’m seriously considering switching to Home Assistant Operating System on dedicated hardware. The plan:
- HAOS on its own machine — a dedicated mini PC or NUC running HAOS, with the Zigbee dongle attached directly. No more USB passthrough, no more manual add-on management.
- Separate Docker host — a more powerful server (more RAM, more storage) running all the non-HA services: Authentik, monitoring, development tools, AI experiments.
- Clean separation — Home Assistant focuses on what it does best (home automation), while the Docker host handles everything else.
This separation would also improve reliability. Right now, if the Docker host needs a reboot for updates, the smart home goes down too. With dedicated HAOS hardware, the lights, heating, and security continue working independently.
What I’ve Learned
Running 20+ containers on a single mini PC has been a masterclass in resource optimization and Linux systems administration. I’ve learned more about Docker networking, reverse proxies, DNS, identity management, and monitoring in the past few years than I did in any course or tutorial.
But I’ve also learned that there’s a line between “efficient” and “fragile.” A single point of failure — one machine, one SSD, one power supply — running your entire smart home and infrastructure is a risk. The new lab will address that.
Next Steps
In the next post, I discuss the new hardware selection — the philosophy behind the build, the scenarios I evaluated (mini PC + NAS vs custom build), and why expandability and GPU support drove the final decision.
The migration is coming. Time to build it right.