Komodo is a self-hosted build and deployment tool: a central Core with a web UI and API, plus a lightweight Periphery agent on every machine you want it to control. It manages Compose stacks, builds images from git repos, and keeps configuration in a database you can sync back to git.
Our verdict on Komodo#
Komodo is the pick if you have more than one machine and you think in Compose files rather than in Kubernetes manifests. Core is a Rust binary that stores everything in MongoDB and talks to a Periphery agent on each host, so adding a second or third box is a one-line install rather than a cluster join. Version 2.0 was a genuine break: the :latest tag is deprecated and you must move to the :2 tag, and there is a v1 to v2 database schema migration with a documented revert path. Current release is 2.3.3 (September 2026). Being honest about maturity: the project dates to 2023 under the name Monitor, was renamed Komodo in 2024, and shipped a breaking major within the last twelve months. Assume another one is possible. The MongoDB dependency is the other cost; FerretDB is supported but it is one more moving part on a home server.
Who Komodo is for#
Choose it if
- Someone running three or more Docker hosts who is tired of SSHing into each one to pull and restart
- A person who keeps compose files in git and wants webhook-triggered redeploys without standing up a CI system
- A homelabber who wants build servers and deploy targets separated, so image builds do not hammer the machine serving media
Look elsewhere if
- You have exactly one Docker host, where Komodo's Core plus Mongo plus agent is more infrastructure than the thing it manages
- You will not run MongoDB or FerretDB, which is a fair position on a low-RAM box
- You need a stable API for automation right now, given a major version landed within the last year
What running it actually looks like#
Take the project's mongo.compose.yaml and compose.env, set the database credentials and COMPOSE_KOMODO_IMAGE_TAG=2, then bring up three services: mongo, core publishing 9120, and a local periphery agent. Periphery mounts /var/run/docker.sock and /proc, and keeps its state under /etc/komodo. That gives you Core managing the machine it runs on. For every additional server you install Periphery there, either as a container or via the install script, and register it in the UI with its address and passkey. Agent and Core versions want to move together, so upgrade Core and every Periphery in the same window. Backups are written to the path in COMPOSE_KOMODO_BACKUPS_PATH, defaulting to /etc/komodo/backups, which is on the host and not in a volume.
Resource profile#
- Memory
- 250 MB idle, around 700 MB in ordinary use. The Rust Core is small; MongoDB is what actually eats the memory and will take whatever the host offers for its WiredTiger cache.
- CPU and acceleration
- Core is idle between actions; the spikes are image builds, which happen on whichever Periphery host you assign as the builder, not necessarily on Core.
- Storage growth
- Mongo grows with update and log history rather than with stack count; the dated database backups Komodo writes to `/etc/komodo/backups` are the part that will surprise you.
- Operational load
- 3 of 5, Moderate. A real database service, an agent on every managed host that must stay version-aligned with Core, and a major version in the last year that changed image tags and the database schema. That is rubric level 3.
Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.
Data and backup surface#
Three things. The Mongo volumes (mongo-data, mongo-config) hold all configuration, stack definitions, users and update history; back these up with a mongodump or by using Komodo's own scheduled dumps rather than copying the files live. The keys volume holds the Core key material and is required to talk to existing Periphery agents; lose it and every agent must be re-registered. Third, /etc/komodo on each Periphery host holds agent config and the stack working directories. Container images and cloned repos are regenerable. Also export your resource definitions to git via the sync feature, which turns a restore into re-applying TOML.
Derived backup shape
Mongo dump. mongodump into a file, then snapshot that file plus the app's data volume.
Traps and surprises#
The latest tag is deprecated as of v2
Komodo v2 images are published only under the :2 tag and the :latest tag is deprecated. If your compose file still says moghtech/komodo-core:latest, you are either pinned to a stale v1 image or you will get an unexpected jump. Set COMPOSE_KOMODO_IMAGE_TAG=2 in compose.env and pin the same tag for Periphery so agent and Core stay compatible.
The v1 to v2 upgrade migrates the database schema
Moving from Komodo v1 to v2 rewrites documents in Mongo, and the release notes include a revert procedure back to v1.19.5 precisely because the migration is not a no-op. Take a Mongo dump before the first v2 start, not after. Later 2.3.x patch releases were still fixing edge cases in the v2 update path where legacy environment variables remained set.
Core and Periphery versions must match
Periphery is not a stable protocol boundary you can leave on an old version. Upgrading Core without upgrading agents produces confusing partial failures where a host shows as connected but actions fail. Plan the upgrade as a batch: pull Core, then pull or reinstall Periphery on every managed machine, then verify each server goes green in the UI before deploying anything.
MongoDB is a real dependency you now operate
Komodo needs MongoDB, and on hosts that cannot run current MongoDB builds (older CPUs without AVX, for example) the documented alternative is FerretDB. Either way you have added a stateful database service to a home server, with its own memory appetite and its own backup story, in order to manage compose files. Size the box accordingly rather than putting it on a 2 GB VM.
Specifications#
- Category
- Platforms and container management
- Licence
- GPL-3.0 (Copyleft)
- Written in
- Rust / TypeScript
- First release
- 2023
- Maturity
- Stable
- Datastore
- MongoDB (FerretDB supported as a drop-in for hosts that cannot run current MongoDB)
- Default ports
9120,8120- Ships as
- docker compose (core + mongo), periphery agent as container or systemd binary
- arm64 builds
- Yes
- Identity
- Native OIDC. Built-in OIDC plus GitHub and Google OAuth, configured through `KOMODO_OIDC_*` environment variables with PKCE support.
- Replaces
- Portainer Business, Dokku, Heroku
- Project site
- komo.do
- Source
- github.com/moghtech/komodo
- Documentation
- komo.do/docs/intro
Alternatives to Komodo#
Everything else in platforms and container management, closest in operational weight first.
| Tool | Ops load | Idle RAM | Licence |
|---|---|---|---|
| Coolify | 3, Moderate | 1200 MB | Apache-2.0 |
| Dokploy | 3, Moderate | 900 MB | Apache-2.0, with DSAL 1.0 reserved for a /proprietary path |
| TrueNAS Community Edition | 3, Moderate | 8192 MB | LGPL-3.0 (middleware) |
| CasaOS | 2, Light | 300 MB | Apache-2.0 |
| Docker Engine | 2, Light | 120 MB | Apache-2.0 (Engine and Compose); Docker Desktop is proprietary |
| Podman | 2, Light | 40 MB | Apache-2.0 |
Where Komodo comes up elsewhere#
Sources#
Facts on this page were checked against the project's own material. Where a number is our own estimate rather than a published figure, the text says so.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.