Dockly: a terminal UI for Docker containers, services and images

What Dockly solves, and for whom

Docker's own command line is a query language. You type docker ps, read a wide table, copy an ID, then type docker logs with that ID. Dockly replaces that loop with a full-screen terminal interface that lists containers, services and images and lets you act on the selected row. It is aimed at engineers who already work inside a terminal and want container state visible without leaving it, and at people running a single Docker host or a small Swarm where a browser dashboard is more setup than the job deserves. The README describes the project as an "immersive terminal interface for managing docker containers, services and images", and the repository topics (cli, command-line-tool, console, containers, docker) match that framing. It is not a control plane. There is no declarative file describing desired state, no scheduling, and no fleet view. If your mental model is a YAML file that a controller reconciles, Dockly is the wrong shape of tool.

How Dockly talks to the Docker daemon

The architecture is a Node.js process that renders a terminal UI and forwards operations to the Docker Engine API. The package.json dependency list names dockerode, the Node client for that API, alongside blessed and blessed-contrib for the interface, command-line-args and command-line-usage for the CLI surface, and clipboardy for copying values out. The README states that firing up dockly connects automatically to the localhost daemon through the unix socket, so the default data flow is: Dockly process, unix socket at /var/run/docker.sock, Docker daemon. Everything you see is a rendering of API responses, not a cached state file. That has a practical consequence: when the daemon is unreachable or the socket path is wrong, the interface has nothing to show, and there is no offline mode. The repository layout separates src/, lib/, widgets/ and hooks/, which suggests the UI widgets and the Docker-calling layer are kept apart, but the README does not document an internal plugin API, so extending it means working in the source.

Installing Dockly and a first real session

Dockly ships on npm as a global binary. The README's install section gives a single command, and the repository's bin field maps the dockly executable to ./index.js, so the installed command and the source entry point are the same file.

npm install -g dockly

With the binary on your PATH, start it with no arguments. According to the README, this connects to the localhost daemon through the unix socket, and you should see the terminal interface populate with your containers.

dockly

If you want to point it at a different daemon, the README documents -s or --socketPath for a socket, and -H or --host, -P or --port and -T or --protocol for a remote daemon, where the protocol is one of http, https or ssh. To narrow a long container list, --containerFilters takes an x-www-form-urlencoded string in the format used by the Docker Engine container list endpoint. The README's own example is:

dockly --containerFilters="name=test&status=running"

That filter shows only running containers whose name matches test. If you would rather not install Node.js locally, the README gives a Docker invocation that mounts the host socket into the container so the daemon sees the same endpoint:

docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock lirantal/dockly

The repository Dockerfile builds the same image from node:24-alpine, sets LANG and LC_ALL to C.UTF-8, and uses node index.js as the entrypoint.

Runtime requirements and the failure modes they cause

The most common failure is version drift, and the project documents it directly. The README's first FAQ entry shows two stack traces, a SyntaxError on a default parameter in src/screen.js and a TypeError about Object.values, and attributes both to an unsupported Node.js version, stating that Dockly requires Node.js v7.6 and above. The current package.json engines field is stricter than the README text: it asks for node >=24.0.0 and npm >=11.10.0. That gap matters. Someone reading only the README may install on a Node version that satisfies the prose but not the manifest, and npm's engine handling varies by configuration. Treat the engines field as the real floor and the README line as historical. A second documented failure is cosmetic but disruptive: the README FAQ says icons may not work properly and recommends exporting LANG and LC_ALL as C.UTF-8. The Dockerfile already sets both, which is why the container path avoids the problem while a local install may hit it. The third is the socket itself. Running Dockly inside a container without mounting /var/run/docker.sock leaves it with no daemon to talk to, and the README's run command exists precisely to avoid that.

Where Dockly is the wrong tool

Dockly assumes one daemon endpoint per session. The command line options let you choose which endpoint, but there is no documented notion of switching between several hosts inside the interface, and no aggregation across them. For a Swarm or a multi-node cluster the README's framing around "services" is the closest it gets; the package keywords list swarm, but the documentation does not describe cluster-level scheduling or node management. If your work is defining what should run rather than observing what is running, Dockly cannot express it. There is also no documented audit trail or change history: actions are issued against the daemon and the interface reflects the result. Teams that need an approval record for every container restart should look elsewhere. Finally, the interface is a terminal UI, so it is unusable in a script or a CI job. Dockly is for a human at a keyboard, and the README's own usage section is written that way.

Dockly and Lazydocker: two terminal UIs, different bets

The closest comparison a reader is likely to make is Lazydocker, which appears repeatedly in the search phrases around this project. Both render Docker state in a terminal and both are keyboard-driven, so the difference is not the pitch but the implementation and the surrounding ecosystem. Dockly is a Node.js package installed through npm, built on blessed and blessed-contrib, and its extension path is the JavaScript source in src/, lib/ and widgets/. Lazydocker is a separate project with its own distribution and its own interface conventions, and the README of Dockly does not attempt a feature comparison. The honest way to choose is to look at what you already run: if your toolchain is Node-based and you want to read or patch the UI code in a language you already use, Dockly's stack is the shorter path. If you want a single self-contained binary and no Node runtime on the host, that is a different bet. Note that the README's alternatives section does not name Lazydocker at all. It points at the terminal section of the Awesome Docker list, which is a catalogue rather than a recommendation.

Licence, maintenance and what an upgrade costs

Dockly is MIT licensed, and the LICENSE file sits at the repository root. For most users that means you can run it, modify it and ship it inside a product without a copyleft obligation, but the usual caveat applies: this is a description of the licence identifier, not legal advice, and if you are redistributing it as part of something commercial, read the file yourself. On maintenance, the last push to the repository was on 2026-07-23, and the most recent release listed is v3.24.5 from 2025-04-17, with v3.24.4 in February 2025 and v3.24.3 in June 2024. The repository is not archived. The release cadence is uneven, so pinning matters. The package.json version is 0.0.0-development, which is the conventional placeholder used when the publish pipeline stamps the real version at release time; installing from npm gets you a published version, not that placeholder. Upgrading is a global npm install, and the thing that will break is the runtime floor: because engines now requires node >=24.0.0, a host that satisfied an older Dockly will not satisfy this one without a Node upgrade first. Check that before you upgrade, not after.

Editorial conclusion

Adopt Dockly if you spend your day in a terminal on a single Docker host and want container and service state a keystroke away; skip it if you need declarative configuration, multi-host orchestration or a browser UI. Before rolling it out, check that the runtime satisfies the package.json engines field (node >=24.0.0, npm >=11.10.0), that the daemon socket path matches your setup, and that your terminal locale is set to C.UTF-8 so the icon glyphs render.

Frequently asked questions

Official sources

1. License: MIT
2. lirantal/dockly on GitHub
3. Project website
4. README
5. Releases