Best Docker Containers for Your Home Server in 2026

If you’re standing up a home server for the first time, or rebuilding after the inevitable “I’ll just wipe it and start fresh” moment, picking the best docker containers for home server use is where you spend the first hour and regret for the next six months. This list is for people running an N100 mini-PC, a Beelink S12 Pro, a Synology that supports Compose, or similar modest hardware. If you have not settled that part yet, the mini PC tiers for a Docker homelab and the NAS models that actually run Docker cover both routes. It assumes you have docker-compose installed and can edit a YAML file without a video tutorial. When you have settled on your shortlist, the interactive compose stack builder turns it into a single ready-to-run docker-compose.yml, and the full topic index collects every per-service walkthrough referenced below.

Who Should Skip This

If you’re already running a multi-node Kubernetes cluster with Flux CD syncing from GitOps, you’ve moved past this guide. Also skip it if you have under 8GB of total RAM, because half these containers will fight over swap.

The Foundation Layer: Management and Reverse Proxy

Before any application container, get your management layer sorted.

Dockge (port 5001) is a Docker Compose stack manager from the creator of Uptime Kuma. It’s the right default for anyone who prefers docker-compose.yml but doesn’t want to SSH in every time a restart is needed. Portainer CE is the older, more feature-heavy alternative. It is fine, but its RBAC model and credential management add complexity that a single-node home setup doesn’t benefit from.

For your reverse proxy, Caddy is the answer for most home server operators. Automatic HTTPS via ACME, a simple Caddyfile syntax, and no fighting with certbot renewal timers. Traefik integrates with Docker labels for dynamic per-container routing and is worth learning if you’re managing 20+ services, but the configuration surface is real, as the Traefik with Docker Compose walkthrough makes clear. Caddy first, Traefik when you outgrow it.

There is a third option worth naming for anyone who would rather not edit YAML to add a route at all. Nginx Proxy Manager puts a web UI in front of Nginx and handles Let’s Encrypt certificates from a form, reaching the same outcome as Traefik with no configuration files:

services:
  npm:
    image: jc21/nginx-proxy-manager:latest
    container_name: nginx-proxy-manager
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "81:81"  # web UI
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

Port 81 is the admin interface, and it should never be exposed beyond your LAN.

Media Stack: Jellyfin and the *arr Ecosystem

Jellyfin is the default media server recommendation in 2026. Completely open-source, no account required, no telemetry, and the LinuxServer.io image handles PUID/PGID permission mapping correctly out of the box. For hardware transcoding on Intel N-series mini-PCs, mount /dev/dri:/dev/dri, and Quick Sync handles 4K HEVC transcoding without pegging the CPU at all.

A minimal starting point, with the render device mounted for Quick Sync:

services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    container_name: jellyfin
    restart: unless-stopped
    environment:
      - JELLYFIN_PublishedServerUrl=https://media.yourdomain.com
    volumes:
      - ./config:/config
      - ./cache:/cache
      - /mnt/media:/media:ro   # your media library, read-only
    devices:
      - /dev/dri:/dev/dri      # Intel/AMD GPU transcoding

Plex is still a valid choice if you want its polished mobile apps and don’t mind the account requirement and telemetry. Jellyfin has closed the feature gap significantly, though.

Build the *arr automation stack around Jellyfin if you want downloads managed without manual intervention:

• Sonarr: TV show management and download automation
• Radarr: the same for movies
• Prowlarr: indexer manager that feeds both
• Bazarr: automatic subtitle downloads
• Jellyseerr: a request interface for family members so they stop texting you to add things

This is more configuration work than it sounds. Budget a Saturday afternoon and two restarts.

The *arr apps need a download client underneath them, and qBittorrent is the usual pick, a web-accessible client that Sonarr and Radarr drive directly:

services:
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    restart: unless-stopped
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/New_York
      - WEBUI_PORT=8080
    volumes:
      - ./config:/config
      - /mnt/downloads:/downloads
    ports:
      - "8080:8080"
      - "6881:6881"
      - "6881:6881/udp"

Set PUID and PGID to the same values across qBittorrent and the *arr containers, so every service in the pipeline reads and writes the downloads directory as the same user.

Privacy and Networking

Pi-hole or AdGuard Home provides DNS-level ad blocking for every device on the network without touching each client individually. AdGuard Home has a cleaner UI and supports DNS-over-HTTPS natively; Pi-hole has a larger community and more documentation covering edge cases. Either runs comfortably on an N100, and either is a five-minute install. One deployment decision is worth making before you paste the compose file: a DNS container that borrows the host’s address collides with anything already bound to port 53 on that machine, which is why many homelabs hand it its own LAN IP through a macvlan network instead of publishing ports.

services:
  pihole:
    image: pihole/pihole:latest
    container_name: pihole
    restart: unless-stopped
    environment:
      - WEBPASSWORD=changethis
      - TZ=America/New_York
    volumes:
      - ./etc-pihole:/etc/pihole
      - ./etc-dnsmasq.d:/etc/dnsmasq.d
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "8080:80"
    cap_add:
      - NET_ADMIN

Note the web UI is mapped to 8080 rather than 80, leaving port 80 free for whichever reverse proxy you settled on above.

Vaultwarden is a Bitwarden-compatible password server that idles at around 10MB of RAM, light enough for a Raspberry Pi. It has full compatibility with the official Bitwarden browser extensions and mobile apps.

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    volumes:
      - ./data:/data
    environment:
      - WEBSOCKET_ENABLED=true
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.vw.rule=Host(`vault.yourdomain.com`)"
      - "traefik.http.routers.vw.entrypoints=websecure"
      - "traefik.http.routers.vw.tls.certresolver=letsencrypt"

Stand the reverse proxy up before Vaultwarden rather than after: the browser extension requires HTTPS to talk to the server at all, so a plain HTTP deployment looks broken even though it is running fine. Self-hosting your own password manager eliminates vendor lock-in and keeps credentials off third-party servers, which matters whenever a hosted credential provider is in the news. For the wider breach and vulnerability picture, TechSentinel.news covers security incident reporting.

Tailscale solves remote access without port forwarding. Install the container (or the agent directly on the host), authenticate once, and every device on your Tailnet reaches your home server through an encrypted WireGuard tunnel. No DDNS, no open inbound ports, no dynamic firewall rules. The free Personal plan supports up to 6 users with unlimited devices. This is the networking answer for roughly 95% of home lab operators.

Self-Hosted Cloud

Nextcloud is mature, feature-rich, and genuinely complex to operate well. The official Docker image works, but plan for PostgreSQL and Redis from day one, because SQLite collapses under any meaningful write load. The All-in-One container simplifies initial setup but reduces configurability. Budget a few hours the first time; upgrades are also more involved than most containers.

Immich is the Google Photos replacement with mobile apps that do real-time backup, face recognition, and EXIF map views. It needs more RAM than most containers on this list, so plan for 2-4GB. Worth it if eliminating a cloud photo subscription matters to you.

Paperless-ngx handles scanned documents with OCR. Low resource footprint, high long-term value if you receive paper mail. Scan receipts and invoices into it and search them by content two years later.

Syncthing deserves a mention precisely because it is the answer for people who do not want any of the above. It is decentralised file sync with no server role at all. Syncthing on the home server and Syncthing on your laptop sync directly to each other. If all you actually wanted was Dropbox-style sync, this replaces Nextcloud at a fraction of the operational weight:

services:
  syncthing:
    image: syncthing/syncthing:latest
    container_name: syncthing
    restart: unless-stopped
    environment:
      - PUID=1000
      - PGID=1000
    volumes:
      - ./config:/var/syncthing
      - /home/user/sync:/sync
    ports:
      - "8384:8384"
      - "22000:22000/tcp"
      - "22000:22000/udp"

Home Automation

Home Assistant is the de facto standard, supporting thousands of integrations across smart lights, thermostats, sensors and presence detection, with a large community and unusually good documentation.

services:
  homeassistant:
    image: ghcr.io/home-assistant/home-assistant:stable
    container_name: homeassistant
    restart: unless-stopped
    privileged: true
    network_mode: host    # required for device discovery
    volumes:
      - ./config:/config
      - /etc/localtime:/etc/localtime:ro

That network_mode: host line is not optional if you want local device discovery to work, and it has a consequence worth planning around: a host-networked container does not play well with Traefik or any other label-driven reverse proxy. Reach Home Assistant directly on its own port, 8123 by default, and route the rest of your stack normally. What that line turns off, and the two alternatives to it, are set out in the Docker Compose host networking guide.

Local AI

Ollama + OpenWebUI lets you run local large language models without routing queries through cloud APIs. Ollama handles model downloads and serves an OpenAI-compatible API endpoint; OpenWebUI provides a ChatGPT-style frontend. On 16GB RAM you can run Llama 3.1 8B locally, expect roughly 8-14 tokens per second CPU-only and 15-20-plus once you add GPU offload. An NVIDIA card with 12GB VRAM (RTX 3060 or better) takes it from “interesting experiment” to “actually replacing some cloud usage.”

The privacy case for local inference is straightforward: queries stay on-device, with no conversation logging and no model fine-tuning on your data. For the deeper threat modeling around AI inference in self-hosted environments, aisec.blog covers prompt security and model access patterns in detail.

Backup and Monitoring

Uptime Kuma monitors your services and sends alerts through Slack, Telegram, email, or webhooks the moment something falls over. Five minutes to configure, and it covers HTTP, TCP, DNS and ping checks:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    container_name: uptime-kuma
    restart: unless-stopped
    volumes:
      - ./data:/app/data
    ports:
      - "3001:3001"

Grafana + Prometheus is the step beyond that, and a much larger one. Prometheus scrapes metrics from your services and infrastructure while Grafana turns them into dashboards. The setup effort is genuinely high and the visibility once it runs is genuinely unbeatable, which is why it belongs late rather than early. Start from a community stack such as dockprom, which bundles Prometheus, Grafana, cAdvisor for container metrics and Node Exporter for host metrics into one Compose file, rather than assembling four services yourself.

Kopia handles encrypted incremental backups with deduplication. Point it at a NAS dataset, a Samba share, or a Backblaze B2 bucket and schedule daily snapshots. Duplicati is the older alternative with broader format support if you have existing backup archives. Either works.

One standing rule: test your restore before you need it. Backups you have never restored from are assumptions.

Small Wins Worth Ten Minutes Each

Not everything needs a section. These are low-effort, high-satisfaction additions once the foundation is in place:

• Homarr, Homer or Dashdot: a homepage for your own services, so the URLs live somewhere other than your memory. Homer is the most widely used; Homarr has a more modern UI and reads the Docker socket to discover what you are running.
• Mealie: a recipe manager that imports from URLs automatically and generates meal plans and shopping lists.

services:
  homarr:
    image: ghcr.io/ajnart/homarr:latest
    container_name: homarr
    restart: unless-stopped
    volumes:
      - ./config:/app/data/configs
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - "7575:7575"

Mount the Docker socket read-only, as above, whenever a container asks for it. Homarr only needs to look.

What to Run First

If this is a first home server, the order matters more than the list does:

1. Pi-hole or AdGuard Home: network-wide benefit on day one, and simple enough to build confidence.
2. A reverse proxy plus Vaultwarden: this pairing teaches you the routing and certificate model you will use for everything else, and leaves you with a password manager at the end of it.
3. Uptime Kuma: so you learn a service has fallen over from an alert rather than from someone complaining.

Add Jellyfin and Home Assistant once those feel routine. Leave Grafana and Prometheus until you have enough services running to give the dashboards something to say, and leave local AI until you have checked your RAM against the hardware notes below.

Hardware Notes

Most containers on this list are lightweight, at 50-500MB RAM each in steady state. The exceptions:

• Jellyfin transcoding: high CPU without hardware acceleration; mount /dev/dri and the load drops dramatically
• Nextcloud with PostgreSQL + Redis: budget around 2GB total for the stack
• Immich: 2-4GB RAM under load
• Ollama with any real LLM: 8-16GB RAM minimum, GPU strongly recommended

An N100 mini-PC with 16GB RAM handles the full stack minus local AI. Bump to 32GB and you can run Ollama with smaller models (7-8B parameters) comfortably. To turn that list into a number before you buy, the container resource calculator totals RAM and CPU across a stack, and the three mini PC tiers compared match the total to a box.

Add a NAS for media and backup storage. Do not put your media library on the same NVMe as your OS and databases. Which NAS platforms genuinely run Compose, and which quietly do not, is the whole subject of the best NAS for Docker containers guide.

One last piece sits outside Docker entirely: whatever is between this box and the internet. If you are opening anything to the outside world rather than keeping everything behind Tailscale, the homelab firewall guide at firewallcompare.com covers that layer.

Related across the network

• Home Assistant OS vs Container: Which Install Method to Pick — homeassistanthq.com
• Install Open WebUI With Docker: Setup Guide — openwebuihq.com