TL;DR – My bootc hosts stage new images every hour, but nothing rebooted them into those images. Now a small timer on each host checks a time window, its own health and its neighbours, takes a lock from a ~200-line Python FleetLock server, and only then reboots. No Kubernetes, no etcd, and protocol-compatible with the Fedora CoreOS tooling in case I outgrow it.

In how I tweak my base image I described how I replaced bootc-fetch-apply-updates.timer with my own bootc-fetch.timer: every hour bootc update pulls the newest image and stages it, but doesn’t reboot. I ended that post with “the actual reboot is a separate step I control manually or via another timer”. This post is about that missing step.

TL;DR – I plan my side project with a coding agent in OpenProject instead of a chat window. I write user stories (what and why); the agent, working as its own least-privilege user, turns them into features and tasks with specs (how) and hands them back for review. It only writes code for items assigned to it, and only when I ask. It works, it costs some ceremony, and the MCP tooling still has rough edges.

My homelab is mostly text: Docker Swarm compose files, bootc Containerfiles, Forgejo workflows, a few Ansible playbooks and this Hugo blog. All of it lives in git, and for years the workflow has been the same: edit in an editor, render, deploy, check the logs, repeat.

Over the last months two coding agents moved into that loop: opencode and Claude Code. This post covers how I set them up, what they do for me, and where I still keep my hands on the wheel.

Every prompt you send to a hosted LLM leaves your network. That includes the text you type, the files you attach, and whatever context your tools decide to pack around it. For a quick question about a regex that doesn’t matter. For your mailbox, your customers’ tickets or your company wiki, it matters a lot.

That is the main reason I run most of my models on my own hardware with Ollama. This post covers why, and where these models are useful in a self-hosted setup.

Running image builds on a schedule makes sense for security – you want your bootc images to pick up the latest Fedora updates automatically. But scheduling a daily build that rebuilds every image every day, even when nothing upstream changed, wastes runner time and fills the registry with identical layers.

This post covers how I added upstream change detection to my Forgejo CI pipelines for gorgeOS, so that scheduled builds are truly no-ops when the upstream image hasn’t moved.

Running a Fedora-based bootc image stack means tracking multiple Fedora releases in parallel. Instead of duplicating every job in the workflow, I wired up the matrix strategy in Forgejo Actions to build F43 and F44 from a single job definition.

The Problem With Hardcoded Versions

Before, every Containerfile had a hardcoded base image:

FROM git.m1ch.eu/oci/c-os:base-43

Supporting F44 would have meant either duplicating the whole workflow or a manual find-and-replace for every release. Neither scales.