Ducker: a k9s-style terminal UI for Docker containers, images, volumes and networks
A slightly quackers Docker TUI based on k9s 🦆
At a glance
- What is it?
- Ducker is a Rust TUI that puts Docker container, image, volume and network management behind a k9s-inspired command prompt and hotkey layout. It is a thin, keyboard-driven front end over the local Docker daemon, and its README is candid about the parts that are still rough.
- Who is it for?
- Adopt Ducker if you already live in a terminal, you think in k9s keybindings, and you want container, image, volume and network actions without leaving the shell. Skip it if your workflow depends on exec into images without bash, on reliable network deletion feedback, or on a pre-built binary you can drop onto a machine with no Rust toolchain.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 44 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Ducker fills between docker ps and a full dashboard
Docker's own CLI is precise but chatty. Listing containers, reading logs, stopping one, removing an image and pruning dangling volumes means several commands, and each one prints a wall of text you have to scan by eye. Browser dashboards solve the scanning problem but add a daemon, a port and a session outside your terminal. Ducker targets the middle: a single terminal window that shows the containers, images, volumes and networks on the host and lets you act on the selected row with one keypress. The README describes it as "a terminal app for managing docker containers, inspired by K9s", and the audience is anyone who already knows k9s or lazydocker-style tools and wants the same muscle memory for Docker. It is written in Rust and published under the MIT licence, so the binary is a single native executable rather than a runtime you have to host.
Pages, a command prompt and hotkey actions
The interaction model has three pieces. Pages are the top-level views: images, containers, volumes, networks and help. You reach a page by typing a command into the prompt, which opens with the colon key. The README lists the commands and their aliases: images or image, containers or container, volumes or volume, networks or network, help or h, and quit or q. Actions are hotkeys that operate on whatever row is currently selected. A legend for global hotkeys sits at the bottom of the screen, and a contextual legend for the current page sits in the top right. Navigation is vim-flavoured: k and the up arrow move up, j and the down arrow move down, g jumps to the top of a list or table and G to the bottom. On the Containers page the actions are r to run, s to stop, Ctrl+d to delete, l to view logs and a to exec into the selected container. The Images, Volumes and Networks pages each expose Ctrl+d for deletion, d to describe the selected item, and Alt+d on Images and Volumes to toggle dangling entries. Sorting is per page and uses Shift plus a column letter, and pressing the same sort key again reverses the order. Containers sort by name, image, status, created or ports; Images by name, created, tag or size; Networks by name, created, scope or driver. The data flow is direct: the TUI calls the local Docker daemon, renders the result with ratatui-rs, and sends actions back as Docker API calls. There is no agent, no server component and no remote mode described in the README.
Installing Ducker on Linux, macOS and Nix systems
There is no downloadable pre-built binary. The README states that installing from source requires cargo 1.88 or higher, and gives cargo install --locked ducker as the command. The --locked flag is not optional advice: the README warns that installing without it makes the build susceptible to changes in upstream dependencies that could break it. Arch Linux users can install from the official repositories with pacman -S ducker. Homebrew users can run brew install ducker. Ducker is packaged in nixpkgs, so nix-shell -p ducker gives a throwaway shell and nix run nixpkgs#ducker runs it directly with flakes enabled; persistent installation means adding pkgs.ducker to environment.systemPackages in configuration.nix. For the bleeding edge there is cargo install --git https://github.com/robertpsoane/ducker, which the README labels as the unstable version. The README does not document any configuration file, environment variable or config key. The Configuration anchor in the header points at a section that is not present in the supplied material, so if you need to change keybindings or point Ducker at a non-default Docker socket, treat that as unverified and check the repository before assuming it is supported.
Exec only works with bash, and network deletion is unfinished
Two limitations are documented by the maintainer rather than discovered by users. The first is exec. The Containers page binds a to exec into the selected container, but the README adds a direct note: exec currently only supports containers with bash installed, and the intention is to update it to provide a user option. That rules out a large class of images by default. Alpine-based containers, distroless images, and anything built from scratch will not give you a shell through Ducker, even though docker exec works fine against them from the CLI. The second is network deletion. The README states that a failed deletion currently results in a yes/no modal telling you it could not be deleted, and that there is no difference between the yes and no results. The maintainer calls this "a quick and dirty hack to get them set up" and says it will be patched once a generic modal exists. The practical consequence is that a failed network delete is a dead end in the UI: you get told it failed, you answer a question that does not change anything, and you go back to the docker network rm command to find out why. Neither issue is hidden, which is worth something, but both are real friction points in daily use.
How Ducker differs from k9s and from browser dashboards
The obvious comparison is k9s, and it is the comparison the project invites. k9s manages Kubernetes clusters: it talks to the API server, understands namespaces, pods, deployments and the rest of the object model, and its actions map onto kubectl verbs. Ducker manages a single local Docker daemon and its four resource types: containers, images, volumes and networks. That narrower scope is the whole point. If your work is Kubernetes, Ducker is the wrong tool and k9s already covers it. If your work is a handful of Docker containers on a laptop or a build box, k9s has nothing to say about them, and a browser dashboard like Portainer asks you to run and secure another service to do what Ducker does from a binary in your PATH. The trade is capability for weight. Ducker will not show you compose stacks as a unit, it will not manage a swarm, and it will not give you a remote host by default. What it does give you is the k9s interaction pattern applied to the Docker objects on the machine you are already sitting at, which for a lot of development and debugging work is the entire job.
Release cadence, licence and what maintenance costs you
Ducker is MIT-licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is a permissive arrangement, and it matters here because Ducker is a client that shells out to your Docker daemon rather than a service you deploy. Nothing about the licence obliges you to publish changes, and there is no copyleft clause reaching into your own tooling. On maintenance, the release history shows a steady patch cadence: v0.6.3 in February 2026, v0.6.4 and v0.6.5 in March 2026, with the most recent push to the repository in August 2026. The version numbers are still in the 0.6 range, which is consistent with the unfinished areas the README describes. Upgrading is cheap if you installed through a package manager: pacman, brew and nixpkgs each carry their own update path. Source installs are the ones to watch, because the README's own warning about --locked exists precisely because upstream dependency drift can break a build. If you install from git rather than from a release tag, you are tracking master and should expect to rebuild when the dependency tree moves. There is no migration story to worry about, since the README documents no on-disk state or configuration file that a version bump could invalidate.
Who should run Ducker and what to check first
Ducker fits engineers who keep a terminal open all day, who already use k9s or a similar keyboard-driven TUI, and whose Docker work is local: iterating on a container, tailing its logs, restarting it, clearing out old images and dangling volumes. It fits less well in three cases. If you need to exec into slim or bash-less images, the documented bash-only restriction will send you back to docker exec. If you are managing networks as part of your routine, the unfinished failure modal means you will not trust what the UI tells you. And if you need a binary on a machine with no Rust toolchain and no package manager entry, the absence of a pre-built download is a hard stop, since cargo 1.88 or higher is required to build from source. The first thing to verify is the exec path against your own images, because that is the action most likely to be used and the one with the clearest documented limitation. The second is the Configuration section on the project homepage, since the README's table of contents points to it but the supplied material contains no configuration keys at all. Until that section is confirmed, assume defaults only.
Editorial conclusion
Adopt Ducker if you already live in a terminal, you think in k9s keybindings, and you want container, image, volume and network actions without leaving the shell. Skip it if your workflow depends on exec into images without bash, on reliable network deletion feedback, or on a pre-built binary you can drop onto a machine with no Rust toolchain. Before committing, install with cargo install --locked ducker, open the Containers page, and confirm that the exec action (a) works against the images your team actually runs, since the README states it currently only supports containers with bash installed.
Community notes