.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Updated and tested 31 October 2026
Portainer and Dockge both run as a container, both mount /var/run/docker.sock and both give you a browser tab where you start, stop and inspect what Docker is running. Past that point they have very little in common. Dockge is a compose file editor with a start button attached. Portainer is a management layer over the entire Docker API, plus Swarm, Kubernetes and Podman. This comparison is about which of the two belongs on a single machine, a homelab box or one VPS, because that's where the "dockge vs portainer" question comes from. Fleet management is a different conversation and Komodo enters it, which is covered separately in Komodo vs Portainer for a fleet.
What Dockge manages and what it ignores
Dockge describes itself in its README as "A fancy, easy-to-use and reactive self-hosted docker compose.yaml stack-oriented manager", and the word doing the work in that sentence is stack-oriented. Each stack is a directory under /opt/stacks holding a compose.yaml, and Dockge reads, edits and runs those files. The interface is split down the middle: a YAML editor on one side, a form view of the same services on the other, and typing in either updates the other. Under that sits a live terminal streaming the output of docker compose pull and docker compose up as it happens, which is the feature people remember after they've used it once.
Containers you started with docker run don't appear in Dockge at all. Neither do images, volumes or networks as first-class objects. There's a converter that takes a docker run command and rewrites it as a compose service, and that's the intended path: everything becomes a stack or Dockge doesn't see it. Existing compose projects need to be moved into /opt/stacks/<stackName>/compose.yaml before Dockge picks them up, which the Dockge repository confirms in its README FAQ: stop the stack, move the file, then run Scan Stacks Folder from the menu at the top right. Anything running out of a home directory shows up greyed out in the stack list, and opening it gives "This stack is not managed by Dockge." until you move it.
A stack I started with plain docker compose in /opt/stacks shows up as a normal Dockge stack; ones elsewhere are greyed out.
The stacks directory is also the one thing that bites people on install. The path has to be identical on the host and inside the Dockge container, because Dockge hands those paths straight to the Docker daemon, which resolves them on the host. Change one side of the bind mount without the other and stacks get written somewhere you didn't intend. The official compose.yaml carries a warning comment about exactly this.
What Portainer adds on top of compose stacks
Portainer has stacks too, deployed from a pasted compose file, an uploaded one or a git repository. In CE 2.45.3 the git route starts from a saved Source and the form offers a "Create a Webhook" toggle when you create the stack, while the webhook on an existing stack carries a Business Feature label; I found no polling option on that form. The existing guide to deploying apps with Portainer stacks walks through that. Around the stacks sits everything else the Docker API exposes: a container list with exec and log views, images with a pull and build screen, volumes, networks, registries, events. Then the parts that have no equivalent in Dockge at all: Swarm services, Kubernetes namespaces and Helm, Podman environments, app templates, users and teams with per-environment access and the Edge Agent for machines behind NAT.
Default ports, for reference. Portainer serves HTTPS on 9443, keeps 9000 as the older plain HTTP port and opens 8000 for Edge Agent tunnels. The standard agent listens on 9001. Dockge listens on 5001 over plain HTTP.
Access control is the one line in Portainer CE that's thinner than people expect. CE has users, teams and environment-level access. Roles with fine-grained permissions (the RBAC feature) are Business Edition only, per the Portainer roles documentation. Dockge has a single admin login and no user model beyond that, so for a homelab with one operator neither product loses anything here.
Dockge asks for one admin account on first visit, and that is its whole user model.
Install Dockge and Portainer side by side
Dockge needs Docker 20 or newer, or Podman (with the podman-docker package on Debian), and its install is four commands from the README:
mkdir -p /opt/stacks /opt/dockge
cd /opt/dockge
curl https://raw.githubusercontent.com/louislam/dockge/master/compose.yaml --output compose.yaml
docker compose up -dPortainer CE is a volume and one docker run, using the lts tag that the official install command uses:
docker volume create portainer_data
docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always \
-v /var/run/docker.sock:/var/run/docker.sock \
-v portainer_data:/data portainer/portainer-ce:ltsThen open https://YOUR_SERVER_IP:9443, paste the setup token from docker logs portainer (the setup_token= line, required on new installs since 2.43) and create the admin account within five minutes, or the container locks the setup page and needs a restart. That timeout catches a lot of first installs and the fix is in how to install Portainer if you hit it.
| Dockge | Portainer CE | |
|---|---|---|
| Latest tagged release | 1.5.0, 30 March 2025 | 2.45.3 LTS, 21 October 2026 |
| Web port | 5001 (HTTP) | 9443 (HTTPS), 9000 (HTTP) |
| Manages | Compose stacks in /opt/stacks | Containers, images, volumes, networks, stacks, Swarm, Kubernetes, Podman |
| Multiple hosts | Dockge agents (since 1.4.0) | Portainer Agent on 9001, Edge Agent over 8000 |
| Users | Single admin | Users and teams; RBAC roles in Business Edition |
| Git deploys | No | Yes, from a repository Source |
| Architectures | amd64, arm64, armv7 | amd64, arm64 (check the Docker Hub tags for anything older) |
| Licence | MIT | zlib |
Release cadence and maintenance
This is the row in that table to read twice. Dockge's most recent tagged release is 1.5.0 from 30 March 2025, with no version cut in the nineteen months since. The project isn't dead: the author also maintains Uptime Kuma, and Docker Hub shows a nightly image that was rebuilt on 31 October 2026. But the latest, 1 and 1.5.0 tags all point at the same March 2025 build, so whatever Docker CLI and Compose binary that image bundles date from then, and those are the two things Dockge wraps.
After pulling the :1 tag on my test server, the Dockge container reports 1.5.0, the March 2025 release.
Portainer put out 2.45.0 as a new LTS line on 27 August 2026 and was at 2.45.3 by 21 October, with the previous 2.39 LTS supported until November 2026 according to the Portainer lifecycle page. Whatever you think of the product, it ships. One thing to know before you commit to it: Portainer has called 2.45 the last 2.x line and released 3.0.0 on 29 October 2026 as a Kubernetes-first short-term-support release for Business Edition only, with Community Edition staying on 2.x, which Portainer CE vs Portainer Business Edition goes through.
Small digression on that point, since it's relevant to the choice. Komodo now covers the compose-first, more-than-one-server case and Arcane the single-host case with a modern interface, and both release often (Komodo 2.3.4 on 22 October 2026, Arcane 2.17.1 on 25 October). That doesn't make Dockge worse at the thing it does, but it changes the answer to "what will this look like in two years".
Memory and CPU on a small box
Both are light. Dockge is a Node.js application, Portainer is a single Go binary, and on a 2 GB VPS with a dozen containers neither one is the process you'll notice in htop. There's no fair number here for Dockge during a full pull-and-up of a large stack, because the memory spike there belongs to docker compose itself, which Dockge shells out to, and the same spike shows up under Portainer when it does the equivalent.
