10 Best Docker Containers for Home Users and Tech Enthusiasts

10 Best Docker Containers for Home Users and Tech Enthusiasts

If you have a spare PC, a NAS or a Raspberry Pi running Docker, these are the ten containers I'd put on it first:

1. Portainer: a web interface for managing containers
2. AdGuard Home: network-wide ad and tracker blocking at the DNS level
3. Audiobookshelf: your own audiobook and podcast server
4. Uptime Kuma: checks that your services are up and tells you when they aren't
5. Heimdall: a start page that links to everything you host
6. Home Assistant: the hub of a local-first smart home
7. Frigate: a camera recorder with on-device object detection
8. Mosquitto: the MQTT message broker many smart-home devices rely on
9. Zigbee2MQTT: connects Zigbee sensors, switches and bulbs without vendor hubs
10. ESPHome: turns cheap ESP32 boards into custom sensors

The first five make the server itself easier to run and more useful to the household. The last five work together as a home automation stack. You don't need all ten. Pick the problem you want to solve and start there.

This list was first published in January 2025 and refreshed in November 2026 with current project status and setup notes.

What is a Docker container, and why use one at home?

A container is an application packaged with everything it needs to run, isolated from other software on the same machine. Docker downloads that package (an image) from a registry and runs it. Your settings and data live in volumes, which survive when the container is deleted and recreated.

For a home server, that model has three practical benefits:

• No dependency clashes. Each app brings its own libraries, so installing one service can't break another.
• Easy upgrades and rollbacks. Updating usually means pulling a newer image and recreating the container. If the update misbehaves, you go back to the previous image tag.
• A setup you can rebuild. A single compose.yaml file describes every service, port and volume. Back up that file and the volumes, and you can rebuild the server on new hardware.

Containers are lighter than virtual machines because they share the host's kernel rather than running a whole operating system each. That's why an old desktop or a NAS can run a dozen of them comfortably. The trade-off is weaker isolation than a VM, which matters for the security notes later in this article.

If you haven't set up a Docker host yet, start with the weekend project to build a properly managed Docker host. It covers installing Docker, organising Compose files and testing your backups.

The ten containers at a glance

Containers for running the home lab

1. Portainer: manage containers from a browser

Portainer gives you a web interface for everything you'd otherwise do with docker commands: starting and stopping containers, reading logs, opening a console, managing volumes and networks, and deploying Compose files as "stacks". It can manage several Docker hosts, and Kubernetes, from one place.

Who it suits: people who are new to Docker or who simply prefer seeing their containers on a screen. It's also handy for checking logs from a phone. The Community Edition is free. A paid Business Edition adds team and access-control features.

Before you install it: Portainer manages Docker by mounting the Docker socket, /var/run/docker.sock. Anything with access to that socket can effectively control the host as root, so treat the Portainer login as an admin password, use HTTPS (the default port is 9443), and don't expose it to the internet. Keep your Compose files in a folder or Git repository too, so the UI isn't the only record of how things are configured.

Portainer isn't the only option. The Docker host weekend project uses Dockhand, a lighter Compose-focused manager, and the same socket precautions apply to it.

2. AdGuard Home: block ads and trackers for the whole network

AdGuard Home is a DNS server that refuses to resolve known advertising, tracking and malware domains. Point your router's DHCP settings at it and every device on the network is covered: phones, laptops, smart TVs and the smart-home gadgets you can't install an ad blocker on. It can also send your DNS queries upstream over encrypted DNS (DNS-over-HTTPS or DNS-over-TLS), apply per-device rules, and act as the network's DHCP server if you want it to.

Who it suits: any household. The query log alone is an education: it shows how often a smart TV or a cheap camera tries to contact servers it has no reason to talk to.

Before you install it:

• DNS is now critical. If the container or its host goes down, nothing on the network can resolve names. Give clients a second DNS server, ideally a second AdGuard Home instance on different hardware, rather than a public resolver that would bypass your filtering.
• Port 53 may already be in use. On Ubuntu, the systemd-resolved stub listener holds port 53. Disable the stub listener before starting the container, or the port mapping will fail.
• DHCP needs host networking. If you want AdGuard Home to hand out addresses, run the container with network_mode: host so it can see DHCP broadcasts. For DNS only, normal port mappings are fine.
• Expect some breakage. Aggressive blocklists break the odd shopping link or app login. Start with the default list and add more gradually.

Pi-hole does the same job and is equally good. Choose whichever interface you prefer.

3. Audiobookshelf: your own audiobook and podcast server

Audiobookshelf organises and streams audiobooks and podcasts you own or subscribe to. It downloads new podcast episodes automatically, remembers your listening position across devices, and has companion mobile apps as well as a web player.

I started using it because every podcast app I settled on seemed to be discontinued or changed a few months later. With Audiobookshelf, my subscriptions and listening history stay on my own server regardless of what happens to any one app.

Who it suits: heavy podcast listeners and anyone with a library of DRM-free audiobooks.

Before you install it: the value comes from listening away from home, so plan remote access deliberately rather than forwarding a port on your router. A VPN such as WireGuard or Tailscale is the simplest secure option: your phone joins the home network and the server stays private. If you need browser access without a VPN, use a tunnel or reverse proxy with authentication in front of it, and keep the server updated. Put the library and the configuration on volumes you back up, because listening progress lives in the configuration database.

4. Uptime Kuma: know when something breaks

Uptime Kuma checks your services on a schedule and notifies you when one stops responding. It can check websites (HTTP and HTTPS, including certificate expiry), TCP ports, ping, DNS records, Docker containers and several databases. It can also receive "push" heartbeats from scripts such as a nightly backup job, so you learn when the job didn't run. Notifications go to dozens of services, including email, Telegram, Discord, Slack, ntfy and Home Assistant, and it can publish a simple status page.

Version 2.0, released in October 2025, added MariaDB as an alternative to the built-in SQLite database and refreshed the interface. If you're upgrading from 1.x, back up the data volume and read the migration notes first.

Who it suits: anyone running more than a handful of services, especially if other people in the house depend on them.

Before you install it: a monitor on the same machine as everything else can't tell you that the machine is down. Run Uptime Kuma on separate hardware if you can, even a Raspberry Pi, or monitor the monitor with an external heartbeat. Be selective about notifications, too: alert on things someone needs to act on, not every brief blip. The same principles apply at home as at work, as covered in designing actionable alerts.

5. Heimdall: one start page for everything you host

Heimdall is an application dashboard: a tidy page of tiles linking to every service you run, with optional live stats for supported apps. Set it as the browser home page and nobody in the house needs to remember port numbers.

Who it suits: households where several people use the self-hosted services, and anyone with more than five or six web apps.

Before you install it: Heimdall is maintained by the LinuxServer.io team and still receives updates and security fixes, but new features arrive slowly. If you want a dashboard configured in YAML with more widgets, Homepage is a popular alternative, and Homarr offers a drag-and-drop editor. All three do the core job well, so this is a matter of taste.

Containers for a local-first smart home

The remaining five containers work best together. Home Assistant is the hub, and the others connect devices to it without relying on a manufacturer's cloud.

6. Home Assistant: the smart home hub

Home Assistant is an open-source home automation platform that runs locally. It has integrations for thousands of devices and services, from lights and thermostats to solar inverters and energy meters, and it lets you combine them in automations, dashboards and history graphs. Because it runs locally, most automations keep working when the internet doesn't.

Who it suits: anyone who wants devices from different brands to work together, or who wants to stop depending on a manufacturer's cloud.

Before you install it, choose the installation type. Home Assistant runs in Docker as "Home Assistant Container", but that installation doesn't include the Supervisor. As a result, it doesn't have the built-in app store for one-click extras such as Mosquitto, Zigbee2MQTT and ESPHome. Home Assistant renamed these from "add-ons" to apps in early 2026, and they're only available on Home Assistant OS. That leaves two sensible routes:

• Home Assistant OS, on dedicated hardware or in a virtual machine (for example, on Proxmox). It's the easiest choice if Home Assistant is the main reason you're building a server.
• Home Assistant Container, with the supporting services run as separate containers, as in this list. It fits best if you already run a Docker host and are comfortable managing Compose files.

For the Container route, the documentation recommends network_mode: host so Home Assistant can discover devices on your network.

7. Frigate: a camera recorder that understands what it sees

Frigate is a network video recorder (NVR) that runs object detection on your own hardware. Instead of recording every gust of wind, it can recognise people, cars, animals and other objects, and record or alert based on what it saw and where. Video stays on your server.

It integrates with Home Assistant through an integration installed from HACS (the Home Assistant Community Store), which uses MQTT for events. That means a detected person at the front door can trigger lights, notifications with a snapshot, or anything else Home Assistant can do. An optional paid subscription, Frigate+, fine-tunes detection models on images from your own cameras that you have reviewed and verified, which can reduce false positives.

Who it suits: anyone with IP cameras that support RTSP who wants smarter recording without cloud subscriptions.

Before you install it: Frigate is the most demanding container on this list. Running detection on the CPU alone is slow and inefficient. Plan for a supported detector, such as a Google Coral, an Intel integrated GPU via OpenVINO, or another accelerator listed in the documentation. Also give recordings their own storage with a retention limit, so continuous video doesn't fill the disk the rest of your services rely on. A Raspberry Pi is a poor fit for more than a camera or two.

8. Mosquitto: the MQTT message broker

Mosquitto is a lightweight broker for MQTT, the publish-and-subscribe protocol many smart-home devices and tools use to exchange messages. Zigbee2MQTT publishes device state to it, Frigate publishes detection events to it, and Home Assistant subscribes to both. Many DIY and commercial devices (for example, those running Tasmota firmware) speak MQTT too.

Who it suits: anyone running Zigbee2MQTT or Frigate with Home Assistant Container. You won't use it directly, but the rest of the stack depends on it.

Before you install it: since version 2.0, Mosquitto only accepts local connections from the same machine until you configure a listener. Create a minimal mosquitto.conf that listens on the network and requires a password:

listener 1883
allow_anonymous false
password_file /mosquitto/config/passwd
persistence true
persistence_location /mosquitto/data/

Then create a user for each client, such as Home Assistant and Zigbee2MQTT. The command prompts for the password:

docker compose exec mosquitto mosquitto_passwd -c /mosquitto/config/passwd homeassistant

Omit -c when adding further users, because it overwrites the file. Restart the container after editing the password file. Keep port 1883 on your local network only.

9. Zigbee2MQTT: Zigbee devices without vendor hubs

Zigbee2MQTT talks to Zigbee devices, including sensors, buttons, plugs and bulbs from many manufacturers, through a single Zigbee coordinator, then publishes their state to MQTT. You avoid a separate hub for each brand, and its device database covers thousands of models. Zigbee devices form a mesh. Mains-powered devices such as plugs and bulbs relay messages for battery-powered sensors, so coverage improves as you add devices.

Who it suits: anyone building up a collection of Zigbee devices, particularly from mixed brands. Home Assistant's built-in ZHA integration is a simpler alternative if you don't want MQTT. Zigbee2MQTT typically supports more device-specific features.

Before you install it: you need a Zigbee coordinator, either a USB adapter or a network-attached coordinator. Pass a USB adapter into the container using its stable path rather than /dev/ttyUSB0, which can change after a reboot:

devices:
  - /dev/serial/by-id/usb-YOUR_ADAPTER_ID:/dev/ttyACM0

Use a USB extension cable to move the adapter away from USB 3 ports and the server's case, which can interfere with the 2.4 GHz signal. If you're following an older guide, note that version 2.0 (released December 2024) included breaking configuration changes. Check the current documentation before copying settings.

10. ESPHome: build your own sensors

ESPHome turns inexpensive ESP32 and ESP8266 microcontroller boards into custom devices. You describe the device in a short YAML file, for example "a temperature sensor on this pin and a relay on that one", and ESPHome compiles and installs the firmware. The ESPHome container provides a web dashboard (the Device Builder) to write configurations, flash boards and push updates over Wi-Fi.

The finished devices connect to Home Assistant directly through its native API, without needing MQTT. An ESP32 can also act as a Bluetooth proxy, relaying nearby Bluetooth sensors to Home Assistant. That's useful when the server sits in a cupboard far from the sensors.

Who it suits: tinkerers who want sensors that don't exist commercially, or that cost a fraction of the price when built yourself.

Before you install it: run the container with host networking so the dashboard can find devices on your network. Store the configuration folder in a backed-up volume. It contains your device definitions and the encryption keys the devices use to talk to Home Assistant.

How do you run these containers safely?

A few habits apply to every container on this list:

• Don't expose admin interfaces to the internet. Use a VPN such as WireGuard or Tailscale for remote access, or a reverse proxy with authentication for the few services that genuinely need to be public.
• Treat Docker socket access as root access. Only management tools such as Portainer should mount /var/run/docker.sock, and only when you understand why they need it.
• Pin image versions once things work. The latest tag means an update can arrive whenever a container is recreated. Pinning a version makes each upgrade deliberate, and lets you roll back.
• Back up volumes and test a restore. Your configuration, history and media live in volumes, not in the images. A backup you have never restored is a hope, not a backup.
• Read release notes before major upgrades. Several projects here, including Uptime Kuma, Zigbee2MQTT and Mosquitto, have had major versions with breaking changes.

The Docker host weekend project walks through each of these, including a scripted backup and a full restore test.

Which containers should you start with?

Start with one problem rather than all ten:

• "I want fewer ads and a quieter network." Start with AdGuard Home, then add Uptime Kuma so you know if DNS goes down.
• "I want to manage the server more easily." Start with Portainer and Heimdall, and keep the Compose files in Git.
• "I want to own my media." Start with Audiobookshelf, and set up VPN access before you need it on the move.
• "I want a smart home that works offline." Start with Home Assistant. Add Mosquitto and Zigbee2MQTT when you buy your first Zigbee device, ESPHome when you want a custom sensor, and Frigate when you have cameras and suitable hardware.

The takeaway

A modest Docker host can replace a surprising number of subscriptions and vendor hubs. These ten containers cover the essentials: managing and monitoring the server, filtering the network, owning your media, and running a smart home that doesn't depend on someone else's cloud. Each one is free to self-host, actively used, and well documented.

What makes the setup last isn't the choice of containers. It's how you run them: keep admin interfaces off the internet, pin versions, and back up and test your volumes. Get those habits right, and adding the eleventh container is easy.

References

• Docker: Docker overview and Docker Engine security
• Portainer: installing Portainer CE on Docker
• AdGuard Home: Docker instructions
• Audiobookshelf: documentation
• Uptime Kuma: project repository and releases
• Heimdall: project repository and LinuxServer.io image
• Home Assistant: installation types and Linux and container installation
• Frigate: documentation and Frigate+
• Mosquitto: documentation and migrating to version 2.0
• Zigbee2MQTT: Docker installation
• ESPHome: documentation and Bluetooth proxy