Docker Management Stack

Last reviewed Oct 11, 2026 · 664 words

The rule that keeps this stack sane is one owner per compose stack. Komodo deploys from git, Portainer is for looking and for quick fixes, and Homepage only reads. Let two of them edit the same stack and you will lose changes. The three together need about 896 MB of RAM by the directory's estimates: 512 MB for Komodo, 256 MB for Portainer CE and 128 MB for Homepage.

What talks to what

All three talk to the Docker engine, and none of them talk to each other.

Portainer CE connects to the Docker socket, or to a Portainer agent on remote hosts, and shows containers, images, volumes, networks and stacks with full control over each. Komodo has a central Core with a web UI and a lightweight Periphery agent on each server it manages; Core pulls your compose files from a git repository and tells Periphery to deploy them, and its webhooks can redeploy on push. Homepage is a YAML-configured dashboard that can auto-discover containers from Docker labels and show live widgets for the services behind them.

Three apps holding the keys to the host

Access to the Docker socket is root-equivalent access to the machine. Portainer and Komodo need it to do their jobs, so put both behind authentication, keep them off the public internet, and use strong passwords from the first login. Homepage only needs to read container state, so mount the socket read-only or, better, point it at a socket proxy that exposes only the read endpoints. If someone compromises your dashboard, they should get a dashboard and nothing else.

Deploy in this order

Portainer first: it is the quickest way to see what is already running and to clean up stray containers and volumes before you put anything under git. Then Komodo, starting by moving one existing compose stack into a repository and letting Komodo deploy it. Once that works, migrate the rest one at a time. Homepage last, because its value is in pointing at services that already exist.

Komodo Core needs its own database, so it brings an extra container of its own. Watchtower used to fill the automatic-update slot in this kind of setup, but it has been archived; Komodo's update monitoring now covers that, and showing you what changed before redeploying is safer than updating blind anyway. The container updates guide explains why.

Can Portainer and Komodo manage the same containers?

They can both see them, but only one should ever change them. A stack Komodo deployed from git will be overwritten by the git version on the next deploy, so an edit made in Portainer quietly disappears. A stack created in Portainer's editor lives inside Portainer's own data volume rather than in your repository, so Komodo knows nothing about its definition. This drift is the common mistake with the combination. Decide that git and Komodo own every long-lived stack, and use Portainer for inspection, logs, exec shells and emergency restarts only.

Backups

With Komodo in charge, your compose files are already in git, which is the most valuable backup in the stack. Back up Komodo's database for its deployment history and secrets, Portainer's data volume for its settings, and Homepage's /app/config folder, which is a handful of YAML files. None of this replaces backing up the application volumes themselves.

What I'd do

Run Portainer now for visibility, move your compose files into a git repository and let Komodo deploy them, and add Homepage last with a read-only socket. The Docker Compose homelab patterns post covers how to lay out that repository.