Dockge Setup: The Compose Manager That Does Less On Purpose (2026)

By LK Wood IV · 2026-08-15 · ~7 min read · St. Louis County, MO

Dockge is a web UI over a folder of docker-compose.yaml files. That sentence is the entire product. I mean it as praise.

The install is one container. Five minutes, most of it waiting on a pull. The thing worth reading this page for is the volume line in the middle of that file, because getting it wrong is the one failure the project cared enough about to put a warning emoji beside in its own README, and because it fails quietly rather than loudly.

The compose file

services:
  dockge:
    image: louislam/dockge:1
    restart: unless-stopped
    ports:
      - 5001:5001
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./data:/app/data
      # Both sides of this MUST be the same path. See below.
      - /opt/stacks:/opt/stacks
    environment:
      - DOCKGE_STACKS_DIR=/opt/stacks
      - PUID=1000
      - PGID=1000

mkdir -p /opt/dockge /opt/stacks && cd /opt/dockge
# save the file above as compose.yaml
docker compose up -d

Then open port 5001 and create the admin account. Done.

Before you run that: the stable image is old

I nearly published this page without checking. That would have been a disservice, so here it is up front, ahead of the install advice rather than buried in a caveats section at the bottom where nobody reads it.

Dockge 1.5.0 was released on 30 March 2025. On Docker Hub the tags 1, latest and 1.5.0 all resolve to one digest, and all three were last pushed that same day. The 1 tag in the compose file above is therefore an image that has not been rebuilt in roughly sixteen months.

The project is not abandoned. Master took commits into April 2026, and there is a nightly tag rebuilt daily from it, which I confirmed had been pushed the day I wrote this. What has stalled is the release. The gap between the code and the artefact you actually pull is the part that matters, and it is the part a version number on a README will never show you.

Now weigh that against the socket mount in the next section. This is a container holding root-equivalent access to your host, running an image whose base layers have not been refreshed in over a year. Those two facts are worse together than either is alone.

I still think it is worth running. On a LAN-only host, behind a proxy, on a homelab you could rebuild in an afternoon. I would not put it on anything internet-facing, and I would not put it on a machine whose loss would ruin a week. You can pin nightly for the newer code. Then you are on unreviewed daily builds, which is a different risk, not a smaller one.

Check the dates yourself before installing. They may well have moved since I wrote this:

curl -s "https://hub.docker.com/v2/repositories/louislam/dockge/tags?page_size=10&ordering=last_updated"   | python -c "import json,sys; [print(t['name'], t['last_updated'][:10]) for t in json.load(sys.stdin)['results']]"

The volume line

Look at the stacks mount again:

- /opt/stacks:/opt/stacks

Host path on the left, container path on the right. They are identical, and that is not stylistic. The README’s own examples are blunt about it — it marks /my-stacks:/my-stacks correct because both paths match, and /docker:/my-stacks wrong because they do not, with the warning that your data could end up written into a wrong path.

Here is why. “Just do it” is unsatisfying, and you will meet this shape again.

Dockge talks to the Docker daemon through the socket you mounted. When it asks the daemon to bring up a stack, the daemon resolves every path in that compose file on the host, not inside the Dockge container. So Dockge writes a compose file to what it believes is /opt/stacks/immich/compose.yaml, and the daemon goes looking for that same path on the host. If your bind was /docker:/opt/stacks, then Dockge’s /opt/stacks/immich is really /docker/immich on the host, and the two halves of the system now disagree about where your stacks live.

Make both sides identical and the disagreement cannot happen. It is the same class of problem as any socket-mounted tool that hands paths to the daemon, and the fix is always the same: agree with the host.

/opt/stacks is only a convention, and /srv/stacks:/srv/stacks would do just as well, because what the daemon cares about is that the two sides agree rather than what they agree on. Matching is the rule. The path is yours.

What it deliberately will not do

Dockge is compose-only. It will not manage standalone containers, networks, images, or the rest of the Docker surface Portainer covers.

I think that is the most interesting thing about it. It is also the part people get annoyed by, because they arrive expecting a Portainer swap and find something with a deliberately smaller footprint instead. If every workload you run is a compose stack — which, in a homelab, it usually is — then a tool that only does stacks has a much smaller surface to be confusing in. If you regularly poke at networks or one-off containers, Dockge will not cover that and you will keep a terminal open. Neither of those is a defect. They are just different jobs.

I compare it properly against the two obvious alternatives in Komodo vs Portainer vs Dockge, including the licensing change that pushed a lot of people to look in the first place.

Security, briefly, because the socket mount deserves it

That first volume line mounts the Docker socket into the container. Anything that can reach the Docker socket can start a container that mounts your host filesystem as root. That is not a partial privilege. It is root.

So the Dockge UI is not a dashboard. It is a root-equivalent control surface with a login form in front of it. Treat it that way:

• Do not publish 5001 to the internet. Put it behind Nginx Proxy Manager with a real certificate, or reach it over a tunnel and leave it on the LAN entirely.
• Give it a password you did not reuse.

If you already run Uptime Kuma, the same reasoning applies there and the same fix works for both.

PUID and PGID

The official file sets both to 1000, and its comment is worth repeating: both must be set for it to do anything. Setting one alone does nothing at all.

They decide who owns the stack files Dockge writes. Get them wrong and the symptom is undramatic — you SSH in later, try to edit a compose file by hand, and cannot, because it belongs to someone else. id -u and id -g give you the right numbers for your own user.

Adopting stacks you already have

Dockge reads a directory. There is no import step, and no separate database holding the real state, so a compose file you drop into the stacks directory is simply a stack it can see.

That property is the reason I find it easy to recommend trying. The compose files are the state. Nothing else is. If you decide against it in a month, you stop the container and your stacks are exactly where you left them, in plain files, unchanged. Tools that own their state are a commitment; this one is a visit.

What I have not tested

I have not run the agent/multi-host setup, so I cannot tell you how it behaves when a remote host goes away mid-deploy, which is the case I would want to know about before depending on it.

I have not measured its resource use, and I would rather say that than quote a figure I did not take.

I have also not run it against a stack large enough to make the UI struggle, so I do not know where that boundary sits.

What getting the volume wrong costs

Not much, if you catch it on day one. You notice the stacks are not where you expected, you fix the bind, you move on.

The expensive version is catching it in month four, after you have pointed a backup job at /opt/stacks on the host and it has been faithfully archiving an empty directory the whole time. The compose files were always at /docker. Nothing errored, because nothing was wrong from any single component’s point of view.

Check the two paths match. Before anything else.