Dockge

Last reviewed Aug 26, 2026 · 760 words

Dockge will only manage Compose stacks that live in one directory, and that directory must be mounted at the same path inside the container as on the host. Get that right and the rest of the setup takes 1 minute; get it wrong and the UI shows an empty list and you spend an evening on GitHub issues. It comes from the author of Uptime Kuma, shares its reactive, socket-driven UI, is MIT-licensed TypeScript with 24,157 stars, idles in about 128 MB, and its whole pitch is that it does one thing, docker compose, with a text editor and a terminal next to it.

The stacks directory is the design, not a limitation

Dockge's model is a folder per stack, each holding a compose.yaml, under a root that defaults to /opt/stacks. The container edits those files directly and runs Compose against them, which is why the host path and container path must match, and why the compose file that runs Dockge itself looks like this:

services:
  dockge:
    image: louislam/dockge:1
    restart: unless-stopped
    ports: ["5001:5001"]
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./data:/app/data
      - /opt/stacks:/opt/stacks
    environment:
      - DOCKGE_STACKS_DIR=/opt/stacks

The upside is that nothing is hidden: the files on disk are the source of truth, you can edit them with vim over SSH and Dockge notices, and if you delete Dockge tomorrow every stack keeps running from plain files. Stacks you already have in ~/docker/whatever are invisible until you move them under the root, and moving a running stack means bringing it down first, so migration day is the one bit of planning.

The editor and terminal are why people switch

Each stack gets a page with a YAML editor on the left and a .env editor beside it, start, stop, restart, update, and down buttons, and a live terminal that streams the output of whatever Compose is doing, so a failing pull or a bad indent is visible in the same window rather than in a container log you have to go and find. A bash shell into any running container is one click away. The "convert docker run to compose" box takes a pasted one-liner from a project README and turns it into a stack, which is a small feature that saves beginners a lot. The Compose patterns post covers how I lay stacks out so this workflow stays tidy.

What it deliberately does not do

No image browser, no volume manager, no network editor, no Kubernetes, no Swarm, no user roles beyond a single login. Dockge does not try to be the control plane for a fleet; it manages the stacks on one host, plus additional hosts running their own Dockge that you link as agents from the main UI, which covers a 3-box homelab without a database. If you need per-user access, registries, templates, or a Kubernetes view, that is Portainer's job and Dockge does not pretend otherwise. For image updates, pair it with Watchtower or use Dockge's own update button per stack, which pulls and recreates that stack only, the safer of the two. There is no scheduled backup of the stacks directory either, so the nightly job that copies /opt/stacks off the box is yours to write, and it should exist before the first stack moves in.

Where it fits next to a terminal tool

I run lazydocker for logs and stats when I am already in SSH, and Dockge for editing stacks from a browser, including from a phone when something needs a restart and I am not at a desk. They do not overlap: one is a viewer, the other is an editor. What Dockge replaces is the habit of keeping a dozen compose files scattered across a home directory with no memory of which flags you ran them with.

What I'd do

Move every stack under /opt/stacks on a quiet afternoon, one at a time, with docker compose down then up -d from the new location, then install Dockge with the file above and put it behind your proxy with authentication in front of the socket-holding container. Keep its data directory in your backups because it holds the login and the agent list, but treat the stacks directory as the thing that actually matters. If you are a beginner choosing your first container UI, choose this one: it teaches Compose instead of hiding it.