<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Selfhost on M1CH's Log</title><link>https://blog.m1ch.eu/tags/selfhost/</link><description>Recent content in Selfhost on M1CH's Log</description><generator>Hugo</generator><language>en-us</language><copyright>Michael Klamminger</copyright><lastBuildDate>Mon, 19 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.m1ch.eu/tags/selfhost/index.xml" rel="self" type="application/rss+xml"/><item><title>Coordinated Reboots for bootc Hosts</title><link>https://blog.m1ch.eu/posts/20261019-bootc-fleetlock-reboots/</link><pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate><guid>https://blog.m1ch.eu/posts/20261019-bootc-fleetlock-reboots/</guid><description>&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; &amp;ndash; 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.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;In &lt;a href="https://blog.m1ch.eu/posts/20251122-bootc-tweeks/"&gt;how I tweak my base image&lt;/a&gt; I
described how I replaced &lt;code&gt;bootc-fetch-apply-updates.timer&lt;/code&gt; with my own
&lt;code&gt;bootc-fetch.timer&lt;/code&gt;: every hour &lt;code&gt;bootc update&lt;/code&gt; pulls the newest image and
stages it, but doesn&amp;rsquo;t reboot. I ended that post with &amp;ldquo;the actual reboot is a
separate step I control manually or via another timer&amp;rdquo;. This post is about
that missing step.&lt;/p&gt;</description></item><item><title>No Assignment, No Code: Planning with a Coding Agent in OpenProject</title><link>https://blog.m1ch.eu/posts/20261007-openproject-coding-agent/</link><pubDate>Wed, 07 Oct 2026 00:00:00 +0000</pubDate><guid>https://blog.m1ch.eu/posts/20261007-openproject-coding-agent/</guid><description>&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; &amp;ndash; I plan my side project with a coding agent in OpenProject
instead of a chat window. I write user stories (&lt;em&gt;what&lt;/em&gt; and &lt;em&gt;why&lt;/em&gt;); the agent,
working as its own least-privilege user, turns them into features and tasks
with specs (&lt;em&gt;how&lt;/em&gt;) 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.&lt;/p&gt;</description></item><item><title>AI Agents in My Hosting Workflow</title><link>https://blog.m1ch.eu/posts/20260928-ai-agents-in-my-hosting-workflow/</link><pubDate>Mon, 28 Sep 2026 00:00:00 +0000</pubDate><guid>https://blog.m1ch.eu/posts/20260928-ai-agents-in-my-hosting-workflow/</guid><description>&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Over the last months two coding agents moved into that loop:
&lt;a href="https://opencode.ai"&gt;opencode&lt;/a&gt; and
&lt;a href="https://claude.com/claude-code"&gt;Claude Code&lt;/a&gt;. This post covers how I set them
up, what they do for me, and where I still keep my hands on the wheel.&lt;/p&gt;</description></item><item><title>Why I Run My Models Locally</title><link>https://blog.m1ch.eu/posts/20260924-why-local-models/</link><pubDate>Thu, 24 Sep 2026 00:00:00 +0000</pubDate><guid>https://blog.m1ch.eu/posts/20260924-why-local-models/</guid><description>&lt;p&gt;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&amp;rsquo;t matter. For
your mailbox, your customers&amp;rsquo; tickets or your company wiki, it matters a lot.&lt;/p&gt;
&lt;p&gt;That is the main reason I run most of my models on my own hardware with
&lt;a href="https://ollama.com"&gt;Ollama&lt;/a&gt;. This post covers why, and where these models
are useful in a self-hosted setup.&lt;/p&gt;</description></item><item><title>Conditional bootc build</title><link>https://blog.m1ch.eu/posts/20260507-forgejo-runneres-advanced/</link><pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate><guid>https://blog.m1ch.eu/posts/20260507-forgejo-runneres-advanced/</guid><description>&lt;p&gt;Running image builds on a schedule makes sense for security &amp;ndash; 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.&lt;/p&gt;
&lt;p&gt;This post covers how I added upstream change detection to my Forgejo CI pipelines
for &lt;a href="https://codeberg.org/m1ch/gorgeOS"&gt;gorgeOS&lt;/a&gt;, so that scheduled builds are truly
no-ops when the upstream image hasn&amp;rsquo;t moved.&lt;/p&gt;</description></item><item><title>Bootc Matrix Build</title><link>https://blog.m1ch.eu/posts/20260505-bootc-matrix-build/</link><pubDate>Tue, 05 May 2026 00:00:00 +0000</pubDate><guid>https://blog.m1ch.eu/posts/20260505-bootc-matrix-build/</guid><description>&lt;p&gt;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.&lt;/p&gt;
&lt;h2 id="the-problem-with-hardcoded-versions"&gt;The Problem With Hardcoded Versions&lt;/h2&gt;
&lt;p&gt;Before, every Containerfile had a hardcoded base image:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"&gt;&lt;code class="language-dockerfile" data-lang="dockerfile"&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;&lt;span style="color:#66d9ef"&gt;FROM&lt;/span&gt; &lt;span style="color:#e6db74"&gt;git.m1ch.eu/oci/c-os:base-43&lt;/span&gt;&lt;span style="color:#960050;background-color:#1e0010"&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Supporting F44 would have meant either duplicating the whole workflow or a manual
find-and-replace for every release. Neither scales.&lt;/p&gt;</description></item></channel></rss>