The state of my house is a reflection of the state of my mind.
The opposite is also true: If I clean, I instantly feel better. Digital housekeeping is no exception.
Containers running slow, services scattered across different ports and addresses, and I have to remember what is going on where. It works, but it isn’t right. It’s mental load.
Anyways. I finally sat down to clean up. Got nothing better to do. How long can it take? A day? Two? Just put in a little work now, so I don’t have to do a lot of work later, right? While I’m on it, I might as well upgrade my system…
If you’ve been following along, you know this blog runs on a TrueNAS Electric Eel system. It’s a great piece of kit, but self-hosting … well. You’re never really „done“ working on it.
This digital housekeeping was about a little bit of fresh air and a lot of maintenance: A new mainboard. Files from SSD to NVME. All the problems that came with the hardlinks in compose.yamls. Caddy, automation, port fowarding, network routing, certificate obtaining, head-against-wall banging. You know the drill.
From J5005 to N100
I finally swapped the old J5005 for an N100 to actually run my stuff properly. The N100 is great, but of course, it only has one RAM slot. I had to wait for a 16GB stick from eBay (thanks AI for the nice RAM prices, buying my stuff used now) and until then, I was stuck with 8GB. I’m absolutely sure this won’t be a problem in the meantime.
I actually enjoy the hardware side of this. Rewiring everything in a Node 305 is tight, but cable management is weirdly relaxing. The real headache started when I tried to boot up. Running 20+ containers (including resource hogs like Immich and Nextcloud) on 8GB is a death sentence. Especially when you’re moving massive datasets from an SSD to a new NVME. Everything crashed. Of course, it took me a while to figure out why.
The data migration was a mixed bag. Changing all those hardlinks in the compose files while trying to keep FoundryVTT assets on the SSD and the OS on the NVME was tedious. Sometimes it do be like that.
At least it is clean now. And got to write a bit of compose.yaml and refresh my memory. It’s scary how much I forget. It’s my code, after all, but it didn’t feel like it.
Put the DNS in the Black Hole or something
I also moved my Pi-hole. It’s no longer on the TrueNAS, now it lives on a dedicated Raspberry Pi 3B+ with the TrueNAS just acting as a backup. Why? Please don’t ask. No good reason. I just thought that was neat, and it doesn’t throw load errors anymore.
Then I tried setting up „Split Horizon“ DNS. Basically, I wanted the same URL to point to a local IP when I’m at home (for speed) and a public IP when I’m out, without any changes on my end. I scrapped it. Couldn’t get it to work. Abandon ship, maybe later.
Cloudflare WTF of the day
Then there was Caddy. Specifically, the Cloudflare DDNS plugin.
Cloudflare started pushing these new cfut_ tokens. They’re great, except the old tokens were all 40 characters long. The new ones are cfut_ + 40 characters.
And Caddy don’t like this. Oh no, good sir. The Caddy plugin (cloudflare-ddns) had a fixed 40-character limit hardcoded into it. The new tokens are longer. It broke everything. I could not add a new API token into Caddy, it will not work. Caddy does not accept it. Fix is out as we speak, but of course not implemented into the precompiled images yet. So I compiled my own. Sure. Why not. Can’t wait to use serfriz image again. These maintainers are basically gods to me.
Who is to blame? I blame Cloudflare for their shit error messages and for forcing new tokens down everyone’s throat to „fix“ their own bad legacy documentation. But Caddy isn’t innocent either for having such a rigid limit.

Classic. https://xkcd.com/2347/
Work is never done because someone somewhere changes a character limit.
Somewhere along the Watchtower
I installed Watchtower to update my images. I cannot wait until this breaks stuff, too. In my infinite wisdom I excluded things like FoundryVTT from the automatic updates. I would never make the mistake and update Foundry directly after a big patch and break everything and spend a week to fix it and grow a little bit balder over all the frustration. Oh no, not me.
I have no friends, so a bot writes me
I coded a small script that lets me know when services go down. That’s it. I also get overly excited that someone writes me when I get a notification, only to get disappointed that something crashed and burned.
It wasn’t even that much work. And AI really helps out with easy projects, though I fear I wont learn that much if I rely on it too much. Or my own voice and expression gets lost in the process. If anyone real reads this, I bet you thought this was written by an AI in parts, right? That’s what I mean.
Lessons Learned
I am not big on learning from my own mistakes. I’m lazy and I really like learning from the mistakes of others. Also I might have infinite wisdom, but I do not have infinite hair to spare. But sometimes you gotta do what you gotta do.
So. What did I learn…
- Automation is a double-edged sword. You spend a lot of time now to safe a lot more time later. Until it „helps“ you into a disaster. My new Watchtower is set to Opt-In only.
- Monitoring is peace of mind. My pinger bot now yells at me on Telegram the second a service croaks.
- I actually don’t do complicated stuff. I’m basically script kiddy level, and I can still make mistakes. Big, big thanks to all the maintainers and open source coder gods out there. Thanks to you, I can enjoy my silly little projects.
As a kid, when I was five or so, I had a cassette (shut up, I’m not that old). I don’t remember much from it, only that it was a poem or song about someone working on a computer all night to get something to work.
It ended something like this:
Die Augen brennen müde,
doch er hat es geschafft.1
I think it influenced me more than I knew.
- The eye are burning, tired, but he did it. ↩︎

Schreibe einen Kommentar