Isaiah: a web front end for lazydocker's Docker fleet workflow
Self-hostable clone of lazydocker for the web. Manage your Docker fleet with ease
At a glance
- What is it?
- Isaiah is a Go server that exposes Docker resource management over a websocket-driven browser UI, aimed at people who want lazydocker's controls without a terminal. The trade-off is a read-only Docker socket mount, a single master password, and a Stack feature that requires Docker 26 or newer.
- Who is it for?
- Adopt Isaiah if you already like lazydocker's model of managing stacks, containers, images, volumes and networks from one screen and you want that screen in a browser, on a phone, or behind an SSO proxy. Skip it if you need per-user roles, an audit trail, or a multi-tenant control plane; the README describes a single master password and proxy-header authentication, not an account system.
- 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 47 days ago.
- What is it written in?
- Mainly Go, 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 Isaiah fills between lazydocker and a browser tab
lazydocker is a terminal UI. That is fine when you are already at a shell on the machine running the daemon, and awkward when you are not. The README frames Isaiah as an attempt at recreating that command-line application from scratch while making it available as a web application without compromising on the features. The target user is therefore someone who runs a Docker host, likes the lazydocker interaction model of one screen showing stacks, containers, images, volumes and networks, and wants to reach it from a laptop, a tablet or a phone. It is not a Kubernetes dashboard, not a CI system, and not a registry. The scope is deliberately the Docker object model plus a terminal emulator and a compose file editor. If your fleet is one VPS running a handful of compose projects, that scope is the whole job.
How the Go server and the websocket client divide the work
The README states the server is written in Go and the client in Vanilla JS, that the binary is a single file of roughly 4 MB, that the Docker image is also roughly 4 MB, and that the application works exclusively over Websocket with very little bandwidth usage. It also states that 100% of the Docker features are implemented through the official Docker SDK. So the data flow is: browser holds a websocket, the Go process holds the Docker SDK client, and every action (restart a container, stream logs, open a shell) is a message on that socket rather than a REST round trip. Log streaming and the built-in terminal emulator fit that model naturally, because both are long-lived byte streams. The practical consequence is that a reverse proxy in front of Isaiah must pass websocket upgrades, not just plain HTTP. The README lists a proxy example compose file for exactly that reason, and the SSL example terminates HTTPS on port 443 with mounted certificate and key volumes.
Deployment commands and the .env keys that matter
The README gives three docker run forms. The attached form is docker run --env-file .env -v /var/run/docker.sock:/var/run/docker.sock:ro -p <YOUR-PORT-MAPPING> mosswill/isaiah, the daemon form adds -d, and the quick form is docker run -v /var/run/docker.sock:/var/run/docker.sock:ro -p 3000:3000 mosswill/isaiah. Note the :ro suffix on the socket mount in every example. Since version 1.36.2 the images are also mirrored on GitHub, so ghcr.io/will-moss/isaiah:latest is an alternative pull source. Configuration is described as extensive and supplied through .env, and authentication accepts a master password either raw or as a sha256 hash. The README states the default password is one-very-long-and-mysterious-secret, which is a string you must change before the port is reachable from anywhere you do not control. The examples directory ships docker-compose.simple.yml (front-facing on port 80, variables inline), docker-compose.volume.yml (same, variables from a mounted .env), docker-compose.ssl.yml (port 443 with mounted certificate and key), docker-compose.proxy.yml (Isaiah on 80 behind a proxy on 443), and docker-compose.traefik.yml. The README also warns that Docker 23.0.0 or newer is required, and 26.0.0 or newer if you use the Stacks feature.
Multi-node and multi-host: two different deployment shapes
The table of contents separates multi-node deployment from multi-host deployment, and the distinction is worth reading before you pick one. Multi-node appears to describe running several Isaiah instances, while multi-host is about pointing the tool at more than one Docker host or context; the features list confirms support for a custom Docker host or context and for standalone, proxy, multi-node and multi-host deployment. The README does not spell out the topology in the excerpt available here, so treat the two sections as required reading rather than relying on the naming. What is clear is that host discovery is built in, which matters if you run Docker contexts locally and want Isaiah to enumerate them instead of you typing an endpoint per host. If your fleet spans machines that cannot see each other's daemons, this is the part of the documentation to verify first, because the deployment shape determines whether you need one instance or several.
Where Isaiah is the wrong tool
The socket is mounted read-only in every documented example, yet the feature list includes removing containers, pruning images and volumes, and editing compose stacks. That combination is only coherent if Isaiah talks to the daemon over the socket for reads and performs mutations through some other path, or if the read-only mount is a hardening default that limits what the container itself can do to the host filesystem rather than what the Docker API permits. The README does not resolve this, and it is the single thing I would test before trusting the tool with a production host. Separately, the authentication model is a master password or forward proxy headers such as Authelia. There is no mention of user accounts, roles, or an audit log. Anyone who can reach the port and knows the password has the same powers as everyone else. On a shared team that is a real constraint, and it is the reason I would not put Isaiah in front of a host that other people's workloads depend on without an authenticating proxy in front of it.
Isaiah against Portainer, and against staying in the terminal
Portainer is the obvious comparison and the difference is architectural. Portainer is built around a server-side API with users, teams, roles and endpoints, and its UI is a management console for organisations. Isaiah is built around one websocket per browser session and one Docker SDK client, with a master password as the gate. The feature lists overlap heavily for a single operator: both start and stop containers, stream logs, open consoles, and manage stacks. They diverge the moment you need to know who did what, or to give a contractor access to one stack and nothing else. The other alternative is simply not installing anything: lazydocker over SSH already does most of this, and the README says Isaiah is a recreation of it, so the honest question is whether browser access is worth running another service with a Docker socket mount. If you mostly work from one workstation with a terminal, it is not. If you want the same controls from a phone, or you want to hand a colleague a URL instead of an SSH key, it is.
Maintenance cost and what the MIT licence leaves you with
The release history shows 1.36.1 and 1.36.2 in July 2025, then 1.36.9 in February 2026, with the last push to the repository in July 2026. That is a project that ships fixes but not on a schedule you can plan around, so pin a tag rather than tracking latest if you care about reproducibility. Upgrades are cheap by design: the README describes a single binary and a roughly 4 MB image, and it has an Updating section under standalone deployment, which suggests the intended path is replacing the binary or pulling a new image rather than running migrations. The licence is MIT, which permits commercial use and modification; it also means there is no warranty and no support obligation, and if you fork it you carry the maintenance yourself. The README includes a Security section and a Disclaimer, both of which are worth reading in full before you expose the port, because the disclaimer is where a project of this shape usually states what it will not protect you from.
Editorial conclusion
Adopt Isaiah if you already like lazydocker's model of managing stacks, containers, images, volumes and networks from one screen and you want that screen in a browser, on a phone, or behind an SSO proxy. Skip it if you need per-user roles, an audit trail, or a multi-tenant control plane; the README describes a single master password and proxy-header authentication, not an account system. Before deploying, verify three things against your own host: that Docker is at 23.0.0 or newer (26.0.0 or newer if you intend to use the Stacks feature), that your compose files sit where Isaiah expects to find them, and that you have replaced the default password one-very-long-and-mysterious-secret in your .env file.
Community notes