GitOps for Self-Hosted Podman Containers with GitHub, Renovate and Komodo

After the past weeks of vulnerability disclosures, I decided it was time to take updates more seriously for the containers in my home lab. My setup is pretty basic - I run a CentOS Stream machine that stays online to host infra services such as dns, monitoring, media hosting for my photos and movies libraries, some websites and other utilities. All these run as podman containers.

Until recently, I used shell scripts to create the containers and systemd units to manage their lifecycle. That worked well when there were only a few of them but as the number of containers grows, it becomes harder to keep track of the image versions in use and to update them consistently.

I wanted to try for a while Nick Cunningham’s guide to automating container updates with Gitea, Renovate and Komodo but for this time I adjusted the approach and used GitHub and GitHub Actions with the cloud Renovate. I will explore self-hosted Renovate and Forgejo at a later time.

The workflow

I moved the container definitions into Compose files and put them in a GitHub repository. Komodo manages the stacks from that repository.

The update path is:

1. Renovate checks the image references and opens a pull request when it finds a newer version.
2. I review the update and merge the pull request.
3. A push to main that changes files under compose/ starts the GitHub Actions workflow.
4. The workflow sends a POST request to the Komodo webhook using a signature.
5. Komodo validates the signature and runs the configured stack procedure to refresh and deploy the Compose stacks.

This makes Git the source of truth of the versions I want to run. Renovate proposes changes, but the containers do not update just because a new image appears in a registry; deployment follows a reviewed change in the repository.

One example is Renovate’s pull request updating Immich, which changed the server image from v3.3.3 to v3.3.5.

Keeping Komodo’s web interface private

The GitHub Actions runner needs to reach Komodo, but I did not want to expose the Komodo interface to the public Internet. Requests to my public address already pass through an Nginx reverse proxy, so I configured it to allow the Komodo webhook endpoint and deny other Komodo routes. The web interface remains available only from my internal network or VPN.

What this gives me

The result is a small GitOps workflow for the services on my home lab host. Compose files are versioned in Git, Renovate finds image updates, pull requests give me a place to review them, and Komodo applies the changes. I can see what changed and when and I can use Git history to identify or revert a bad version update.

This is not a substitute for backups or for checking release notes, especially when updates includes database migrations or breaking config changes. But it does make routine image updates easier to notice and manage than remembering to inspect every container by hand.

References

• Infrastructure repository
• GitHub Actions workflow that calls Komodo
• Example Renovate image update pull request
• Nick Cunningham’s original guide
• Komodo documentation