Lazydocker Terminal UI: 5 Practical Ways to Simplify Docker

Managing Docker from the command line means juggling half a dozen commands. docker ps, docker logs, docker exec, docker stats, repeat until your history is a mess. The lazydocker terminal UI puts all of that in one keyboard-driven dashboard. Written in Go by Jesse Duffield, the same developer behind lazygit, it shows your containers, images, volumes, and logs in a single terminal window. No mouse needed, no browser-based dashboard eating 300 MB of RAM.

I started using the lazydocker terminal UI after getting tired of running docker stats in one tmux pane and docker logs -f in another. Now one tool does both, plus cleanup, plus restarts.

Why the lazydocker terminal UI beats raw docker commands

The core problem with the Docker CLI is that it has no state. Every question needs a new command, and every command needs a container ID or name you have to look up first. Lazydocker keeps everything on screen at once.

The layout is simple. A panel on the left lists your projects, containers, images, and volumes. The main panel on the right shows details for whatever you select: live logs, stats graphs, config, or the top processes inside a container. Switching between them takes one keystroke.

The lazydocker terminal UI also handles the tasks that normally require typing out long commands. Restarting a container is r. Removing it is d. Attaching a shell is E. Pruning unused images is b for bulk commands. That last one alone saves me from googling docker system prune flags every month.

Installing lazydocker

On Debian and Ubuntu there is no official apt package yet, so the quickest route is the install script from the lazydocker GitHub repository:

curl https://raw.githubusercontent.com/jesseduffield/lazydocker/master/scripts/install_update_linux.sh | bash

If you avoid curl-to-bash installs on principle (fair), grab the binary from the releases page instead:

wget https://github.com/jesseduffield/lazydocker/releases/latest/download/lazydocker_0.24.1_Linux_x86_64.tar.gz
tar xf lazydocker_0.24.1_Linux_x86_64.tar.gz lazydocker
sudo install lazydocker /usr/local/bin

Arch users get it from the official repos with pacman -S lazydocker, and Homebrew handles Mac and Linuxbrew with brew install lazydocker. There is also an official Docker image, which feels appropriately recursive:

docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock lazyteam/lazydocker

Run lazydocker with no arguments and the lazydocker terminal UI opens. Your user needs access to the Docker socket, so either be in the docker group or run it with sudo.

Getting around the lazydocker terminal UI

Navigation follows vim conventions, which makes sense given the lazygit heritage. If you already use lazygit for git operations, your muscle memory transfers directly.

• j/k or arrow keys: move up and down within a panel
• h/l or Tab: switch between panels
• [ and ]: cycle tabs in the main panel (logs, stats, config, top)
• x: open the menu with every action available for the selected item
• q: quit

The x menu is the safety net. Forget a keybinding and it lists everything in context. After a week you stop needing it.

Select a container and press Enter to focus its logs. The stats tab draws live CPU and memory graphs in ASCII, which sounds like a gimmick until you spot a memory leak climbing in real time without leaving your terminal.

Managing containers day to day

Here is my routine when a compose stack misbehaves. Open the lazydocker terminal UI, scan the containers panel for anything red, hit Enter on the suspect to tail its logs, then r to restart it once I see the cause. Total time, maybe twenty seconds. The same dance with plain docker commands takes five commands and two ID lookups.

For docker compose projects, the lazydocker terminal UI groups containers by project automatically. You can restart a whole stack, view merged logs across services, or drop into a single service. It reads your compose file and shows the config the container actually launched with, which has settled more than one “but the YAML says otherwise” argument for me.

The bulk commands menu (b) covers pruning. Stopped containers, dangling images, unused volumes, all removable in two keystrokes. On a build server this matters. I have reclaimed 40 GB in one sitting from accumulated image layers. If you want to know exactly which layers are bloating a specific image before you prune, dive digs into image layers in a way lazydocker does not try to replicate.

Customizing the lazydocker terminal UI

Configuration lives in ~/.config/lazydocker/config.yml. Press o inside the tool to open it. The defaults are sensible, but two tweaks are worth making.

First, custom commands. You can bind your own shell commands to keys, templated with the selected container’s attributes. I have one that opens a shell as root and another that copies the container IP to the clipboard:

customCommands:
  containers:
    - name: bash as root
      attach: true
      command: docker exec -it -u root {{ .Container.ID }} /bin/bash

Second, the stats graphs. By default the memory graph shows raw usage. Switching it to a percentage scale makes cross-container comparison readable. The Docker CLI reference documents the underlying stats fields if you want to graph something custom, and lazydocker accepts any of them in its config.

Where it fits, and where it does not

The lazydocker terminal UI is a single-host tool. It talks to one Docker socket and does that well. It will not manage a Kubernetes cluster, and it does not pretend to. For clusters, k9s covers Kubernetes with a similar keyboard-driven approach, and the two tools make a natural pair on any machine that runs both workloads.

It is also not a monitoring system. The stats graphs reset when you close the tool, and nothing is recorded or alerted on. Treat it as a live window, not a history. For anything you need to graph over days, you still want Prometheus and cAdvisor.

Within those limits, the lazydocker terminal UI has replaced a dozen aliases in my shell config. It is a 15 MB binary with no dependencies beyond the Docker socket, it starts instantly over SSH, and the keybindings stick after a day of use. If containers are part of your daily work, install it and give it that day.