<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Systemd on Neil Hanlon</title><link>https://thepotato.tech/tags/systemd/</link><description>Recent content in Systemd on Neil Hanlon</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Wed, 30 Sep 2026 12:56:00 -0400</lastBuildDate><atom:link href="https://thepotato.tech/tags/systemd/index.xml" rel="self" type="application/rss+xml"/><item><title>I Made swamp Deploy swamp</title><link>https://thepotato.tech/posts/swamp-as-a-service/</link><pubDate>Wed, 30 Sep 2026 12:56:00 -0400</pubDate><guid>https://thepotato.tech/posts/swamp-as-a-service/</guid><description>&lt;p>I run swamp for a &lt;em>lot&lt;/em> of things at this point, so when it came time to stand up the swamp control plane itself, a long-running service on a box in my basement, there was really only one acceptable answer: deploy swamp using swamp.&lt;/p>
&lt;p>The one rule I set going in was to only use swamp, for everything. No Ansible, and no shell script that makes perfect sense today and becomes archaeological evidence six months from now. Every change to the host, identity, certificate, and systemd unit had to go through a swamp model and leave behind a versioned run I could interrogate later. Partly that was dogfooding, but mostly it was consistency: if my whole argument for swamp is that modeling a system forces you to understand it, then exempting swamp itself seemed rude.&lt;/p></description></item></channel></rss>