This is Part 2 of a 3-part series: “GitOps for Homeservers”
- Part 1: My Homeservers, Ansible, and the Pain Points
- Part 2: Searching for the Right Tool — Komodo, Dockhand, and Beyond (You are here)
- Part 3: ComposeFlux — A Lightweight GitOps Tool for Docker Compose
Also read: How I Manage My Homeservers with GitOps and Docker Compose on Medium.
Introduction
In Part 1, I covered my homeserver setup, the Ansible-based deployment workflow, and the problems that came with it — slow deployments, no selective deployment, manual triggers, and the fact that it was never true GitOps.
I made some time to look for alternatives that could replace the Ansible playbook 10-deploy-apps.yml. Below are the tools I evaluated and what I found.
Komodo
A solid, all-in-one tool to build and deploy containers across servers. Written in Rust, it has a nice UI and supports GitOps. When I deployed Komodo on one of my homeservers and started testing, I genuinely thought I’d found my replacement. It had more than everything I needed:
| My Requirement | Availability in Komodo |
|---|---|
| True GitOps | ✅ |
| UI | ✅ (Bonus) |
| Env vars management | ✅ |
| Agent to manage more servers | ✅ |
So, it was all good, right? But… there were some drawbacks that I discovered as I kept testing.
Backend Database
Komodo needs a database backend. I prefer not to deploy one — I want things simple and lightweight. But for the sake of testing, I went with MongoDB since Komodo supports MongoDB and FerretDB (in a recent version, they dropped SQLite support).
Since I wanted a lightweight setup, I looked for “tiny” MongoDB Docker containers. All I found were old images running older versions, while Komodo requires MongoDB 7 or 8. The official MongoDB image ships DB tools alongside the actual database binary, making it bigger than I’d like.
So I decided to build my own “tiny” MongoDB Docker image. In the end, I got it down to around 330MB. You can find the image on DockerHub: veerendra2/mongodb.
Secrets Management
I prefer to manage secrets in an external provider like Bitwarden or Infisical. Komodo doesn’t support external secrets providers. To be fair, this wasn’t a dealbreaker — Komodo has its own backend database and lets you store env vars as variables with secret flagging.
But I had recently learned Go at work and was looking for a side project to explore. So I decided to try integrating an external secrets provider with Komodo and created a tool called komodo-secrets-sync.
GitOps — The Dealbreaker
This is where things fell apart for me. To set up GitOps in Komodo, you need to configure Sync Resources. For Komodo to pick up docker compose apps from a Git repo, you have to create a TOML file defining each stack. For example, see the stack configuration docs.
If I want to deploy 10 apps on a server, I have to define 10 stacks in the TOML file. Even more annoying — if I want to deploy the same set of apps on multiple servers, I have to copy-paste the stack configs.
I searched online for a trick to automatically discover stacks in a folder recursively. There is an open GitHub issue that addresses this, and there’s a workaround tool that generates the TOML file automatically.
After some days, I lost interest in Komodo. The GitOps drawback was the main thing that set me off. In the end, I’d have to define each app twice — once in the docker-compose YAML file, and again in the TOML config for Komodo. I decided it wasn’t worth it for me. I realized Komodo’s use case and goals might be different, and it just wasn’t the right fit for what I needed.
Dockhand
A really good and lightweight tool with a UI to manage Docker containers. I only briefly tested it on my Mac.
Pros
| Requirement | Availability |
|---|---|
| GitOps | ✅ |
| UI | ✅ |
| Env vars management | ✅ |
| Agent to manage more servers | ✅ |
| Lightweight and no backend database | ✅ |
Cons
- At the time I was testing, there was no support for Docker Compose override files — it needed a full, resolved docker compose file
- NOTE: This support was added later in v1.0.16
- No support for external secrets management
In the end, I felt this tool was also “incomplete” for my specific needs.
What I Actually Wanted
After evaluating these tools, I had a clearer picture of what I was looking for:
- True GitOps — Push to Git, and the deployment happens automatically
- Lightweight — No heavy backend database
- Flexible configuration — Minimal config, no need to define apps in two places
- External secrets provider support — Bitwarden, Infisical, or similar
- Smart change detection — Don’t redeploy everything when only one stack changed
No existing tool checked all these boxes. And that’s what led me to build my own.
Next up: Part 3: ComposeFlux — A Lightweight GitOps Tool for Docker Compose, where I’ll walk through the tool I created to solve these problems.