# luci-app-dockerman: managing Docker from the OpenWrt web interface

> luci-app-dockerman adds a Docker Manager interface to LuCI on OpenWrt, covering containers, images, networks and volumes, and it can drive a remote daemon as a client instead of running dockerd on the router.

**lisaac/luci-app-dockerman** — Docker Manager interface for LuCI

- Repository: https://github.com/lisaac/luci-app-dockerman
- Stars: 905 · Forks: 237
- Language: Lua
- License: AGPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/lisaac-luci-app-dockerman

## A Docker control panel that lives inside LuCI

luci-app-dockerman is a LuCI application for OpenWrt that manages Docker containers, images, networks and storage volumes. The placement is the point. On a router, the only interface most operators have is the LuCI web interface, and Docker on a router is a normal part of the job for anyone running services at the edge. This plugin puts the container lifecycle into that interface rather than leaving it to a command line over SSH. The repository is small in layout terms, with an applications/ directory holding the LuCI application code, a doc/ directory with the screenshots, and a .github/ directory. It is a front end, not a container runtime: the actual Docker engine is a separate concern, and the plugin's own dependency list makes that explicit by listing dockerd as optional and by naming a separate luci-lib-docker library as a required dependency.

## The four object types the interface covers

Looking at what the project page screenshots, the plugin is organised around Docker's own object model. There is a containers view, a container info page, a container edit page, a container stats page, and a container logs page, plus a dedicated new container screen. Images have their own list view, networks have a list view and a new network screen, and storage volumes are named in the feature list. That coverage is the practical argument for the plugin over driving the Docker API by hand: create, edit, inspect, watch and read logs for a container are all reachable from the same interface, and the stats and logs pages are the two that a remote daemon on a resource constrained router makes awkward over SSH. The project page is written bilingually, with a Chinese translation credited to a named contributor, which is a small signal about the audience the author had in mind.

## dockerd is optional, so the plugin can act as a client

The dependency list is where this project differs from the usual OpenWrt Docker packages. dockerd is marked optional, with the note that you can use the plugin as a Docker client, and the project page also points at two companion repositories, Openwrt-in-docker and LuCI-in-docker, for running the stack in a containerised arrangement. That gives two deployment shapes. The first is the native one, with Docker Community Edition installed on the router itself and the plugin talking to a local daemon, which is what the build instructions lead you through. The second is a client arrangement, where the LuCI plugin on the router is the control surface for a daemon that runs somewhere else, or on the same host in a container. The difference in approach is not cosmetic: with a local daemon the container shares the router's kernel, storage and network stack, whereas in the client arrangement the management plane and the workload are separated, which suits a setup that does not want the daemon competing with the router's own services.

## Installing the ipk and the packages it expects

The distribution method is a prebuilt ipk package, and the project page links the releases page for the download. There is no separate installer script and nothing to configure before the file is uploaded, so installation is the standard OpenWrt package flow: fetch the ipk, install it, and the LuCI application appears in the menu once its dependencies are satisfied. Those dependencies are worth reading before you download anything. luci-lib-docker is required and is itself a separate project in the same family. luci-lib-jsonc is required as well. Then there are the optional entries: dockerd, which is optional only because the plugin can run as a client, ttyd, described as being for the container console, and docker itself, also for the container console. The console path therefore depends on pieces that a bare installation will not have, which is the single most likely reason a new user finds the console view empty.

## Compiling the package inside an OpenWrt source tree

For anyone building rather than downloading, the project page gives the OpenWrt build system commands, and the first target compiles the shared library the application depends on:

```bash
#compile package only
make package/luci-lib-docker/compile v=99
make package/luci-app-dockerman/compile v=99
```

The full path goes through the configuration menu first:

```bash
#compile
make menuconfig
#choose Utilities  ---> <*> docker....................................... Docker Community Edition
#choose Kernel features for Docker which you want
#choose LuCI ---> 3. Applications  ---> <*> luci-app-dockerman..... Docker Manager interface for LuCI ----> save
make V=99
```

The menu path is worth reading twice. The application is selected under LuCI, then Applications, and the Docker Community Edition package lives under Utilities, with kernel features for Docker chosen as well. A build that produces no application is usually a configuration miss rather than a compiler problem, and the verbose flags on the compile targets are there to show which stage failed. The second command in the pair matters as well, because the library package has to be built for the application to have something to depend on.

## Container console, logs and the optional pieces behind them

Two features of the interface are explicitly tied to optional software. The container console uses ttyd, and the project page lists docker as an optional dependency for the container console as well, while the logs view is one of the screens shown in the screenshots. A terminal in a browser is genuinely useful on a device with no keyboard or screen of its own, which is a common situation for a router, and it is also the feature most likely to need the extra packages installed. A related constraint is that a console and a stats view both talk to the daemon continuously, so on a router with little memory the operation of the plugin itself becomes part of the resource budget. Neither the memory footprint nor the polling behaviour of the stats view is described in the project page, so neither can be taken for granted when sizing a device.

## AGPL-3.0, and a release list that lags the last commit

The plugin is distributed under the GNU Affero General Public License version 3, with the LICENSE file at the repository root, and the interface ships Chinese and English text, which adds a translation maintenance load on top of the code. The version history is the other thing to look at before you rely on it. The tagged releases stop at v0.5.26 on 2023-07-06, with v0.5.25 in October 2021 and v0.5.24 in September 2021, yet the last push to the repository was on 2026-09-21 and the repository is not archived. So the ipk files linked from the releases page are considerably older than the code in the branch, and a system that installs the latest tag is not installing the latest work. Whether that gap matters depends on the OpenWrt release and the LuCI version in your image, and that is a comparison to make in the browser on the router before updating. A Telegram group is linked from the project page for support.

## Conclusion

luci-app-dockerman fits an OpenWrt operator who wants to run and inspect containers from the LuCI web interface without logging in over SSH for every change, and it does not suit a server operator who wants a general container platform, since the scope is the LuCI interface. Verify three things before installing: that the ipk you download matches your LuCI version, whether the plugin will talk to a local dockerd or act as a Docker client against a daemon elsewhere, and whether the container console and log views work for you, since ttyd and docker are listed as optional dependencies for that path.

## FAQ

### What does luci-app-dockerman do on OpenWrt?

It adds a Docker Manager interface to LuCI covering containers, images, networks and storage volumes, with views for container info, editing, statistics and logs.

### Do I need dockerd installed for luci-app-dockerman?

No. The project lists dockerd as an optional dependency, since the plugin can be used as a Docker client, and it also points at the Openwrt-in-docker and LuCI-in-docker arrangements.

### How do I install luci-app-dockerman?

Download the ipk package from the project releases page and install it through the usual OpenWrt package flow, with luci-lib-docker and luci-lib-jsonc as required dependencies and ttyd and docker optional for the container console.

### How do I build luci-app-dockerman from source?

In an OpenWrt source tree, build the luci-lib-docker package and then the application, or select Utilities, then docker, and LuCI, then Applications, then luci-app-dockerman in make menuconfig before running make V=99.

## Sources

- [Issues](https://github.com/lisaac/luci-app-dockerman/issues)
- [License: AGPL-3.0](https://github.com/lisaac/luci-app-dockerman/blob/master/LICENSE)
- [lisaac/luci-app-dockerman on GitHub](https://github.com/lisaac/luci-app-dockerman)
- [README](https://github.com/lisaac/luci-app-dockerman/blob/master/README.md)
- [Releases](https://github.com/lisaac/luci-app-dockerman/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lisaac-luci-app-dockerman