Container Management Tools: Portainer vs Dockge vs Lazydocker vs CLI

Docker CLI is powerful, but typing docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}" every time you want to check your containers gets old. When you're managing 20+ containers across multiple compose stacks, a management tool saves time and reduces the chance of fat-fingering a command that takes down your entire media stack.

The homelab community has settled on a few popular options, each with a different philosophy. Portainer is the full-featured GUI. Dockge is the compose-focused lightweight alternative. Lazydocker is the terminal UI for people who live in the shell. And plain Docker CLI with aliases is always there when the others feel like overkill.

This guide compares all four with real deployment examples and helps you pick the right one for your workflow.

Quick Comparison

Portainer

Portainer is the most feature-complete Docker management platform. It provides a web-based GUI for managing containers, images, volumes, networks, and stacks. The Community Edition is free for up to 3 nodes.

Deployment

services:
  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    restart: unless-stopped
    ports:
      - "9443:9443"    # HTTPS web UI
      - "8000:8000"    # Agent communication
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./portainer-data:/data
    security_opt:
      - no-new-privileges:true

Access the web UI at https://your-server:9443 and create your admin account.

Key Features

Stack management: Deploy and manage Docker Compose stacks from the web UI. Paste your compose YAML, click deploy, and Portainer handles the rest. You can also pull stacks from Git repositories.

App templates: Portainer includes one-click templates for common homelab services. Click "Portainer Templates" to see pre-built stacks for services like Nextcloud, Pi-hole, and WordPress. Community template lists add hundreds more:

    environment:
      - TEMPLATES=https://raw.githubusercontent.com/Lissy93/portainer-templates/main/templates.json

Container console: Need to debug inside a container? Portainer lets you open a shell directly in the browser — no docker exec needed.

Multi-host management: Deploy a Portainer Agent on each Docker host:

# On remote hosts
services:
  portainer-agent:
    image: portainer/agent:latest
    container_name: portainer-agent
    restart: unless-stopped
    ports:
      - "9001:9001"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /var/lib/docker/volumes:/var/lib/docker/volumes

Then add the remote endpoint in Portainer's UI: Environments > Add Environment > Agent.

Resource monitoring: Basic CPU and memory charts for each container. Not as detailed as Prometheus/Grafana, but useful for quick checks.

Portainer's Compose Handling

Portainer's biggest quirk is how it handles Docker Compose files. When you deploy a "Stack" through Portainer, it stores the compose file in its own database — not as a file on disk. This means:

• Your compose files aren't in your usual directory structure
• You can't easily version-control them with Git
• If you delete and recreate a stack, volumes may not reconnect automatically

Workaround: Use Portainer's Git integration to pull compose files from a repository. Changes in Git trigger redeployment, and your compose files stay version-controlled.

When to Choose Portainer

• You manage containers across multiple hosts
• You want a visual overview of your entire Docker environment
• You need user management (share access with family/friends without giving SSH)
• You use one-click templates for quick deployments
• You want container console access without SSH

When to Avoid Portainer

• You prefer compose files on disk in a Git repo
• You don't need multi-host management
• You want minimal resource usage
• You find the extra abstraction layer confusing (some people prefer seeing their compose files directly)

Dockge

Dockge (pronounced "dock-gee") was created by the developer behind Uptime Kuma as a lightweight, compose-focused alternative to Portainer. Its philosophy is simple: manage your Docker Compose stacks, and nothing else. Compose files are stored as actual files on disk, not in a database.

Deployment

services:
  dockge:
    image: louislam/dockge:1
    container_name: dockge
    restart: unless-stopped
    ports:
      - "5001:5001"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./dockge-data:/app/data
      # Where your compose stacks live on disk
      - /opt/stacks:/opt/stacks
    environment:
      - DOCKGE_STACKS_DIR=/opt/stacks

Access the web UI at http://your-server:5001.

How Dockge Works

Each stack in Dockge corresponds to a directory in your stacks folder:

/opt/stacks/
├── jellyfin/
│   └── compose.yaml
├── nextcloud/
│   └── compose.yaml
├── monitoring/
│   └── compose.yaml
└── arr-stack/
    └── compose.yaml

When you create or edit a stack in Dockge's UI, it writes a real compose.yaml file to disk. This is Dockge's killer feature — your compose files are always accessible as plain files, ready for Git version control or manual editing.

Key Features

Interactive compose editor: Dockge's compose editor has syntax highlighting, validation, and a "Convert" button that can convert docker run commands into compose format.

Real-time status: See which containers are running, stopped, or erroring at a glance. The UI updates in real-time via WebSocket.

Terminal output: When you deploy or update a stack, Dockge shows you the Docker Compose output in real-time — just like running docker compose up in your terminal.

Simple and fast: Dockge doesn't try to manage images, volumes, or networks separately. It manages compose stacks, period. This makes it fast and predictable.

Migrating Existing Stacks to Dockge

If you have existing compose stacks scattered around your filesystem, move them into Dockge's stacks directory:

# Move an existing stack
mkdir -p /opt/stacks/jellyfin
cp /home/user/docker/jellyfin/docker-compose.yml /opt/stacks/jellyfin/compose.yaml

# Dockge expects the file to be named "compose.yaml"
# If your volumes use relative paths, update them to absolute paths

Restart Dockge, and it will discover the new stacks automatically.

When to Choose Dockge

• You want compose files stored as real files on disk (Git-friendly)
• You prefer a simple, focused tool over a feature-rich platform
• You manage everything on a single host
• You want to convert docker run commands to compose format
• You like the Uptime Kuma developer's design philosophy (clean, minimal, effective)

When to Avoid Dockge

• You need multi-host management
• You want container-level console access from the web UI
• You need user management / RBAC
• You want resource monitoring charts

Lazydocker

Lazydocker is a terminal UI (TUI) for Docker. It's the htop of container management — fast, lightweight, and perfect for people who spend most of their time in a terminal anyway.

Installation

# Via Go
go install github.com/jesseduffield/lazydocker@latest

# Via package manager
# Arch
sudo pacman -S lazydocker

# Homebrew (macOS/Linux)
brew install lazydocker

# Or run in Docker (meta, but it works)
docker run --rm -it \
  -v /var/run/docker.sock:/var/run/docker.sock \
  lazyteam/lazydocker

For persistent Docker-based usage:

# Add as an alias
alias lzd='docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock -v ~/.config/lazydocker:/.config/jesseduffield/lazydocker lazyteam/lazydocker'

Key Features

Container overview: All containers with status, image, ports, and uptime at a glance. Navigate with arrow keys.

Real-time resource graphs: CPU and memory usage graphs rendered in the terminal — surprisingly detailed for ASCII art.

Log viewing: Scroll through container logs with search. Press f to follow logs in real-time.

Container management: Stop, restart, remove, and rebuild containers with single keystrokes.

Bulk operations: Prune unused images, volumes, and containers from a menu.

Keyboard Shortcuts

Custom Commands

Lazydocker supports custom commands in ~/.config/lazydocker/config.yml:

customCommands:
  containers:
    - name: "View compose config"
      attach: false
      command: "docker compose -f {{ .Container.Labels.com.docker.compose.project.config_files }} config"
    - name: "Shell into container"
      attach: true
      command: "docker exec -it {{ .Container.ID }} /bin/sh"
    - name: "View health check"
      attach: false
      command: "docker inspect --format='{{json .State.Health}}' {{ .Container.ID }} | jq"

When to Choose Lazydocker

• You live in the terminal and want to stay there
• You need a quick overview of container status and resource usage
• You manage a single host via SSH
• You want the lightest possible tool (no web server, no database)
• You like TUI applications and keyboard-driven workflows

When to Avoid Lazydocker

• You prefer a web-based interface
• You want to edit compose files visually
• You need multi-user access
• You want to manage stacks (compose projects), not just individual containers

Docker CLI: The Foundation

Every other tool on this list is built on top of the Docker CLI. Knowing it well makes you faster with any management tool and is essential when things go wrong.

Essential Commands

# Container management
docker ps                                    # Running containers
docker ps -a                                 # All containers (including stopped)
docker compose up -d                         # Start a compose stack
docker compose down                          # Stop and remove a compose stack
docker compose pull                          # Pull latest images
docker compose up -d --force-recreate        # Recreate containers with new images
docker logs -f --tail 100 container-name     # Follow logs, last 100 lines

# Debugging
docker exec -it container-name /bin/bash     # Shell into a container
docker inspect container-name                # Full container details
docker stats                                 # Real-time resource usage
docker compose logs -f                       # Follow all stack logs

# Cleanup
docker system prune -a                       # Remove all unused data
docker image prune -a                        # Remove unused images
docker volume prune                          # Remove unused volumes

Useful Aliases

Add these to your ~/.bashrc or ~/.zshrc:

# Quick status
alias dps='docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}" | sort'
alias dpa='docker ps -a --format "table {{.Names}}\t{{.Status}}\t{{.Image}}" | sort'

# Compose shortcuts
alias dc='docker compose'
alias dcu='docker compose up -d'
alias dcd='docker compose down'
alias dcl='docker compose logs -f --tail 50'
alias dcp='docker compose pull && docker compose up -d'

# Debugging
alias dlog='docker logs -f --tail 100'
alias dexec='docker exec -it'
alias dstats='docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}" | sort'

# Cleanup
alias dprune='docker system prune -af && docker volume prune -f'

Script for Updating All Stacks

#!/bin/bash
# update-all-stacks.sh — Pull and recreate all compose stacks

STACKS_DIR="/opt/stacks"

for stack_dir in "$STACKS_DIR"/*/; do
    stack_name=$(basename "$stack_dir")

    if [ -f "$stack_dir/compose.yaml" ] || [ -f "$stack_dir/docker-compose.yml" ]; then
        echo "=== Updating $stack_name ==="
        cd "$stack_dir"
        docker compose pull 2>&1 | grep -v "up to date"
        docker compose up -d --remove-orphans 2>&1
        echo ""
    fi
done

echo "=== Cleaning up old images ==="
docker image prune -af

echo "=== Done ==="

When to Use CLI Only

• You're automating everything with scripts
• You manage a small number of containers (< 10)
• You prefer direct control over abstraction layers
• You're comfortable with Docker commands and don't want another tool to maintain
• You're writing CI/CD pipelines

Container Update Strategies

Regardless of which management tool you use, keeping containers updated is important for security. Here are the options:

Watchtower (Automatic Updates)

services:
  watchtower:
    image: containrrr/watchtower
    container_name: watchtower
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - WATCHTOWER_CLEANUP=true
      - WATCHTOWER_SCHEDULE=0 0 4 * * *    # 4 AM daily
      - WATCHTOWER_NOTIFICATIONS=shoutrrr
      - WATCHTOWER_NOTIFICATION_URL=discord://webhook-token@webhook-id
      # Only update specific containers (safer):
      # - WATCHTOWER_LABEL_ENABLE=true
    # With label filtering, only containers with this label get updated:
    # labels:
    #   - "com.centurylinklabs.watchtower.enable=true"

Caution: Automatic updates can break things. Use label-based filtering to only auto-update containers you're confident won't have breaking changes (simple services, not databases).

Diun (Update Notifications Only)

Diun notifies you when new images are available without automatically updating:

services:
  diun:
    image: crazymax/diun:latest
    container_name: diun
    restart: unless-stopped
    volumes:
      - ./diun-data:/data
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - DIUN_WATCH_SCHEDULE=0 */6 * * *
      - DIUN_PROVIDERS_DOCKER=true
      - DIUN_NOTIF_DISCORD_WEBHOOKURL=https://discord.com/api/webhooks/...

This is the safer approach — you get notified, review the changelog, and update manually when ready.

Choosing Your Tool

Single Host, GUI Preferred

Dockge is the best choice. It's lightweight, compose-focused, and stores files on disk where they belong. You get a clean UI without the overhead of Portainer.

Single Host, Terminal Preferred

Lazydocker for monitoring and quick actions, CLI with aliases for deployment and updates. This combination is fast and lightweight.

Multiple Hosts

Portainer is the only option on this list that handles multi-host management well. The agent-based architecture means you can manage all your Docker hosts from a single dashboard.

Large Stack Count (30+)

Portainer for the overview and management, with compose files in a Git repository for version control. Use Portainer's Git integration to deploy from your repo.

Learning Docker

Start with the CLI. Every management tool abstracts the CLI commands — understanding what's happening underneath makes you better at debugging and more confident when something breaks. Add Lazydocker when you want faster status checks, and Dockge when you want a compose editor.

Combining Tools

There's no rule that says you can only use one tool. A practical combination:

1. Dockge for day-to-day stack management (starting, stopping, editing compose files)
2. Lazydocker for quick terminal-based monitoring and log viewing
3. CLI aliases for scripted updates and automation
4. Diun for update notifications

This gives you a web UI when you want it, a terminal UI when you're already in SSH, and automation for the routine tasks.

Final Thoughts

Container management tools exist on a spectrum from "do everything" (Portainer) to "do nothing extra" (CLI). The right choice depends on how many containers you run, how many hosts you manage, and whether you prefer clicking or typing.

For most homelabbers with a single Docker host and 10-30 containers, Dockge hits the sweet spot. It's simple enough to learn in five minutes, it stores your compose files as real files, and it stays out of your way. If you outgrow it, Portainer is there. If you prefer the terminal, Lazydocker is there.

The most important thing is that you can see what's running, check logs quickly, and update safely. Any tool that gives you that is the right tool for you.