Komodo is a big topic so I’ll leave this here: komo.do.

In a nutshell, though, all of Komodo is backed by a TOML-based config. You can get the config for your entire setup from a button on the dashboard. If have all of your compose files inline (using the editor in the UI) and you version control this file, you can basically spin up your entire environment from config (thus my Terraform/Cloudformation comparison). You can then either edit the file and commit, which will allow a “Resource Sync” to pick it up and make changes to the system or, you can enable “managed mode” and allow committing changes from the UI to the repo.

EDIT: I’m not really sure how necessary the inline compose is, that’s just how I do it. I would assume, if you keep the compose files in another repo, the Resource Sync wouldn’t be able to detect the changes in the repo and react ¯\_(ツ)_/¯

I guess I don’t get that granular. It will respect the current docker compose image path. So. if you have the latest tag, that’s what it will use. Komodo is a big topic: https://komo.do/

Not sure why Renovate is necessary when Komodo has built-in functionality to update Docker images/containers. I wish there was an option to check less often (like once a day), maximum time is hourly.

Also, if you’re using Komodo and have one big repo of compose files, consider just saving your entire config toml to a repo instead. You end up with something akin to Terraform or Cloudformation for your Docker hosts

My home network is called The IT Clowd with these devices:

• Moss - physical server
• Roy - physical server
• Jen - vm - main docker host
• Richmond - vm - *arr stack
• Denholm - vm - management, monitoring
• Douglas - vm - Home Assistant stack
• Basement - vm - development server