One side effect of giving agents access to my Hetzner VM has been drastically reducing the friction to testing out OSS, and ultimately replacing existing SaaS subscriptions with self-hosted options.
I can point an agent at a Github repo, and since it has access to CLI tools that can manage my DNS as well as SSH into my VM, usually 10 minutes later I have <new-service>.hutch.is. The only downside is any required ongoing maintenance, which is typically minimal, but does create a real security risk.
We're in the early days of an explosion in the cybersecurity arms race fueled by AI. And this isn't just impacting obscure software, it's hitting close to home. Several tools I use personally and professionally have been impacted this year.
Ghost, the blog platform this post is (self) hosted on was the subject of a viral security talk by Anthropic in March 2026.
Metabase, an open source BI tool I've been a long-time fan of, had a serious vulnerability reported in August 2026.
https://www.metabase.com/blog/security-update-6-aug-2026 https://www.metabase.com/blog/vulnerability-what-happened
So the same LLMs that are allowing me to lean into owning more of my personal productivity stack are making it more precarious to do so.
Responsible Self Hosting #
When these hacks are reported, your self hosted set up is a sitting duck and hackers are racing to extract as much value before the window of opportunity is closed. Closing that window as fast as possible reduces your exposure and typically means applying a patch.
Unfortunately, this is the kind of house keeping that has significantly less dopamine payoff compared to setting the tool up. It's 100% possible to just ask Codex/Claude <insert your agent of choice> to pull an update, but that felt silly. It was a lazy way to be lazy. I much prefer a lazy way to be smart.
N8N, one of the tools that kickstarted my self hosting obsession, has become my automation and workflow tool of choice, and seemingly every time I logged in it flashed an icon indicating a new version was available. After a dozen rounds of asking codex to update N8N, I figured I could save the tokens by creating an N8N workflow configured to pull the fresh Docker image and restart the service.
This worked beautifully, and along the way one of those updates included N8N's significantly improved MCP support. Once creating a workflow was as easy as talking to codex, the floodgates opened.
Bring Back the Dopamine #
Updating software isn't just about patches, every blue-moon there are valuable new features to take advantage of! Now, after adding a new service to my VM, I have a follow up conversation with my agent that typically looks like:
Let's create a new N8N workflow that checks for an updated version of <service>, applies the update if available, and creates a summary of the changes to be sent via Telegram.
My N8N account is full of workflows that look like this, and then those are bundled into one workflow that trigger all my updates in sequence.
This might be the bare-minimum, but it's a bar that's easier than ever to clear. You can likely point your agent at the above screenshot and have it recreate the flow for your own setup, I encourage it!