DEV Community: Wilhelm Murdoch

I Didn't Need a DAG. I Needed Cron.

Wilhelm Murdoch — Fri, 25 Sep 2026 00:00:00 +0000

Hey, nerds! Stop me if you've heard this one before.

Every homelab eventually hits the same wall. You have a pile of guests, a pile of small chores those guests need done on a schedule and absolutely no desire to SSH into each one by hand. Disk usage, uptime checks, arbitrary commands, pending updates, failed systemd units, the list goes on. This is all boring stuff that quietly rots away if nobody looks at it.

So I went shopping for an automation platform. I came back with nothing and then built one out of SSH, bash, cron and other bits and bobs already running in the homelab. It's called NetRunner, because I'm physically incapable of naming anything in this network without a cyberpunk reference.

Before we begin, I should take a moment to define what a DAG actually is. A Directed Acyclic Graph is a fancy name for a to-do list with dependencies. Each node in the graph is a task and each arrow says "this one waits for that one". Directed means the arrows only point one way. Acyclic means you can never follow them back to where you started, so you can't accidentally shoot yourself in the foot with a loop of tasks all waiting on each other forever.

The order comes from the arrows, not the order you wrote things down in. Say you take a backup, then verify it and copy it offsite, then clean up. Verify and copy both wait on the backup but not on each other, so they run side by side. The clean-up waits for both.

Let's go shopping!

I gave the usual suspects a fair go. Kestra, Windmill and Semaphore are all genuinely good software built by people who clearly know what they're doing. They're also built for teams. Teams that need a web UI, a worker model, RBAC and the plugin ecosystems. I'm just a weird little guy with a Proxmox cluster and a mild addiction to YAML.

Dagu came the closest. It's a single binary written in my favourite language, has jobs defined as YAML and no database to babysit. I liked it a lot and I really tried to force myself to use it. Then I sat down to write my first workflow and realised that not a single one of my jobs was actually a graph. They were all "run this thing on those boxes over yonder and read me the riot act if something failed".

Then, as I usually do in these moments, I took a step away from the desk and had a think. What is the bare minimum required to get this job done well?

The obvious answer was every piece of a central control node was already sitting in the network. Terraform already provisions the guests. Ansible already configures them. Forgejo already holds the code. Proxmox already knows every guest, its tags, its address AND comes packaged with an API. Apprise was also running in the homelab as a notification pipeline to a dedicated set of Slack channels. The only thing missing was a little bit of glue and a box to sit in the middle to press the button.

Boring almost always beats clever.

— Evergreen.

Big brain time!

NetRunner is one unprivileged LXC container with one core and a gig of memory. It has no web UI, no database and, with the exception of SSH, no open ports. It doesn't need Python or Ansible to run because the whole runtime is Bash, OpenSSH, curl, jq, flock and timeout. If you've administered a Linux box at any point in the last thirty years, you already know how every part of it works.

Here's an obligatory Mermaid chart with the basic workflow. We'll get to what nr is in a bit.

flowchart LR
  forge[Forgejo: jobs as code] --> ansible[Ansible playbook]
  ansible --> cron
  subgraph controller[NetRunner container]
    cron[cron] --> job[nr job run]
    job --> exec[nr exec]
  end
  pve[Proxmox API] --> exec
  exec -- "SSH, script on stdin" --> guests[LXC containers and VMs]
  job -- "on failure" --> slack[apprise to Slack]

The self-imposed design constraints were as follows:

A job is a script that runs on the controller and only on the controller.
The controller sends commands to the guests over SSH, collects their output and makes its decisions locally.
The guests run no scheduler, no agent and no daemon. They keep no copy of any job.

That last point matters because the homelab runs on an immutable infrastructure policy, so a guest should look the same after a job as it did before. NetRunner pipes each command or script into the guest on standard input and the guest runs it with bash -s. Nothing lands on the guest's disk, so nothing needs cleaning up afterwards.

Obviously, there could be exceptions to that rule, but if I aim to write something ephemeral to a guest's disk, it goes in /tmp. If I need to write something permanent, I codify it in Ansible or Terraform. It's more of a guideline than a hard rule.

One key to rule them all... with great care.

Each guest gets a dedicated netrunner user. The LXC containers get it from a Proxmox hookscript on every start, which Terraform manages with the proxmox provider. New VMs get it from cloud-init on first boot.

That user's authorized_keys holds exactly one line:

from="10.0.0.xx",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... netrunner

The key is an ED25519 pair that Terraform generates. The private half lives on the controller and nowhere else. The from= option is doing the real work here. Steal that private key, copy it to your laptop and try it from anywhere other than the controller's static address and every guest will politely tell you to get fucked. The key is only useful from one IP on the network.

I'm not going to pretend this is bulletproof, because it isn't. The netrunner user has passwordless sudo, since most of the chores I care about need root. That means the controller is effectively root on every guest. Own the container and you own the lab. It's the same trade every configuration management tool makes and I've made it with my eyes open.

The container is small, hardened, exposes nothing but SSH and has one job.

Finding the guests.

Hard-coding an inventory is how you end up running jobs against a guest you decommissioned weeks ago. So, to save me the trouble, every five minutes, nr refresh asks the Proxmox API for the running guests and caches the name, VM ID, node, type, tags and address of each one on disk.

The fun bit is that when you execute a job it never names a host. It selects guests with filters:

nr exec -t music -- uptime
nr exec -T lxc -P 8 -- 'apt list --upgradable 2>/dev/null | tail -n +2 | wc -l'
nr exec -a web -a dns -e THRESHOLD=70 -s filesystems.sh

Filter by Proxmox tag, by guest type or by a regex on the name. The tags come from Terraform. So when I tag a guest in its Terraform stack, I'm also quietly subscribing it to every job that selects that tag. A new guest needs zero changes on the controller. The hookscript or cloud-init gives it the account, the next refresh picks it up and it starts getting nagged on schedule like everybody else. This is the type of set-and-forget project I love to build.

The `nr` helper.

Everything on the controller goes through one command: nr. It's a bash CLI built with Bashly, which takes a YAML description of your commands, flags and help text and spits out a single, surprisingly well-designed bash script. If you've been reading this blog for a while ( you haven't ) you'd know that I've been using this utility for years.

Yes, there's YAML in the bash. There's always YAML. I've made my peace with it and so should you.

Command	What it does
`nr exec`	Runs a command or a script on every matching guest and collects the results.
`nr guests`	Lists the cached guests, with the same filters.
`nr tags`	Lists the Proxmox tags and the guests behind each one.
`nr ssh`	Opens a session to one guest by name.
`nr notify`	Sends a notification through apprise.
`nr job run`	Runs one job, exactly as cron would.
`nr refresh`	Rebuilds the guest cache and prunes old runs.

nr exec is the workhorse. It fans out to four guests at a time by default and writes <guest>.out, <guest>.err and <guest>.rc for each one, plus a summary.json that ties them together. A job script is then just ordinary bash and jq over a directory of files. No SDK, no bespoke expression language and definitely no plugin API I have to learn and quickly forget.

Secrets are covered as best I can for this kind of setup. nr exec --pass SECRET_SQUIRREL_TOKEN writes the variable into the stdin stream as an export line. This means a passed secret never shows up on a command line on the guest or its shell history.

It's also just a nice way to poke at the lab.

The scheduled jobs are the reason NetRunner exists, but the thing I didn't expect is how often I now reach for nr from a shell with no job in sight. The controller already knows every guest, so it's become the place I go when I have a question about the fleet and can't be bothered remembering an IP.

Some things I've typed within minutes of finally getting this running, more or less verbatim:

# Which guests are running and what are they tagged with?
nr tags

# Kernel versions across every LXC processing eight at a time.
nr exec -T lxc -P 8 -- uname -r

# Which VMs have a reboot pending?
nr exec -T qemu -- 'test -f /var/run/reboot-required && echo yes || echo no'

# Is docker happy on the media guests? Skip the music server.
nr exec -t media -x navidrome -- systemctl is-active docker

# Just get me a shell on that thing.
nr ssh koito

Obviously, I can easily eyeball a few of these from the Proxmox web UI, but we're not in a browser are we?

Every output line is prefixed with the guest name and each one is displayed as a single block, so a fleet-wide df -h is readable instead of a wall of text. At the end you get a list of anything that failed and the path to the results directory in case you want to go digging.

All results are stored locally on the controller as plain'ole files. This means composing stuff with the rest of the toolbox is fairly trivial. --json writes the summary.json to standard output and --quiet suppresses the guest output when you only care about the result:

# Name every VM guest where the command failed.
nr exec -j -T qemu -- hostname | jq -r '.[] | select(.rc != 0) | .name'

# Collect every os-release into a known directory, then read one.
nr exec -q -o /tmp/os -- 'cat /etc/os-release'
cat /tmp/os/koito.out

And because nr notify reads standard input, a one-off report is a pipe away:

nr exec -t music -- uptime | nr notify -T "Uptime of the music guests"

Here it is in the #netrunner channel moments later:

A preview of the resulting Slack notification.

Those ad-hoc runs land in /var/lib/netrunner/runs/adhoc/ and get pruned after a fortnight, same as everything else. This is also exactly how I test a new job before it gets a schedule. Run the commands by hand until they do the right thing, then move them into a script and add the YAML. There's no "run locally" mode to emulate because the shell is the local mode.

Jobs are code. Obviously.

Every job lives in the forge next to everything else. A job is two things: a script in jobs/bin/ and an entry in jobs/jobs.yaml.

- name: disk-usage
  description: Fail when a filesystem on a guest is at or above 85%.
  schedule: "0 * * * *"
  script: disk-usage
  timeout: 600
  exclude:
    - truenas

Info: You might notice I'm excluding TrueNAS here. It's not a standard guest, but a full-blown dedicated distribution that manages itself well enough. No need for my grubby scripts to taint all my legally-acquired ISOs.

The job script for something like "tell me which guests have failed systemd units" is about twenty lines:

#!/usr/bin/env bash
set -euo pipefail

results="${NR_RUN_DIR}/units"

# nr exec exits 1 when a guest fails. The script reads each result itself.
nr exec -q -P 8 -o "${results}" -- 'systemctl --failed --no-legend --plain | wc -l' || true

status=0
while IFS=$'\t' read -r name rc out; do
  if [ "${rc}" != "0" ]; then
    echo "UNREACHABLE ${name}"
    status=1
  elif [ "$(cat "${out}")" -gt 0 ]; then
    echo "FAILED UNITS ${name}: $(cat "${out}")"
    status=1
  fi
done < <(jq -r '.[] | [.name, (.rc // "skip" | tostring), .out] | @tsv' "${results}/summary.json")

exit "${status}"

Don't judge me, all Bash scripting looks ugly. Anyway, as is standard in Linux, you print whatever you want and exit non-zero when something's wrong. That's effectively the API in its entirety.

Ansible does the boring part.

I never touch the controller by hand. The playbook builds nr with Bashly, checks the result with bash -n before it swaps the old binary out and then reads jobs.yaml. It validates every job before it changes anything through an assertion and refuses to continue if any aspect of a job fails:

 ... more yaml up here ...
  tasks:
    - name: assert each job is valid
      ansible.builtin.assert:
        that:
          - item.name is defined and item.name is match('^[a-z0-9][a-z0-9-]*$')
          - item.schedule is defined and (item.schedule | split | length) == 5
          - item.script is defined
          - (netrunner_jobs_src ~ '/bin/' ~ item.script) is file
          - (item.env | default({}) | dict2items | map(attribute='key') | reject('match', '^[A-Za-z_][A-Za-z0-9_]*$') | list | length) == 0
          - item.notify | default('failure') in ['failure', 'always', 'never']
          - item.exclude | default([]) is sequence and item.exclude | default([]) is not string
          - (item.exclude | default([]) | reject('match', '^[A-Za-z0-9][A-Za-z0-9.-]*$') | list | length) == 0
        fail_msg: "Job {{ item.name | default('(no name)') }} in jobs/jobs.yaml is not valid. See the field list at the top of that file."
        quiet: true
      loop: "{{ jobs }}"
      loop_control:
        label: "{{ item.name | default('(no name)') }}"
  ... more yaml down here ...

You'll notice {{ jobs }} near the bottom. That's a variable defined by yet another YAML file containing a list of jobs formatted like the example at the start of prior section.

If the jobs pass, it writes two files on the controller. The first is jobs.json, with secrets resolved from my password manager at deploy time. The second is /etc/cron.d/netrunner, with one line per enabled job. Each line runs nr job run <name> as the netrunner user.

It's a stupid-simple template using that same {{ jobs }} variable passed through. This is what we use to create the resulting cron table:

SHELL=/bin/bash
PATH=/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# Keep the guest cache fresh for the helpers and the jobs.
*/5 * * * * {{ netrunner_user }} systemd-cat -t netrunner-refresh /usr/local/bin/nr refresh --quiet
{% for job in jobs if job.enabled | default(true) | bool %}

# {{ job.name }}: {{ job.description | default('no description') }}
{{ job.schedule }} {{ netrunner_user }} systemd-cat -t netrunner-{{ job.name }} /usr/local/bin/nr job run {{ job.name }}
{% endfor %}

So the entire workflow for a new automation is:

Write a script.
Add a few lines of YAML.
Push to the forge.
Run the playbook.

Want to pause a job? Set enabled: false and run the playbook. Want to drop a job? Delete it and run the playbook, which also removes the script from the container. If I want to see who fat-fingered the wrong thing, I have the git log to stare at. git blame tells me exactly who broke the thing aaaaand, oh wait, that's right, it was me.

Cron, but with a seatbelt.

Raw cron has two classic ways to ruin your weekend. Jobs pile up on top of each other when one runs long and jobs hang forever when a guest goes quiet. nr job run handles both with tools that ship with every Linux box on the planet.

flock makes sure a second run of a job won't start while the first one is still going. timeout kills a run once it goes over its budget, which defaults to an hour. Each run gets its own directory under /var/lib/netrunner/runs/ with its log, its exit code and the raw results from every guest. Output goes to the journal tagged netrunner-<name>, so reading a job's history is just journalctl:

journalctl -t netrunner-disk-usage --since today

Again, all tools that have existed forever, with the addition of things that already do real work in the homelab.

When a job fails, nr grabs the last forty lines of output and posts them to apprise, which drops them into a #netrunner Slack channel. That's the entirety of the alerting stack and it's currently more than adequate for my needs.

There actually are some ugly bits to this.

Here's what NetRunner doesn't do, in the interest of not pretending otherwise and I'm almost certain it's the part that most everyone reading this has been looking forward to:

There's no failover. A single LXC means a single controller. If it dies, the jobs stop and the guests carry on regardless. The container has no backup either, because it doesn't need one. The jobs live in the forge, the key lives in Terraform state and one terraform apply plus one playbook run rebuilds the whole thing. If it goes down for whatever reason, I have a reachability check from Uptime Kuma that'll alert me in Slack as well.
It doesn't verify host keys. Guests get recreated and DHCP addresses tend to wander, so strict host key checking would mostly produce noise. The cost is that a hostile box on the LAN that claims a guest's address could receive a job, secrets and all. It doesn't even need the key. The controller is the one doing the authenticating, not the guest. I accept that on my own network. I wouldn't anywhere else. I sure as shit wouldn't at work.
The cache can be five minutes stale. If an address moves between guests inside that window, a job can land on the wrong box. It's a small window and it's documented. I'd get an alert for this as well, so no biggie. Well, it could potentially be a very BIG biggie depending on what I'm running...
There's no UI. I consider this a feature, but I appreciate not everyone will.

None of these would survive a production review at work. That's fine. This isn't work, and every one of these trade-offs is written down in the homelab's wiki next to the reason I made it.

In closing ...

The platforms I looked at are not bad software. They solve problems that I simply don't have: many users, complex dependency graphs, audit requirements and a web UI for people who don't live in a terminal. I have a handful of guests and a list of chores.

NetRunner is some well structured bash, one SSH key, one cron file and a playbook. There's nothing to upgrade except bash and OpenSSH, and those were never going anywhere. Every part of it is something I already knew how to debug at two in the morning, which turns out to be the only feature that really matters.

I guess the whole point of this post is you don't always need to resort to using a super shiny off-the-shelf solution when you'll only use 5% of its functionality. Especially, when you already have everything you need, but the glue. The rule of YAGNI ( You Aren't Gonna Need It ) applies and prevails. At any rate, this was a fun weekend project!

The nr code is unique to my homelab and I don't plan on publishing it as it literally will not run anywhere else, but I'm flexible. If there's genuine interest, I'll post the source as well as the playbook so you can tinker with it youself.

Wake up, samurai. We have guests to patch.

The Safest Login Page is the One I Never Published

Wilhelm Murdoch — Fri, 11 Sep 2026 00:00:00 +0000

I finally got tired of not knowing whether anyone reads this thing, so I spent a Saturday afternoon standing up Umami in the homelab. The install was the easy part; the instructions are dead simple.

Then I got to the bit where you expose it to the internet. I went along with the advice everyone gives, stopped halfway and decided it wasn't good enough for me. So, I did what I normally do and stubbornly wandered off to my own path.

Quick bit of context for anyone who hasn't gone down this particular hole. Umami is a self-hosted analytics platform: a small Node app with a PostgreSQL database to maintain persistence sans the cookies and third parties slurping up all the data. It's as simple as dropping one script tag on your site. It posts a little blob of JSON on each page view and you get a dashboard. My install runs in an LXC on a member node of my homelab's Proxmox cluster.

I landed on it for the "normal" reasons. Cloudflare's Analytics are free but limited. They don't give me precisely what I'm looking for and they're a bit too slow for my liking. And, I'm not even going to give Google a single thought; they have enough of my data already.

Which leaves the question: how does a script tag on a public website safely and securely reach a container in my house without punching a hole in my router?

The answer everyone gives you.

The standard answer is a Cloudflare Tunnel. A small daemon, cloudflared, runs next to your service and dials out to Cloudflare. No dicking around with port forwarding, firewall rules or opening up your router to the world. Traffic arrives at Cloudflare, goes down the pipe your daemon already opened and lands on your service. It's genuinely lovely and it costs nothing. And since I already use Cloudflare to currently host my static websites and domains it was just the pragmatic option.

I think it's worth noting there is a real trade off here. A tunnel means Cloudflare terminates your TLS. Since they decrypt at the edge, they could inspect whatever they like and they re-encrypt on the way down the pipe. For page view pings carrying a URL and a screen size, I genuinely do not care. For anything with secrets in the payload I would care enormously and so should you.

Anyway, Umami has an admin interface. An admin interface typically has a login page. So, most guides you'll find after searching around will tell you to put something like Cloudflare Access in front of it. Access is an authentication layer at the edge. Basically, someone hits your hostname, Cloudflare intercepts, they sign in against an identity provider and only then does the request continue to your box.

I was about to wire it to my IDP when I actually stopped to read my own ingress config a bit more closely.

Tunnels match on path.

The important little detail I almost skimmed past was that a tunnel's ingress rules do not just match on hostname, but on path.

I had written this, which is what everyone starts with:

ingress = [
  {
    hostname = "analytics.nightcity.network"
    service  = "http://umami:3000"
  },
  {
    service = "http_status:404"
  },
]

You write a single hostname and everything on it goes straight to the app while anything else gets a 404. Ok.

But my analytics service only needs to expose two things to the public internet; the tracker script and the collect endpoint. Nobody on the internet needs to see /login or the dashboard, the settings, the user management or the API the dashboard talks to. So, why was I publishing everything and then buying into another service to place in front of it?

ingress = [
  {
    hostname = "analytics.nightcity.network"
    path     = "^/bundle\\.js$"
    service  = "http://nginx:80"
  },
  {
    hostname = "analytics.nightcity.network"
    path     = "^/api/v1/data$"
    service  = "http://nginx:80"
  },
  {
    service = "http_status:404"
  },
]

I only need precisely two paths out while everything else gets met with a lovely 404.

My admin interface still exists, of course ( I am not typing SQL to read my own page views ). It sits on my home network behind my own reverse proxy, reachable from the couch or over my established VPN.

Drawn out, the whole arrangement is two seperate paths that happen to share a name:

flowchart TD
    N["analytics.nightcity.network"]
    N -->|asked from the internet| CD[Cloudflare DNS]
    N -->|asked from my LAN| TD[Technitium]
    CD -->|104.21.x.x| E[Cloudflare edge]
    TD -->|10.0.0.200| P[My reverse proxy]
    E --> C[cloudflared]
    C -->|/bundle.js| X[nginx]
    C -->|/api/v1/data| X
    C -->|everything else| F[404]
    X --> U[Umami]
    P --> U

cloudflared decides what gets through and it's only aware of two paths. My side of the picture never touches Cloudflare, or the rest of the internet, at all. That shared fork at the top is possible with split horizon DNS and which route your request takes depends on how you get to that point. I'll explain a bit further down.

Why I think this is the better trade.

I want to be fair to Access here, because it's a great product and there are plenty of setups where it's the right call. If you genuinely need to reach an admin panel from anywhere on a machine you don't control, without a VPN, Access is exactly the kind of tool that'll get you there.

But if you don't need that, consider what you're actually buying in to.

With Access, /login is on the internet. It returns a challenge instead of a form, which is much better than nothing, but the attack surface is still there. There's an auth flow to configure, an IDP to keep working and an additional sign-in every time. Umami doesn't consume the Access token, so you authenticate to Cloudflare and then authenticate again to Umami. Nobody has time for that nonsense.

With path scoping, /login returns a 404. There is no flow to misconfigure because there is no flow. There is nothing to leave accidentally open when you change something else eighteen months from now.

Elimination is the ultimate form of hardening.

— Pretty much every cybersecurity professional.

The thing I keep coming back to: an attack surface you removed cannot be misconfigured later. A control you added can. This is all about shrinking the attack surface, which is an idea that's far older than me. We're not doing anything new here. But a standard installation path is built to get the typical user up and running quickly. However, quick doesn't necessarily mean appropriate for something like this.

Worth being precise about which of these is which, though. The 404 on /login is absence. There is nothing behind it to find no matter how hard you look. Umami does allow you to rename its default tracker paths as well, but that's plainly obscurity and it buys me nothing against anyone who actually takes the time to read my page source. Outside of that, renaming dodges a blocklist that matches on names and known patterns.

Does it work though?

The nice part about this setup is that you can test the public path without leaving the house. Using curl --resolve lets you skip your own DNS and dial the Cloudflare edge directly, while still sending the right hostname, so the request takes the same road a real visitor does.

curl -sI \
  --resolve analytics.nightcity.network:443:104.21.x.x \
  https://analytics.nightcity.network/login | head -1

Run that against a handful of paths and you get:

/                  404
/login             404
/bundle.js         200
/script.js         404
/api/v1/data       405
/api/send          404

That 405 is the collect endpoint telling me it only accepts POST, which is exactly what I want to see from a GET. It does admit the endpoint exists, where a 404 would not, but that one has to be findable anyway. Everything else gets a polite middle finger.

Meanwhile, from inside the house, the same hostname gives me the full dashboard. The same two path as before and the split falls out of the DNS I already run for network-wide adblock via a Technitium cluster.

Something worth pointing out.

I updated the ingress config, re-ran my checks and /script.js came back with a 200. Which was alarming, because I had just watched it 404.

It was cached. Umami serves its tracker with a 24-hour cache header. My earlier testing had pulled it through the edge and Cloudflare was dutifully serving me the copy it already had. Which, to be fair, is exactly what it should normally be doing. A request with a junk query string came back 404 immediately confirming the origin was doing its job.

Worth knowing if you ever unpublish something: the edge does not find out until its copy expires. Cache invalidation strikes again!

Hark! A plot twist!

Just after I shipped the script tag and confirmed real traffic was hitting Umami, Firefox showed me this:

Go home Firefox, you are drunk.

Sir, this is my own site from my machine on my home network. How dare you?

As I mentioned earlier, I run split horizon DNS. Inside my network, analytics.nightcity.network resolves to a private address on my LAN so I get the dashboard directly. Outside, where you better be reading from, the same name resolves to Cloudflare and goes down the tunnel. That's what makes the two-path thing work. I also mentioned this before in my previous article My Blog Now Ships From My Homelab! and it's one of my favourite aspects about my setup.

But when I load my public blog from my own house, the browser sees a page served from a public origin trying to load a subresource from 10.x.x.x. Browsers have started treating that as exactly the attack it usually is: a website on the internet quietly poking at your router, your printer or your NAS. Firefox calls it Local Network Access and blocks it by default. Chrome is heading the same way.

So the one place on earth where my analytics silently do not work is the chair I'm sitting in which is precisely how it should work. If it ever bothers me, the fix is to give the tracker its own hostname in a domain my internal resolver doesn't answer for, so it goes out to the edge from everywhere including my lounge room. I won't be doing that as I'm all too happy skipping my own page views.

The one thing path scoping does not fix.

Moving the admin interface off the internet does nothing for the collect endpoint. That endpoint has to accept anonymous POSTs from every visitor's browser, or it isn't an analytics endpoint. Umami rejects requests carrying a website ID it doesn't recognise, which stops idle nonsense, but my real website ID is sitting in the page source of every page on this site and Plant Smart. Literally anyone can read it.

So the only real control is applying some kind of rate limit. Cloudflare's free tier, which I'm currently on because I'm cheap and actually trying to reduce my subscription costs, permits one rule at a ten second window and it insists on counting per data centre rather than globally. It'll stop something stupid. But, it will not stop something determined.

Basically, path scoping shrinks the surface area enormously and then stops. What's left is the stuff that's supposed to be open. Though, the worst that can happen if the service gets hammered is fill my disk with garbage data points. Which would no-shit make me laugh.

... so, naturally I put Nginx in front of it.

I told myself this was about the rate limit which was a lie. It took a few hours for two better reasons to turn up.

The origin is blind.

A tunnel terminates the connection at the edge and opens a fresh one to your box, so every request arrives from the connector sitting next to your service. Umami sees 172.16.x.x, the Docker address of cloudflared, for the entire internet. That's also why the usual advice of "just put fail2ban on it" doesn't really apply. Fail2ban blocks source addresses with a firewall rule and no packet ever arrives from the address you'd want to block.

Cloudflare does pass the real client along in a CF-Connecting-IP header. Nginx can promote that header back into being the actual client address, which makes both the logging and the limiting mean something:

set_real_ip_from 172.16.0.0/12;
real_ip_header   CF-Connecting-IP;

limit_req_zone $binary_remote_addr zone=collect:10m rate=5r/s;

The set_real_ip_from range tells Nginx only the connector may assert that header. Nginx answers cloudflared and nothing else here and my internal route goes straight to Umami without passing through it. Meaning nothing on my LAN can forge a client address at me.

Umami logs nothing at all. Zilch.

Its own logs are four lines of startup and then a blank stare into the void. Which means that until I put a proxy in front of it, the only record of what hit my analytics endpoint was... my analytics.

Nginx gave me an access log within about ten seconds of starting and the very first thing it told me was that I had no idea what my traffic was.

In which I am humbled by a robot.

I had been suprised with my initial visitor numbers. Then I looked properly and roughly ~90% of it was a single machine in Singapore hammering one tiny post:

browser  os      device  screen      country  hits  sessions
chrome   Mac OS  laptop  1366x1366   SG       53    51

There are a few tells here. Not only is the screen size a perfect square, 50ish sessions with just as many hits from the same region with the same browser settings smells like a bot crawl. It was Kagi, near as I can tell, rendering the page to build a preview for Kagi Small Web. I have no real objection to that. It reaches my tracker at all because it runs the JavaScript, which an ordinary crawler never would. This is exactly the sort of thing that pollutes a dataset while you sit there feeling popular.

I don't care about the bots. The point is that I only found it because I'd added logging. I only added logging because I was chasing a rate limit I probably didn't need.

The small detail I liked most.

Nginx has a default location block and mine looks like this:

location / {
    return 444;
}

444 is an Nginx special. It doesn't return a status, but closes the connection quietly.

That rule is doing the same job as the catch-all 404 in my tunnel ingress. It holds exactly the same line only hop further in. Two independent things now have to be wrong at once before anything reaches my admin interface.

So, the tunnel is Cloudflare's. The edge rate limit is Cloudflare's. The Nginx config is a text file that's mine and it doesn't care in the slightest what is in front of it. Which matters, because I'm not 100% sold on keeping Cloudflare around longer-term.

None of the idea is Cloudflare-specific either. Any reverse proxy has a path-scoped location block and any tunnel worth the name matches on more than a hostname. Tailscale, Pangolin, NetBird or even vanilla WireGuard will get you there. I picked Tunnels as a convenient stop-gap until I move on to something a bit more "self-hosty". The vendor is incidental. Publish only what has to be public.

In closing ...

None of this is novel. Tunnels have matched on path since forever, it's in the docs and I'm certain plenty of people are already doing exactly this. I just hadn't thought about it properly, because the well-trodden advice is "put an auth layer in front of it" and this kind of consensus is usually good enough that you stop thinking.

But "protect the admin panel" and "publish the admin panel and then protect it" are not the same sentence and you should be aware of the difference.

If you're running anything through a tunnel right now, it's worth five minutes with your ingress config. Ask yourself which paths actually need to leave your network. For a lot of self-hosted things the honest answer is "fewer than all of them". The best answer is "none". And if you'd rather find out than wonder, that curl --resolve trick works against any hostname, including yours. Start with /login and see what comes back.

And if you're about to tell me the browser permission dialog is a bug, it isn't. It's three correct systems arguing and I've decided that's a feature.

Would you like to know more?

I kept the theory light in the post, because it kind of goes against the vibe of the site and my own casual style of writing. But the ideas underneath this are old and much better argued elsewhere, so here's where I'd start.

The Protection of Information in Computer Systems, Saltzer and Schroeder, 1975. The source of fail-safe defaults ( deny by default, allow by exception, which is exactly what that catch-all 404 rule is ) and economy of mechanism ( fewer moving parts means fewer parts to get wrong ). It's a fifty year old paper and it reads like one, but section I is short and it has aged as disgracefully as I have.
Attack Surface Analysis, OWASP. The plain-English version of the whole post, minus my nonsense. Useful if you want a structured way to ask "what am I actually exposing" about something larger than a script tag.
Tunnel configuration file, Cloudflare. The ingress rules reference. This is the page I had skimmed past twice before noticing that path was sitting right there next to hostname.
Local Network Access, WICG. The spec behind the permission dialog that made me raise an eyebrow. If you'd rather have prose than a spec, Chrome's New permission prompt for Local Network Access covers the same ground and explains why browsers decided this needed fixing.

If you only read one, make it Saltzer and Schroeder. Almost everything I thought I worked out on that Saturday turns out to be in there, but described better by people who got to it first and who are far smarter than me.

What Good is a Number You Can't Call?

Wilhelm Murdoch — Thu, 10 Sep 2026 00:00:00 +0000

This one's relatively short. I feel like I've been posting about Plant Smart a bit too much lately. But I've made a small change to how the site displays emergency information and it matters enough to warrant its own post. So, here we go.

Some background.

For three years every plant page on Plant Smart ended with the same two phone numbers and both of them were for the US. That never really sat right with me. I even flagged it as roadmap work when I rebuilt the site, then left it sitting there. The site's whole reason for existing is for the moment your cat eats something and you need an answer now. For most of the people who land there from a search engine, I was answering with a number they can't dial. So, I recently sat down to address that gap, assuming I'd spend a few minutes filling in a table of hotlines and be done with it.

Every single country had a speed bump.

Sweden's poison centre stopped answering questions about animals in July 2018 because the human call volume got too high.
The Dutch line only takes calls from vets, so if you're a pet owner in Rotterdam, the correct advice is "ring your vet and let them ring the line", which is not a phone number at all.
Belgium answers animal calls only during the day and says outright on its own site that it isn't funded for animal work.
The Australian helpline I'd have sworn was free actually starts at $75. This is a bit embarrassing because I live here and should know this.
The UK's fee changes depending on the time of day you call.
The ASPCA doesn't publish its consultation fee anywhere on its own page, so the figure everyone quotes online comes from third parties.

The list goes on.

I'd have got at least half of these wrong from memory, which is a genuinely unsettling thing to realise about emergency information.

Once again, I had to collate a bunch of disparate data and create a shape to support it before munging it all together. Every entry in the hotlines list now cites the operator's page it came from and the date I read it which is the same rule I put on the plant records in the last post. A Python script holds the whole list and nags me when an entry goes over a year old and it runs as part of the automated deployment. So, the build gives me a big'ole bonk on the nose whenever the list goes stale.

The boring technical stuff.

The engineering ended up being the easy half and mostly a matter of deciding what fails safely. Hugo writes every country into the HTML as a partial. A small script then lifts the relevant one out and folds the rest away. It guesses in order: a country you've pinned, then the location filter if it names exactly one country, then your browser locale.

It never asks permission for anything, because a permission prompt at 2am is the last thing you need while you're panicking about your pet. And, personally, I hate browser prompts asking for location tracking. Hard pass. If the script doesn't run, or if the service worker hands you a stale page, you get all countries instead of the wrong one.

Too many numbers costs you a few seconds. The wrong number costs you the call.

— It me.

There's also a new emergency page for the first five minutes before you get through: what to do, what not to do and what they'll ask you. The guidance follows the ASPCA and the Pet Poison Helpline which is also cited and linked. After all, the one thing I'm definitely not qualified to write is clinical advice.

Another free gift: the hotlines API.

There's really no obvious centralised place online that collates all this information into a single data set. I've at least done the work of bootstrapping the handful of most common countries that have helplines and the list will definitely grow over time. So, I've exposed a new "hotlines" API endpoint with its own documented shape.

{
    "countries": {
        // ... more countries ...
        "US": {
            "checked": "2026-09-10",
            "name": "United States",
            "services": [
                {
                    "audience": "owner",
                    "display": "(888) 426-4435",
                    "fee": "A consultation fee applies",
                    "hours": "24 hours, every day",
                    "org": "ASPCA Animal Poison Control Center",
                    "source": "https://www.aspca.org/pet-care/animal-poison-control",
                    "tel": "+18884264435"
                },
                {
                    "audience": "owner",
                    "display": "(855) 764-7661",
                    "fee": "$89 for each incident",
                    "hours": "24 hours, every day",
                    "org": "Pet Poison Helpline",
                    "source": "https://www.petpoisonhelpline.com/about/",
                    "tel": "+18557647661"
                }
            ]
        }
    },
    "notice": "Emergency telephone numbers for animal poisoning. Each country cites the operator page the entry came from and the date a person read it. Services close and numbers change, so check an entry before you rely on it. Coverage is not global. A country in this file with an empty services list has been checked and has no service an owner can call. A country that is absent has not been checked.",
    "updated": "2026-09-10"
}

I felt wrapping it in an envelope was the correct approach here. It leads with the notice and the date I last changed anything. A .countries object follows, keyed by ISO 3166-1 alpha-2 code. At the very least, it gives me room to change a country's metadata later without breaking the top-level shape.

The audience field on each service is what carries the Dutch problem into the data. It reads either owner or vet. A vet entry means the number exists but you can't ring it yourself, so the entry tells you to phone your vet and let them make the call.

Anyway, along with some stylistic changes and code cleanup, that's pretty much all there is to it for this update. I'll be giving Plant Smart a rest for a bit while all the changes settle in. This gives me some time to work on other fun things!

Enjoy, nerds!

Every Record Now Has a Source

Wilhelm Murdoch — Sat, 05 Sep 2026 00:00:00 +0000

As an experiment, last week I introduced r/InternetIsBeautiful to Plant Smart. To my surprise, it was overall very well received! Obviously, there were a few inevitable bad-faith comments from your standard-issue dickheads, but along with a lot of positive vibes I also got heaps of great suggestions and feature requests. So, this post covers not only a database scrub, but everything I've added as a result of the thread.

The database lost some weight.

Originally, the plant database held around 480 records. It now holds around 280, so roughly 200 records are gone. About 170 of them came from a single symptom list and all of them included "cardiac failure". That one symptom pushed every associated record to the top severity level. They read as "critical" because of the shared symptom list, not because of the plant itself. The list came from older sourced data that I never properly scrubbed and vetted, so I nixed those records entirely from the primary data set.

Sucks, but a smaller database you can trust beats a bigger one you cannot.

How I source vetted data.

At the moment, I check each record against the following authoritative data sources:

The ASPCA toxic plant list. It gives the clinical signs for dogs, cats and horses. This is the original reference that started the project way back in December of 2022.
The Guide to Poisonous Plants from the College of Veterinary Medicine and Biomedical Sciences at Colorado State University. It gives the clinical signs for each body system and it names the animals that the plant affects. It is stronger than the ASPCA list on horses and other farm animals.

Every one of the 280 or so records that remain traces back to at least one of these two references. This is a hard requirement. If a plant can't clear it, it doesn't get a record.

Both references are copyrighted material. I cite them and link to them directly without publishing any of their text. Each record holds my own symptom names only. If you're curious, the attributions page lists every licensed source used to build the site.

If you know of another authoritative data set that covers animals, the plants that are toxic to them and the associated symptoms, please let me know in the comments below or on the contribute page.

What I removed, specifically.

I removed the inaccurate records and enriched and corrected the rest. These changes break down into three groups.

The old data set covered seven animal types. The update reduces coverage to cats, dogs and horses. That doesn't mean I've given up on birds, fish, reptiles and small mammals. If I find good data for any of those groups, they go straight back in. Until then, they're parked.
I also changed the rule that sets the severity level of each record. The old rule just took the worst symptom on the record. Now there's an extra condition: a record with a single "critical" symptom and no "severe" symptoms gets marked "severe" instead. Nothing huge, but I felt it was worth mentioning.
A handful of records turned out to be duplicates, so I merged them.

Warning: A plant that is not in this database is a plant I cannot verify. If I can't verify it, it's not something I would personally call safe. Always consult your veterinarian when in doubt!

The plant index is now a "Field Guide".

Reddit user u/Abbot_of_Cucany mentioned that their bird guide indexes each species twice: the common name in plain type and the scientific name in italic type. I thought this was a great idea, so I built it. Of course, I got a little carried away, so the page now also holds a filter box. Type part of a name and the page shows every matching plant on record. A letter row sticks to the top of the screen while you scroll and it marks the letter you're currently reading through.

The field guide, filtered on "pea".

The front page got some filter updates!

Some people requested more filters, so I delivered. The additions cover severity, plant shape and the geographical regions where you might come across a plant in the wild. Those last two data points were already sourced, but not really in use. At least not in any obvious way. I also added a newer, tighter, photo-centric grid view for smaller screens. Personally, I think it looks good, but I'm not sure if I'm going to keep it. Let me know what you think!

The extra dropdowns squished everything together in the filter bar, so I had to rethink how to display them. I replaced all the individual dropdowns with a single multi-level filter menu. You can now click around and filter as you go. I also shrank the icons a bit to save more space, but they expand when you hover over them with a mouse or tap them on a small screen.

Also, worth noting: your filter selections stay in the browser between visits.

The data for the "Found in" filter comes from GBIF, the Global Biodiversity Information Facility. GBIF counts the wild sightings of each plant in each country. A country counts as a match when it holds one percent or more of the sightings for that plant. It's a totally arbitrary, non-scientific threshold that I imposed to keep the country list as tight as possible.

Safe plants get a facelift!

The safe plants list now holds over 30 common household plants. The new entries include the spider plant, the bamboo palm, sage and baby's breath, among others. A new entry joins this list only when the ASPCA marks the plant as non-toxic and only when the plant is absent from my own database. Each entry also carries a note that names the toxic plant people confuse it with. For instance, bamboo palm is safe while sago palm is deadly.

Based on a couple of user suggestions, each safe plant also includes a small gallery of three related photos sourced directly from the naturalist community at iNaturalist. Clicking a photo opens a lightbox with a zoomed-in view along with attribution and licensing information.

A few entries from the new safe plants list.

It now has a blog... sort of.

This part wasn't a suggestion. In addition to the updates page, I thought some kind of small blog would make sense. The articles I write about the site live here, where visitors to Plant Smart will most likely never read them. So, instead of building actual blogging functionality, I decided to syndicate the articles from here. I updated my Hugo templates to generate an RSS feed for each tag. Every article about Plant Smart carries the plantsm.art tag, so the site can ingest all the relevant content on its own.

A syndicated feed that's in desperate need of more content.

The page shows one featured note first, just the latest entry in the list. Five recent notes follow as cards. Finally, an archive section gives one row per note, grouped by year. There's just not enough content at the moment to fill that section out, so it stays hidden for now. Also, something you can't see just yet: a text filter appears after 15 or so entries and works just like the one in the field guide.

Finally, some changes to the API.

The API gives one file for each animal in the database. Since the data scrub, four of those files no longer exist: birds.json, small-mammals.json, reptiles.json and fish.json. The database itself no longer holds plant records for those animals. The API page documents the files that remain. Every other endpoint and every other shape stays the same.

What's next?

I want the other four animal types back. A rabbit owner needs this data as much as a dog owner does. I'm on the lookout for a reference that gives the symptoms per plant for birds, fish, reptiles and small mammals, but there's just not a lot of authoritative data out there. If you know of one, tell me in the comments below or on the contribute page.

I also want those 170 records back, but each one needs a reference that names the plant and gives the clinical signs. Until then, they stay on the back burner.

That pretty much covers it. It's been a fairly hectic week of coding and rolling out updates, but it's been a lot of fun. At the time of writing, the Reddit post sits at over 530 upvotes! It's always risky sharing something you've made with the world, but more often than not, people appreciate it. It really put a smile on my face.

Till next time!

Why I Rebuilt Plant Smart

Wilhelm Murdoch — Sun, 30 Aug 2026 00:00:00 +0000

Back in June I wrote a little blurb that said, in its entirety, "I should update Plant Smart." Bolder and more visionary words have never been written. So bold, in fact, I went right back to demolishing this blog instead and let the poor thing sit for another two months.

Well, I finally did the thing.

Three and a half years ago I wrote [Why I Built Plant Smart](https://wilhelm.codes/blog/why-i-built-plant-smart/). A free and searchable database of plants that are toxic to pets. I built it over a holiday break to answer a simple question, "Can I bring this plant home without endangering the fluffy little gremlin that runs our household?" It was also my excuse to learn SvelteKit, TypeScript, TailwindCSS and Vite, because my frontend peers wouldn't shut the hell up about them.

The site then chugged along quietly and untouched for years, which sounds like a compliment to its architecture and very much is not one to the maintainer.

The toolchain aged like fine milk.

The thing no one really thinks about when they build something like this with shiny new frontend tools is that it doesn't rust, it curdles. When I finally came back to give Plant Smart a fresh coat of paint, the build no longer ran. Not "a few deprecation warnings" didn't run. It didn't run at all. Two years of an unattended package.json had fermented into something of a cheese-like consistency.

My original requirements list from 2022 said the site must be fast, static, ( almost ) free to run and open with its data. Nowhere did it say "must still compile in two years".

So, I decided to spend a few weeks off and on to throw out the toolchain and give it a much-needed refresh. Just like this site, Hugo now builds the entire thing. There's a single hand-written stylesheet and a few small scripts of delicious vanilla JavaScript. No npm install, because there is no longer anything to install. If I disappear for another two years ( likely ), the site will build exactly the same the day I come back.

First things first, absolute parity.

The rebuild had one rule that saved me from myself: the first pass had to be a 1:1 replica of the old site. It needed the same pages, filters, URLs and quirks. The pass was meant to be boring on purpose. I had to resist the temptation of doing both the replatforming and redesigning all in one go.

My primary constraint was the plant data. Plant Smart's whole gimmick is what I called a "dumb API". The entire primary database lives in one JSON file with other, smaller, supplemental files you could use as lookup tables. Since this was all hosted on Cloudflare's CDN it was effectively free to use for others without keys or annoying rate limits. The old derivations were originally done by a pile of Go magefiles. The new site had to reproduce them exactly, down to the deliberately unsorted first-appearance ordering, or every downstream consumer would notice.

Hugo, it turns out, can do all of it. A content adapter reads the database and births every plant page directly with no intermediate files. A handful of templates re-implement the old Go derivation logic and regenerate the API on every build. I diffed the generated files against the originals and they came back value-identical on the first honest attempt.

Then came my favourite commit of the whole project:

retire the sveltekit stack: remove src, magefiles and the node toolchain
566 files changed, 112 insertions(+), 9905 deletions(-)

I deleted nearly ten thousand lines and the site did more than before. This is every developer's favourite kind of commit.

I made the site cute on purpose.

With the replica shipped, the redesign could actually be fun. The old site was fine but it was very much "2022 Tailwind starter" vibe. A lot of cool greys, hard shadows and gradients on anything that stood still. Meanwhile the logo, a randomised squishy little pastel potted plant with a face, deserved better surroundings.

So, I set out to make the logo the design brief. Cream paper instead of white with warm espresso ink instead of a dull grey. Sage and moss greens with honey and clay accents were all lifted straight from the icon set. Every shadow is tinted warm because plain black shadows on cream look like stickers. The corners got a bit rounder and the controls became pills. The whole thing is set in Fredoka, a rounded display face that weighs about 30kB which I thought fit perfectly with the cute little mascot.

Here are a few before and after shots of the main content pages, with a bonus shot of the new pill navigation that smaller screens finally got:

The data enrichments will continue until "Morella" improves.

Get it? No? Ok, I'll see myself out.

The database had severity ratings for every plant, computed from symptom groupings and the old site displayed them precisely nowhere. Now, every card has a severity pill rated from Mild to Critical. The pills are also clickable filters on the main page's plant cards. Search happens as you type and if you fumble the Latin a bit, a little Levenshtein pass offers "Did you mean Lilium?". I thought this was a little bit more helpful than what the old site did after literally joking about spelling mistakes in its empty state.

A few other mentionable updates:

A safe plants list, because the site only ever told you what not to buy. Every entry has to clear the ASPCA non-toxic list and be absent from my own toxic database before it's allowed in.
A symptom finder that allows you to perform a plant search backwards. You can click on multiple symptoms and it'll filter accordingly.
An emergency strip on every plant page with the poison-control hotlines. Unfortunately, for now, these are US numbers. Localising them by region is on the roadmap.
Wikipedia descriptions for nearly every plant credited under CC BY-SA.
Around 3,000 common-name redirects, so /plant/peace-lily/ finally lands somewhere useful.
Because it made sense, the whole thing is now a PWA and works completely offline. So, now you can use the site in a greenhouse with no signal, which is precisely where this site is most likely to get used.

My friends can no longer accuse me of trying to teach people how to poison their neighbour's pets.

— J'Accuse...!

Once I started auditing the data properly, I started to see a few additional gaps. There were several plants with multiple entries under different, but similar, names. I deduped and merged the symptom data and also updated the severity groupings to make more sense.

I also quickly realised that merging seizure into seizures would have silently promoted over a hundred plants to "Critical". The severity groups treated those two spellings as different levels. The little cleaner script I threw together caught it during a dry run. The script grew a rule about never merging across severity levels as a result. The plants that genuinely deserved promotion got one. For instance white snakeroot, the plant that killed Lincoln's mother, was somehow rated "Severe". The script properly re-rated it to "Critical".

The enrichment didn't stop there. I sourced proper taxonomy for every record via GBIF, per-plant toxicity principles with a glossary and little world maps showing their native origins.

There was also quite a bit of fat to trim.

Somewhere in all this I noticed every page weighed over 200kB. This included pages that were basically just copy. The culprits were painfully self-inflicted. There was an 85kB inline script shipping all ten animated logo SVGs to every single page. The same animal icon inlined seventy times on the front page. Oh, and let's not forget my personal favourite, the attributions page carrying 149kB of pure indentation that a template loop had quietly emitted. I was shipping whitespace at scale.

The fixes were old-school and very satisfying. A single fingerprinted and cached JS bundle, SVG sprites so each drawing only ships once and one well-placed whitespace trim yielded the following results:

page	before	after
home	247 KB	56 KB
attributions	238 KB	24 KB
safe plants	270 KB	33 KB
plant pages	114 KB	36 KB

No framework was harmed, or indeed present, in the making of this facelift.

We ship from the homelab now.

The last box to tick from the original post was the bittersweet one. In 2022 I wanted the project "open-source and community-driven" on GitHub. In practice, the community contribution was me, at midnight, fixing my own typos. So, the repository followed this blog into my homelab using the exact same moving parts as outlined in My Blog Now Ships From My Homelab!. It just made sense after this site's migration. The data remains as open as ever through the API, which was always the part worth opening. That will never change.

While migrating I had a small panic about the 315MB of plant photos sitting in my working tree, imagining every CI build hauling them across the network. Turns out my 2023 self had already gitignored them and the entire repository clones at 7.5MB. Every once in a blue moon past me does something right. I've decided to let sleeping dogs lie and not investigate what else he buried in there.

Was the juice worth the squeeze?

Very much so. The site is faster, cuter and finally says the most important thing it knows on every card: how dangerous is this plant, not just whether. It builds from nothing with a single binary and deploys itself when I push. The data is cleaner and more robust than it has ever been and enriched well past what 2022 me had the patience for.

But the honest win is the same one as the blog demolition. The whole thing is now boring to operate and boring is what lets a hobby project survive its maintainer's attention span.

If you have a plant-curious pet, [Plant Smart](https://plantsm.art) is free, the API is free and the safe list might even let you buy something nice for yourself. And if four years from now there's a third post in this series, may it be shorter than this one.

The data enrichments will continue until "Morella" improves.

— C'mon, this was a GREAT pun!

Anyways, adios...

My Blog Now Ships From My Homelab!

Wilhelm Murdoch — Wed, 26 Aug 2026 00:00:00 +0000

If you've given GitHub's status page a quick glance recently, you'll immediately see that it's been going through it. Every outage is a small reminder that maybe we shouldn't rely too much on single points of failure we can't directly control.

So, having been bitten several times by intermittent outages and service disruptions, I figured a small personal win would be to migrate the repository for this site to the homelab. Now, it lives on my own Forgejo forge and the builds run on my own Woodpecker cluster. The only things that leave the network are static build artefacts that get pushed up to Cloudflare Pages.

The switch was surprisingly straightforward and took less than 30 minutes overall.

Before anyone reaches for the comment box, no, you don't need a homelab for any of this. Forgejo and a Woodpecker cluster ( server and at least one agent ) will happily run on a spare mini PC, an old laptop, that Raspberry Pi you bought with the best of intentions or even as a single Docker Compose file running on the machine you use every day.

How complex can this possibly be?

The first useful thing I did was ask myself what GitHub was actually doing for me when it comes to managing this site. After some mulling about, I could only really list the following:

Hosting a git repository.
Hosting the comment threads, via giscus Discussions.

That's pretty much it. I don't use Actions and GitHub alone never built this site. Cloudflare Pages watched the main branch and did the building itself. This is something I covered back in My Blog Publishing Setup. GitHub's one job was holding a bunch of markdown files.

That's a strange thing to accept as a single point of failure.

The new shape of things.

The replacement looks like this:

I push to Forgejo, which lives inside my homelab network.
Forgejo fires off a message to the Woodpecker Server over a webhook. Also inside the network.
The Woodpecker Server assigns the job to an available Woodpecker Agent, which clones the repo, builds the site with Hugo and pushes the result to Cloudflare Pages with wrangler.
Cloudflare serves the files at the edge, exactly as before.

I just added support for mermaid diagrams, so of course I'm not going to let the opportunity to show it off slide:

sequenceDiagram
    participant D as The desk
    participant F as Forgejo
    participant W as Woodpecker
    participant C as Pages
    D->>F: git push ( main )
    F->>W: webhook
    W->>W: diagrams, changelog, hugo --gc
    W->>C: wrangler pages deploy
    C-->>D: the same site, but newer

The part I want you to notice is the direction of travel. Under the old setup, Cloudflare reached into GitHub to pull my source. Under the new one, nothing reaches in at all. The forge and the CI server accept no traffic from the internet. The only packet that crosses the network boundary is an outbound upload of compiled static assets.

That reversal is the entire security model which was pretty much the point. What looks like "the old way but more steps" allows me to control every aspect of the pipeline up to just before we ship the build artefacts. A push-based deploy means self-hosting your forge requires exposing exactly nothing. No reverse proxy gymnastics, no VPN for the webhook and no port forwarding required.

If my homelab bursts into flames mid-afternoon ( a real possibility as I do live in Queensland, Australia ) Cloudflare keeps serving the last deploy and nobody visiting the site would ever know. That being said, nobody actually does visit this site, so...

A small intermission.

A short aside, because it's a question I'd ask. My internal services hang off a domain I genuinely own, but resolving it depends on where you're standing. Inside the network a locally hosted 3-node Technitium cluster runs the hosted zone and the router sends all DNS requests through it. Initially, I used this for network-wide adblock, which works an absolute treat. It also means the forge and the CI cluster resolve to their internal addresses. Outside the network, the public zone points at a landing page hosted elsewhere.

Same hostname and two completely different worlds depending on which side of the wall you're on. Split-horizon DNS is nothing new, but it's what lets me use real TLS-friendly hostnames for internal services without those services ever being reachable from the internet.

If I did decide to open some services to the outside world, like my Navidrome server, I could use an overlay network like Netbird to provide friends and family access via a familiar naming convention without ever opening a port on the router.

The part Cloudflare doesn't clearly advertise.

A Pages project is either connected to a git provider or it accepts direct uploads. Never both. As long as your project is wired to GitHub, wrangler pages deploy will be rejected and you will get screamed at.

Disconnect the git integration in the project settings and the project quietly converts to "Direct Upload" mode. It keeps its name, its custom domain and its whole deployment history. It just stops watching a repository and starts waiting for you to hand it those delicious files. While you're in there, make sure the production branch is properly specified: main in my case. This matters because Wrangler tags each upload with a branch name. An upload whose branch matches the production branch goes live on the site. An upload under any other name becomes a preview deployment with its own URL instead.

After that, the deploy is one command requiring two secrets:

An API token scoped to Cloudflare Pages: Edit
Your Cloudflare account ID.

Both go into the Woodpecker Server as repository secrets.

Finally, our favourite! YAML.

The whole thing is just one file named .woodpecker.yml that squats in the repository root.

when:
  - event: [push, manual]
    branch: main

clone:
  git:
    image: woodpeckerci/plugin-git
    settings:
      partial: false
      tags: true

steps:
  diagrams:
    image: minlag/mermaid-cli:11.16.1
    commands:
      - ./bin/render-diagrams

  build:
    image: hugomods/hugo:debian-git-0.163.3
    environment:
      HUGO_ENV: production
      HUGO_ENVIRONMENT: production
    commands:
      - git config --global --add safe.directory '*'
      - ./bin/changelog
      - hugo --gc

  deploy:
    image: node:22-slim
    environment:
      CLOUDFLARE_API_TOKEN:
        from_secret: cloudflare_api_token
      CLOUDFLARE_ACCOUNT_ID:
        from_secret: cloudflare_account_id
    commands:
      - >-
        npx --yes wrangler@4 pages deploy public
        --project-name=wilhelm-codes
        --branch=main
        --commit-hash="${CI_COMMIT_SHA}"
    when:
      - event: push

Only build off `main`.

I test design changes and new entries locally, so a push to any other branch doesn't start a pipeline.

We want a full clone, not a shallow one.

This site's changelog page renders the git log and Hugo's enableGitInfo reads commit dates for every page. This is something I wrote about in A Changelog That Builds Itself. CI systems love shallow clones and a shallow clone here means I can't convey the full historical picture on the page. Worse, enableGitInfo derives every article's dates from that same truncated log, so they all come out wrong besides. Setting partial: false makes Woodpecker fetch the entire history.

Diagrams render before anything else.

Articles on this site can embed Mermaid diagrams, like the sequence diagram further up the page. They render to static SVG at build time, not in your browser, so the site ships zero diagram JavaScript. A small script hashes each diagram's source, renders anything that has no matching SVG yet and prunes any SVG nothing references any more. I run it locally and commit the SVGs alongside the content, which means on a clean commit this step does precisely nothing. It exists as a safety net for the day I inevitably forget.

So when I said the diagram was rendered by the pipeline it describes, I meant it literally. If I ever edit that diagram and forget to render it, this step is what quietly saves the deploy.

The build step is a stock Hugo image.

Nothing is installed on the agent itself unless you count Docker image pulls. The image pins the exact Hugo version, ships the extended edition and includes git and bash. Both of which the changelog script that generates the data requires. The safe.directory line exists because the cloned workspace is owned by a different user than the one inside the container and git these days refuses to read a repository it thinks you stole.

The deploy step is a stock Node image.

npx pulls Wrangler at run time. Wrangler then reads the two secrets from the environment and pushes public/ up to Pages and that's pretty much it. Dependencies are snagged and cached at build time, which means nothing to maintain on the agents. Either step's version gets bumped by editing one line.

Info: I already have distribution hosted in the homelab for my local Docker images. I could easily configure it to support pull-through caching, so I don't keep having to pull directly from Docker Hub every time a build agent's local cache expires.

Complete parity with what Cloudflare's own build pipeline was doing, except now I can read every line of it and make it do whatever I need.

I did run into some speed bumps along the way.

For the record, it took only three tries to get the pipeline to a "green" state.

Third time's a charm.

In order of discovery:

The plain version tags of the Hugo image are the extended edition. The reg- prefix means regular and none of them include git unless the tag says git. The tag you guess first ( exts-<version> ) doesn't exist. It's an odd convention, which is why it threw me off.
Woodpecker substitutes ${VAR} expressions in the YAML before the shell ever runs. Anything it doesn't know becomes an empty string. My safe.directory "${CI_WORKSPACE}" quietly became safe.directory "". Hence the asterisk / glob in the YAML.
The changelog script opens with #!/usr/bin/env bash and the default Hugo images are Alpine. env: can't execute 'bash' is the whole error message you get, so I just went with the Debian variants instead which include bash out of the box.

None of these are hard problems, but worth pointing out.

I'm not deleting the old repository... completely.

The GitHub repository still exists if only to provide a place for the giscus integration to store comments. It offloads most of this functionality to GitHub's Discussions feature. Delete the repo and every comment ever left on this site goes with it; all 2 of them.

It no longer needed the full source history to do that job either. It was ported on over to my local forge with Forgejo's native GitHub repository migration feature. So, I force-pushed the whole history into a black hole, leaving a single commit containing only a README. The remaining husk also has a second job coming; it'll eventually host the companion code for tutorial content, so readers can clone examples without ever touching my forge.

Each service kept exactly the job it's uniquely good at. Cloudflare serves files from the edge better than my house ever could and no fucking way am I publicly opening ports on a router. I'd rather lick the rim of a pub toilet. GitHub Discussions gives commenters an identity they already have. Everything else now lives at home.

In closing ...

Was any of this necessary? For a static blog that deploys in under a minute, probably not. The old setup worked fine and if yours does too, keep it. I'm not here to convince anyone.

There's a special kind of satisfaction in watching a pipeline run end to end on hardware you can physically point at, knowing the only cloud dependency left is the one actually earning its keep. The next GitHub outage can happen without me. At least for this project anyway.

Glazier Release: v0.1.5

Wilhelm Murdoch — Mon, 24 Aug 2026 00:00:00 +0000

Today, I minted and tagged Glazier v0.1.5. Immediately after, realised I never announced v0.1.4, the release with all the actual features in it. So, Happy Birthday, you get a twofer.

Let's get `v0.1.5` out of the way first.

There's not much to see here, honestly. This is a routine housekeeping and dependency bump release. The only change worthy of a mention is is a bump of golang.org/x/text to address GO-2026-5970. This is the sort of thing you patch promptly even when the practical exposure for a tmux wrapper is nil ( ha-ha-ha ). Alongside that, the Go toolchain moved up to 1.26.4 and testify, urfave/cli and a stack of GitHub Actions all got their routine nudges courtesy of Dependabot. Hey, thanks little buddy!

Download the latest release, replace your current binary and you should be good to go.

`v0.1.4` is where the features live.

Info: Before we get into it I should point out this release introduces a few breaking changes to the spec that should be easy enough to resolve thanks to Glazier's awesome built-in error reporting.

Back in July I wrote about adding typed variable blocks to Glazier. That work shipped on July 17th as v0.1.4.

The short recap, if you didn't read that post is that profiles can now declare the inputs they accept as first-class variable blocks. Just like, you guessed it, Terraform. Each block can carry a primitive type (string, number or bool), a default and a description. No default means the variable is required. Pass a --var the profile never declared and you get a proper located error.

Values are read through the var. namespace and only that namespace:

variable "district" {
  description = "the district the gig is themed after"
  type        = string
  default     = "watson"
}

variable "fixer" {
  type = string
}

session {
  name = "gig-${var.district}"

  window {
    name = "${var.fixer}-ops"

    pane {
      commands = ["echo ${var.fixer} has the next job"]
    }
  }
}

$ glaze up --var fixer=wakako
$ glaze up --var district=arasaka --var fixer=wakako

That post covers the design reasoning, the type coercion and the breaking namespace migration in detail. So, no need to reshash it all here. What it doesn't cover is everything else that snuck into the release after I hit publish button.

Support for locals.

Variables are inputs. They cross the boundary from the outside world into your profile via --var flags, var files or defaults. But the moment I had proper variables I ran into their natural companion problem; derived values. The thing you compute from an input once and then want to reuse in five places without copy-pasting the same expression five times.

Terraform solves this with locals and, because Glazier remains an unapologetic love letter to Terraform's parser, it does as well:

variable "district" {
  default = "night city"
}

locals {
  slug    = lower(replace(var.district, " ", "-"))
  session = "gig-${local.slug}"
  logfile = "${path.pwd}/logs/${local.slug}.log"
}

session {
  name = local.session

  window {
    name = "${local.slug}-ops"

    pane {
      commands = ["tail -f ${local.logfile}"]
    }
  }

  window {
    name = "editor"

    pane {
      commands = ["nvim"]
    }
  }
}

You declare named values in a locals block at the top level and read them back through local.<name>. Plural block and a singular reference is exactly how Terraform does it.

A local can reference the var.*, env.*, path.* namespaces, the whole function library and, crucially, other locals. In any order. This works fine:

locals {
  session = "gig-${local.slug}"                    # references slug...
  slug    = lower(replace(var.district, " ", "-")) # ...declared after it
}

Under the hood resolution just keeps iterating, evaluating whatever it can each pass until the end. Whatever's left over then reports its real evaluation diagnostics, so a genuine fat-fingered mistake surfaces as the actual error rather than being masked by ordering machinery. If you accidentally declare the same local twice you'll get told exactly where both declarations live.

The one thing you can't do with a local is set it from the command line and this is by design. Variables are the contract with the outside world; locals are private. If a value should be overridable, it's a variable. If it's just an expression you're tired of repeating, it's a local. Having the language enforce that distinction is one of those small things that keeps a profile clean as it grows.

They also pair nicely with the new random function and HCL's inline comprehensions, both of which landed in this release too:

locals {
  editors = ["nvim", "hx", "vim"]
  greeting = random([for g in ["hello", "choom", "wake up samurai"] : title(g)])
}

random(list) returns a uniformly random element of a list as a string. Did anyone ask for this? Absolutely not, but you deserve nice things.

lol... lmfao.

The July post ended with me musing about adding *.tfvars-style functionality and asking, and I quote, "Surely, I won't fall for this again?"

He, indeed, fell for this again.

— narrator

Yeah, so v0.1.4 also ships with --var-file support:

# gig.vars
district = "japantown"
fixer    = "wakako"

$ glaze up --var-file gig.vars
$ glaze up --var-file gig.vars --var fixer=dino

A var file is plain HCL; a name = value attributes written once per line. I originally supported JSON files too and then ripped that out before release, because maintaining a second parse path for a format nobody was going to use failed the smell test. In other words, "YAGNI".

Precedence works the way you'd expect: defaults go first, a var file overrides defaults and an explicit --var flag always has the final say. In the second command above fixer comes out as dino no matter what the file thinks.

Strictness from the flag side applies here too. An entry in a var file that names a variable the profile never declared is an error. Values are coerced to their declared types and every problem in the file is reported all at once for convenience.

Our first contributor has entered the chat!

This release contains the first fix from an actual outside contributor. ThreeToes tracked down an annoying initialisation bug where the first window in a profile would be ignored and cleaned up on startup. Leaving you with either a stray default terminal or only the subsequent windows.

Someone who isn't me not only ran the thing, they read the source and fixed it. That's a genuinely lovely milestone for a hobby project. Thanks, man!

Oh, and the repo finally has a proper SPEC.md. A full reference for the profile format describing every block, namespace and function.

In closing ...

Release notes are like backups. Everyone agrees they're important and nobody does them until it's embarrassing.

As always, it's up on GitHub under MIT. If you've got Go installed:

$ go install github.com/wilhelm-murdoch/glazier/cmd/glaze@latest

Or, grab a prebuilt binary from the releases page, checksums and provenance attestations are included. Small note on this, I do plan on adding support for all your favourite package managers to make this process a bit more intuitive. Homebrew first as a test run, then all the other you'd expect.

If you've opinions on locals, var files or what Glazier should learn next, the comments are right below.

P.S. - I've another secret project in the works and I'm using it to declaratively generate Open Graph social cards for the blog. I thought I'd create a format dedicated to Glazier releases.

Generated using HCL and Ogre...

Some Long Overdue Demolition

Wilhelm Murdoch — Sun, 23 Aug 2026 00:00:00 +0000

Two months ago I wrote Some Long Overdue Housekeeping. A post about giving this blog a proper facelift. I untangled my Tailwind setup, modernised Hugo and taught it to drive the compiler natively and generally felt very pleased with the state of things.

So, of course just weeks later I have this burning desire to nuke it all from orbit!

This means no more standalone Tailwind config, no committed stylesheet, no node_modules in static/ and no build toolchain leaking onto the live site. Very cool!

— me, in June, admiring a thing I have since bulldozed

To be clear, the June cleanup wasn't wrong. The pipeline was genuinely tidy. But, a tidy pipeline is still a pipeline and somewhere between then and now I started asking a more annoying question: why does a personal blog, a pile of static text, need a JavaScript toolchain at all? Why do I need to buy into the Tailwind framework when I knew full well how to write vanilla CSS with my own hands? Every npm install was a little tax that I'd eventually have to pay with interest the next time I wanted to update the site's dependencies. I felt as if I wasn't maintaining a blog. I was maintaining the machinery that produces a blog and the machinery had some very strong opinions.

So, I did a hard reset with a very satisfying amount of deleting.

The demolition ...

Here's the bill for the redesign commit:

230 files changed, 3951 insertions(+), 33365 deletions(-)

That's roughly a 10-to-1 ratio of deleted to written. Which, as a software engineer, is my favourite kind of ratio. I happily added the following the to chopping block:

Tailwind v4 and the typography plugin. Replaced by one hand-written CSS file. The whole thing gzips to under ~10kB with syntax highlighting included.
The entire Node toolchain. The package.json, lockfile, Prettier and its plugins. There is no npm install step anymore because there is no npm anymore.
Fuse.js and the ⌘K search palette. Nobody was searching this blog. I checked. It was me. I was nobody.
Two self-hosted webfonts. More on this in a second, because it's the biggest single win.
The changelog page. This pulled from the GitHub events API and shipped with an 18,016-line JSON fixture for local dev. Eighteen thousand lines of someone else's API response, committed to my repo. So, a page barely anybody visited could render in development. I mean, I added it back becase I missed it, but it's much more efficient now.
68 of the 79 icon SVGs. A 390-line drawer menu and a taxonomy I'd stopped using.

The layouts went from 2,868 lines of template across 48 files to about 800 lines across 21. Not because I got cleverer, but because most of that code was written for the joy of it. Which, look, is a fine reason to build something. It's just a bad reason to keep serving it to strangers. And with all that complexity and cruft came what felt like a lot of brittleness.

The fonts had to go too.

This one hurt a little. I like Inter and Rubik. Together they were 449kB of woff2 riding along on every first visit. Which made them, by an enormous margin, the heaviest thing on the site.

So, I dropped them and switched to the system font stack which, to my surprise, actually looked better on the site. The actual typeface was doing very little. Your operating system already ships a perfectly good set. All lovingly hinted by people with far more patience and experience than myself. Best of all it costs zero bytes to use!

By Grabthar's hammer... What a savings.

— Dr. Lazarus from Galaxy Quest

Hugo, finally home alone.

Thanks to all the trimmed fat, the build process is effectively just hugo. No more extended binary, SCSS, image processing or defining NODE_VERSION in Cloudflare Pages required. Fewer dependencies mean fewer moving parts and that's always an improvement.

Numbers, or it didn't happen.

Right after the deploy I proudly measured the new site and announced it was "under 100kB". Which would have been true if the production site were served by my dev server, uncompressed, with a 40kB livereload script attached. I made the mistake of measuring the network stats on my local development server. Womp, womp.

The real numbers, from the live site with Cloudflare's brotli doing its thing:

	Before	After
Cold home page	`~750kB`	`~24kB`
Webfonts	`449kB`	`0kB`
Stylesheet ( compressed )	it's complicated	under `~10kB`
`npm install`	required	there is nothing to install

The single largest asset on the home page is now the favicon. 7.5kB; roughly a third of the total weight. I think you're allowed to stop optimising when your largest single asset is your favicon.ico. It's an image of my gorgeous mug. It stays. I'm quite attached to it.

An ambitious first pass.

In retrospect, I wanted to make everything simpler and unintentionally over-compensated in the opposite direction. I stripped out too much and was now staring at a sad little blog with zero personality.

So, the second half of the job was building the personality back and making my selections a bit more deliberate. One thing led to another and I think I've produced my finest work yet on a personal blog. It's small and lightening fast. I'm not sure where else I can optimise without drastically affecting the overall vibe of the design; the law of diminishing returns... returns.

The thing about now having such a light frame is adding to it stops feeling like a burden, or something future Wilhelm will have to pay. For example, here are the biggest things I've added and they barely increased the overall "weight" of the design.

Series

A proper taxonomy for multi-part writing. Built because I've been wanting to write a Cyberpunk-themed set of tutorials for writing advanced HCL in Go. The series will be about eight posts long and outside of sharing a tag, I had no way to string them together. Series posts wear a stacked-sheet card, a segmented progress meter that is absolutely not a cyberdeck RAM readout and a panel showing every part in the run, including the ones that don't exist yet.

The unpublished parts of a series ship as glyph noise and decode, left to right, when you point at them. The real titles sit in aria-label the whole time, so a screen reader is never handed the static. The browser tab pulls the same trick on every page load, because a title bar is just a very small marquee nobody was using.

Try moving your mouse pointer over some of the "encrypted" titles on the new dedicated page.

Tired LEDs

The lit chips in the series meters, static leaders in the main page's hero section and a scattered handful of cells in the activity graph flicker like hardware that has seen some things. Their animation clocks share no common factors, so the pattern never visibly repeats. The same no-RNG randomness as the heading glitch. On page load the whole graph boots like an old panel, dark, then a sputter per cell, then steady stream of blinking boxes. Reminiscent of the old monochrome screens and beige boxes of my youth.

Christ, I'm getting old.

Changelog, resurrected

Yes, the one from the butcher's block above. However, instead of hitting the associated Github repository directly at build time using a PAT, the new one doesn't call anyone. Commit data is sourced directly from Cloudflare Pages' shallow clone it checks out during build time. There's a simple 20-or-so-line shell script reads git log and Hugo renders the result. HEAD gets a lit node that flickers, because why the hell not?

Image shortcodes

Something I've been meaning to add is support for various ways to display images. Each image can now be clicked-to-zoom with attribution in the following forms:

Masonry.
A scrollable, horizontal display.
Last, but not least, the typicla single image display.

There's actually a sneaky, super-secret page I use to test all my shortcodes and typography stylings where you can see everything for yourself.

Even with all these complex additions, it all adds up to a few kilobytes of CSS and inline script. Which is to say the entire second wave of features weighs an order of magnitude less than one of the webfonts I deleted.

My new favourite fidget toy.

The part I didn't expect was to glue my eyeballs to the Firefox throttle menu under its network tools panel.

I flipped it to a 2G profile just for shits and giggles - call it a generous 50kb per second - and did the napkin math. The old site's 750kB works out to between 60 to 90 seconds of staring at a blank viewport. The new site lands in about four seconds on a connection profile most of the industry stopped thinking about a decade ago.

I have reloaded this page on simulated garbage networks far more times than any reasonable person should, and it is satisfying every single time. The page just... appears. Like a website. Remember plain'ole websites?

None of this is novel, I know. The "your blog doesn't need 2MB of JavaScript" essay has been written a hundred times. Usually on a blog serving 2MB of JavaScript. I'm not even the hundred-and-first person to do this. But, there's a difference between nodding along to the idea and watching your own site load over a simulated tin-can connection before you can finish blinking.

In closing ...

The funny thing about the June post is that it ended with me feeling like the blog was finally sorted. And it was! For the architecture it had. It just turned out the architecture itself was the thing that needed to go.

The site is now boring in the best possible way. It builds with one command, it has no dependencies to rot behind my back and the whole design fits in one stylesheet I can actually hold in my head ( not really ). Fewer moving parts, fewer things to forget, fewer surprises the next time I touch it in six months. Best of all, it looks fucking great!

Set-and-forget, but this time with almost nothing left to forget. ... Right?

It's OK to Let Go

Wilhelm Murdoch — Fri, 17 Jul 2026 00:00:00 +0000

So, I’m a sucker for wordplay and puns. Anyway…

There’s a line in my shell history that goes back to 2022: go get github.com/wilhelm-murdoch/go-collection. For years it was the first dependency into almost every Go project I tinkered with, sometimes before I’d even give the idea a solid shape. I’d open Neovim, initialise a module and then my little collection library got pulled in. Just like muscle memory.

Today I’m archiving it. Not because it broke and not because I got bored of it, but because the Go standard library quietly walked up and did its job better than it ever could. This post is part explanation and part eulogy, because I think we’re generally quite bad at ending software on purpose and it’s worth practising in public.

Why even write it in the first place?

Waaaay back in 2022 Go 1.18 had just shipped generics after roughly a decade of the community asking, arguing and writing increasingly unhinged interface{} workarounds. I wanted to actually learn the new type parameter machinery rather than just read about it and I was also deeply tired of writing the same for loop to check whether a slice contained a thing for the hundredth time.

So go-collection happened. A single generic Collection[T] type wrapping a slice, with all the conveniences I kept reaching for: Contains, Find, Filter, Map, Sort, Batch, Push, Pop and a few dozen friends. All chainable, fluent, tested and small.

There are far more comprehensive modules out there, but this one works quite well for my purposes. me, in the README, setting expectations appropriately for once

That sentence was doing more work than I realised at the time. It wasn’t trying to compete with the big functional-utility libraries. It was scratching a personal itch and for a few years it scratched it well. Then Go’s standard library grew and slurped most of it up.

Taking a trip to the morgue.

Cause of death is easy to establish here, because it happened in three well-documented releases. Go 1.21 shipped the slices package. Go 1.22 and 1.23 finished the job. Let’s walk through it, method by method, like the nerds we are.

Does it have the thing?

The bread and butter. Probably eighty percent of my actual usage of this library was some flavour of “is this thing in there?”:

fruits := collection.New("apple", "orange", "strawberry")

fruits.Contains("orange") // true

fruits.FindIndex(func(i int, item string) bool {
    return strings.HasPrefix(item, "str")
}) // 2

As of Go 1.21, the standard library does both on a plain slice with no wrapper type in sight:

fruits := []string{"apple", "orange", "strawberry"}

slices.Contains(fruits, "orange") // true

slices.IndexFunc(fruits, func(item string) bool {
    return strings.HasPrefix(item, "str")
}) // 2

No New, no .Items() to unwrap at the end when some other API wants a real slice. It’s just my function with better ergonomics and a compiler team maintaining it. I’m fine with this.

Sorting, where I don’t even get to feel bitter.

Here’s my Sort. I want you to look at what using it actually required:

numbers := collection.New(3, 1, 4, 1, 5)

numbers.Sort(func(i, j int) bool {
    left, _ := numbers.At(i)
    right, _ := numbers.At(j)
    return left < right
})

Index-based comparators, so you had to reach back into the collection you were currently sorting to get at the values. I inherited that design from the old sort.Slice idiom and it was clunky then too. The modern equivalent:

numbers := []int{3, 1, 4, 1, 5}
slices.Sort(numbers)

And when you’re sorting something with actual structure, SortFunc hands you the two elements directly, with cmp.Compare doing the boring part:

slices.SortFunc(people, func(a, b Person) int {
    return cmp.Compare(a.Age, b.Age)
})

This isn’t a case of the standard library catching up to my library. It blew my version right out of the water.

The killing blow came with iterators.

Go 1.22 added slices.Concat, which retired my Concat. Fine, that one was three lines anyway. But Go 1.23 shipped range-over-function iterators and with them slices.Chunk, and that’s the release where I stopped pretending this was still a contest. Batch was one of the few methods I was genuinely proud of:

records.Batch(func(batch, index int, item Record) {
    // process item as part of batch N
}, 100)

Now it’s a language feature wearing a standard library hat:

for chunk := range slices.Chunk(records, 100) {
    // chunk is a []Record of up to 100 items
}

A real for loop. You can break out of it, continue past things and return early. My callback-based version couldn’t do any of that without contorting itself. The trouble is that a wrapper library can only ever be as expressive as the language it wraps and the language just grew.

The stuff that never needed a library.

An honest confession while we’re standing over the body: a decent chunk of the API never deserved to exist in the first place. Push, Pop, Shift, Unshift. I wrote JavaScript for years before Go was ever a public thing and apparently nobody walks away from that unscathed.

c.Push("e") // s = append(s, "e")
item, ok := c.Pop() // item = s[len(s)-1]; s = s[:len(s)-1]

The comments on the right are the entire implementation. Idiomatic Go slice handling was already good at this in 2012. Those methods existed because my fingers missed Array.prototype, not because Go was missing anything.

The “survivors”, if you could even call them that.

Here’s the wrinkle that makes this more interesting than a straight obituary. Map, Filter, Reduce, Some, None; the functional stalwarts still aren’t in the standard library, all these years later. On paper, that’s the corner of the market my little module could have retired to. A niche! Sustained relevance!

Except, no. First, because my Map had a secret shame:

func (c *Collection[T]) Map(f func(int, T) T) (out Collection[T])

See it? T in, T out. Go methods can’t introduce new type parameters, so a method-based Map can never change the element type. Strings to strings, ints to ints. A Map that can only map onto itself is a Map in vibes only; the moment you want lengths of strings you’re back to writing a loop anyway.

And second, more fundamentally: the Go community collectively shrugged and decided the loop was fine. The proposal discussions happened, the experiments ran and the ecosystem largely settled on this:

names := make([]string, 0, len(ducks))
for _, duck := range ducks {
    names = append(names, strings.ToUpper(duck))
}

Four lines. Obvious to anyone who’s read any Go at all, no import, nothing to learn, nothing to maintain and debugger-friendly. Even where go-collection wasn’t superseded, it turned out to be unnecessary, which is somehow a more thorough defeat.

Software is a tool, not a legacy.

So that’s the technical half. Here’s the part I actually wanted to write about.

We don’t really have a culture of finishing software. A project is either “actively maintained” or it’s “abandoned”, with all the guilt that word drags behind it. Issues accumulate, badges rot and the README slowly becomes a lie because nobody wants to be the person who admits the thing is done, or no longer necessary. I’ve had this module sitting in that limbo for a while now, still getting pulled into new projects out of habit while a strictly better replacement sat in the standard library the whole time.

But software isn’t a legacy; it’s a tool. Tools serve a purpose. This one’s purpose was to teach me generics in their first year of existence and to spare me a few thousand for loops while the language sorted itself out. Purpose served on both counts. And of all the ways for a library to die, being absorbed by the standard library is the best one available. It means the gap you filled was real and now it’s just gone, fixed at the correct layer, for everyone and forever. That’s not a failure state. That’s the mission succeeding so hard the mission ceases to exist.

Keeping it alive from here would mean maintaining a slightly worse, slightly slower, personally-branded copy of slices out of pure sentiment. Nobody needs that, least of all me. I’m busy enough and would much rather move on to newer, more interesting things.

The practical bits.

So today, the repo gets the full send-off:

A deprecation notice at the top of the README, pointing anyone who lands there at the slices package and at this post.
The repository gets archived on GitHub. Read-only, clearly signposted and locked in eternal statis.

If you’re one of the however-many people with this module in a go.mod somewhere nothing breaks. The Go module proxy caches published versions more or less permanently, so v1.0.11 will keep resolving long after we’re all dust. Archiving just makes the end of our relationship official rather than leaving it implied.

If you’ve got a little module of your own in the same situation that has been superseded, purpose spent, kept alive out of habit, then consider this your permission slip. Write the notice, hit archive and go build that next thing. An honest ending is a kindness to your users and to yourself. It’s OK to let go.

Here is an example of me tearing go-collection out of my very recent Glazier project. This one stung a little at how easily it was replaced.

In closing …

Thanks, little buddy. You were there before the ecosystem knew what generics were supposed to look like, you appeared in more of my go.mod files than any dependency I didn’t write, and you were, right to the end, exactly as comprehensive as I needed you to be.

go get in peace.

I Added Variable Block Support To Glazier

Wilhelm Murdoch — Wed, 01 Jul 2026 00:00:00 +0000

I knew the moment I thought about potentially adding variable definition blocks as a first-class feature Glazier it was going to bother me until I went about implementing it. So, as expected, a week later, here we are. I am happy to report that I've maintained my spotless record of not talking myself out of something tricky.

So, over the course of the past few days Glazier learned a new trick. Profiles can now declare the variables they accept, give them primitive types, mark them as required and read them back through a proper var. namespace.

Out with the old.

Technically speaking, Glazier has had variable support since day one. You could pass --var region=watson and reference ${region} anywhere in your profile and that was that. Anything you passed got dumped into a flat namespace and any name you referenced, but forgot to set, quietly resolved to an empty string.

That's fine right up until you fat-finger ${reigon} and spend ten minutes wondering why your session name has a hole in it. The whole reason I built this thing was to get Terraform's "here is exactly what you did wrong and where" experience.

Letting variables fail silently just felt a bit like an own-goal.

Profiles can now declare what they accept.

Because this whole thing is kind of a love letter to Terraform's parser, the idea behind variable definitions is functionally the same. You declare a variable block, it sits at the top level next to your session and that's the input you're allowed to pass:

variable "district" {
  description = "the district the gig is themed after"
  type        = string
  default     = "watson"
}

variable "fixer" {
  type = string
}

session {
  name = "gig-${var.district}"

  window {
    name = "${var.fixer}-ops"

    pane {
      commands = ["echo ${var.fixer} has the next job"]
    }
  }
}

First, you reach a variable through var. and only var. now, so it reads exactly like it would in a .tf file. Second, district has a default and fixer doesn't, which turns out to matter quite a lot in a second.

$ glaze up --var fixer=wakako # district falls back to "watson"
$ glaze up --var district=arasaka --var fixer=wakako

So, here you are using the same templated profile to define two seperate sessions decided entirely by flags.

Pass it something it doesn't know and it says so.

If you pass a --var for a variable the profile never declared, you no longer get a silent shrug. You get a proper error:

Error: Undefined variable

A value for "ghost" was passed with --var, but the profile declares no
variable "ghost". Add a variable "ghost" {} block, or remove the flag.

I went back and forth on this one. Being strict about undeclared flags is the sort of thing that feels pedantic until the day it catches a typo you'd have otherwise chased for half an hour. In this case strict won.

A --var you can't explain is almost always a mistake, so Glazier now treats it like one.

No default means you have to mean it.

A variable without a default is required. Leave it unset and up refuses to do anything until you supply it:

Error: Missing required variable

  on .glaze line 6, in variable "fixer":
   6: variable "fixer" {

The variable "fixer" has no default, so a value must be supplied with
--var fixer=<value>.

This is the bit that makes a profile a genuine contract rather than a suggestion. If a layout is useless without a fixer, declare fixer with no default and the tool will make absolutely sure you provided one before it touches tmux.

Proper type-checking.

Every variable declares a type. Use one of the bare keywords string, number or bool. The value you hand over on the command line is coerced into that type and rejected if it doesn't fit:

variable "base_index" {
  type    = number
  default = 1
}

$ glaze up --var base_index=two

Error: Invalid variable value

  on .glaze line 1, in variable "base_index":
   1: variable "base_index" {

The value passed for variable "base_index" with --var cannot be used as
number: a number is required.

two is not a number, so you find out before anything launches rather than after tmux has already swallowed a garbage option and started behaving oddly. Booleans get the same treatment: true and false are fine, anything else is shown the door. Unfortunately, I decided not to go with truthy or falsey value coercion.

I kept it to the three primitives on purpose. The moment you add list(string) and friends you're also signing up for coercing comma-soup off the command line into nested types. That's a much bigger can of worms than a tmux helper needs to open today.

Though, obviously, if you disagree you're more than welcome to leave a comment below!

A namespace for everything.

I'll be honest about the consequence here. This is a breaking change and pretending otherwise would be rude. The old flat ${region} style is gone. If a value comes from a declared variable, you read it as var.region.

Which raised a genuinely interesting design question I sat with for a while. If variables are only ever used inside a session, why not declare them inside the session block too? It feels more intuitive at first though, but it's also wrong.

However you nest the declaration, the reference is still flat and global; you write var.fixer, never session.var.fixer. Declaring something file-global but reading it block-scoped is incoherent and a variable is really an input to the invocation, sitting conceptually above the session and not a property of it. So they live at the top level, exactly where Terraform puts them. I borrowed both the syntax and the reasoning.

Where did the environment variables go?

They also got their own namespace. Previously GLAZE_ENV_token showed up as a bare ${token}, sharing the same flat namespace as everything else. Now it lives under an env. namespace, which makes the three sources nicely symmetric:

var.* for variables you declared and passed with --var
env.* for GLAZE_ENV_* environment variables
path.pwd & path.base the unchanged built-ins

session {
  name = "host-${env.box}"

  window {
    pane {}
  }
}

$ GLAZE_ENV_box=nightcity glaze up

session = host-nightcity

There's no declaration needed for env.*; the environment is the environment. Only the things you pass with --var have to be declared, because those are the inputs you are claiming the profile accepts.

Tearing down a session.

If a required variable now blocks up, doesn't that wreck glaze down? I recently taught the down command to evaluate only the session name so it doesn't need every variable buried deep in the profile just to kill a session. Surely required variables undo that?

They don't and this was the fiddly bit to get right. down resolves variables leniently. A variable used solely in some pane command, far away from the session name, is neither required nor evaluated when you're tearing things down:

variable "beep" {
  type = string
}

session {
  name = "daemon-run"

  window {
    pane {
      commands = ["echo ${var.beep}"]
    }
  }
}

$ glaze down
INF nothing to do; session is not running session=daemon-run

If beep isn't provided, the command just accepts it and moves on, because down never needed it. up enforces the full contract; down only asks for what the name actually depends on. Obviously, the exception here is if a variable is used to construct the actual session name. Other than that, this is an idempotent no-op.

Validation has been updated too.

glaze format --validate decodes a profile and reports diagnostics without ever touching tmux and it now enforces the entire variable contract. Miss a required variable and validation fails right there:

$ glaze format --validate
Error: Missing required variable
  ...

$ glaze format --validate --var region=us-east-1
# clean. nothing to report.

So, you can lint a parameterised profile in CI, or just before committing it and know it holds together before you ever try to bring it up.

This literally broke all my current profiles.

And I regret nothing. The flat-namespace migration touched pretty much everything; sample profiles, the docs, a pile of tests and all the profiles I actually use day to day. Normally this is the part of a post where I'd sketch out a careful migration path and apologise profusely.

But, the entire userbase of this tool is almost, as far as I can tell, me. So the migration path is "I'll fix all my profiles tomorrow morning over coffee."

There is a real freedom in shipping a breaking change to an audience you can fit in a mirror.

— it me.

To migrate is easy enough, just define your variables and prefix all references with var.. This is still currently in beta after all.

In closing...

Under the hood this turned into a more interesting refactor than I expected. hcldec wants to decode a whole file body against one spec and it flatly refuses to tolerate a variable block sitting next to the session it doesn't know about. The trick was to stop handing it the whole file, pull the session block out myself and decode just its body, which leaves the variable blocks to be gathered and resolved in their own quiet little pass beforehand. There's a tidy PartialContent implementation in there that was heaps of fun to figure out.

None of which a tmux wrapper strictly needed, of course. But "strictly needed" stopped being the bar around the time I added a fuzzer. The point was to feel out how Terraform turns a typo into a friendly, located error and now Glazier does a respectable impression of it for variables too.

I'm still ironing out all the kinks and ensuring I still have an 80% baseline in testing and code coverage, but I'm planning to release this and a few bug fixes and dependency bumps this weekend. Tomorrow-me gets to read this back with fresh eyes and decide how much of it past-me oversold. Very nice.

Until I merge it in, you can play with the latest release here.

And now I'm thinking about adding *.tfvars-like functionality. Surely, I won't fall for this again?

Why I Built Glazier

Wilhelm Murdoch — Sat, 20 Jun 2026 00:00:00 +0000

I live in tmux. I typically have an editor here, a dev server there, logs tailing in the corner or a spare pane for poking at things. The trouble is that this little world is frustratingly ephemeral. Rebooting my machine ( thank you, compuslory MacOS updates ), kill the wrong session or just close the laptop lid for too long and it can all evaporate. Then, I'm back to rebuilding the same layout by hand, one split-window at a time, like some kind of animal.

So I built Glazier; a small command-line tool that lets me describe a tmux workspace once and recreate it on demand. Type glaze up and the sessions, windows and panes I described spring back into existence exactly how I left them.

This has been a slow-burning labour of love for the better part of two years and it's finally in a state where I feel comfortable letting other people look at it. So let's talk about why it exists, what else is out there and how this one is different.

It's just a config file, right?

That was the idea, at least. I just wanted to stop rebuilding the same layouts over and over. But, as is tradition, I didn't want to make it too easy for myself.

There was a second, more selfish motivation. As a platform engineer, there isn't a day that goes by where I don't work with Terraform. I've always been quietly fascinated by how it parses and validates its configuration. That whole experience of getting a precise, friendly error pointing at the exact line you fat-fingered, rather than a stack trace and a 🖕. I wanted to understand how that machinery actually worked.

So, I'm a heavy tmux user and I wanted to learn HCL parsing from the inside. These two things lined up a little too perfectly. So Glazier's profiles aren't YAML; they're HCL. The same configuration language Terraform uses and parsed with the same underlying library.

Here's a basic profile:

session {
  name = "daemon-run"

  window {
    name   = "ice-breaker"
    layout = "main-vertical"

    pane {
      commands = ["nvim ./payloads"]
    }

    pane {
      commands = ["watch -n1 netwatch --target arasaka-mainframe"]
    }
  }
}

Drop that in a file called .glaze, run glaze up next to it and you're jacked in.

I'm not the first to do this; not even the 3rd... or the 4th.

This is a thoroughly-solved problem and I'd be doing you a disservice if I pretended otherwise. There's a whole shelf of mature, battle-tested tools that do effectively the same thing:

tmuxinator is the one most are familiar with. Written in Ruby with YAML profiles. Probably what most people reach for.
teamocil is also written Ruby; also uses YAML.
smug is written in Go and uses YAML and is the closest in spirit to Glazier if we're being honest.
tmuxp is written in good'ole reliable Python and it'll happily eat YAML or JSON.

If you already use and trust one of these, I'll be straight with you: there isn't a compelling reason to switch. Keep using what works. I'm not here to convince anyone to rip out a tool they're happy with.

But if you're still reading, here's what I like about mine.

So what's actually different?

The profile validates itself!

This is the part I set out to build, so it's the part I'm fondest of. Because Glazier is built on HCL, it inherits Terraform-style diagnostics for free. Mistype a layout, point a starting directory at somewhere that doesn't exist or forget a required block and you don't get a vague "something went wrong fuck you". You get told exactly what and where you messed up:

Error: Invalid layout specified

  on .glaze line 4, in session.window:
   4:     layout = "main-plumbus"

The layout value of "main-plumbus" is not a supported preset
(even-horizontal, even-vertical, main-horizontal, main-vertical,
tiled) nor a valid tmux layout string.

There's a glaze format command that rewrites your profile into a canonical style and, with --validate, reports any of these diagnostics without touching tmux at all. Both of these scratch exactly the itch that started the whole project.

Variables, templates and string functions! Oh, my!

A static layout is useful. A templated one is better. Profiles can reference variables and you can feed those in from --var flags or GLAZE_ENV_* environment variables:

session {
  name               = "ops-${region}"
  starting_directory = path.pwd

  window {
    name = upper(region)

    pane {
      commands = ["k9s --context ${region}"]
    }
  }
}

$ glaze up --var region=ap-southeast-2

Look familiar? If you work with Terraform it does!

There's a handful of built-in string functions too. upper, lower, replace, trimspace, join and friends which act as thin wrappers over the same go-cty standard library Terraform uses. Plus, a couple of freebies like path.pwd and path.base so a profile can adapt to wherever it's run from.

It doesn't lie to you about timing.

This is the bit of engineering I'm quietly proudest of, even though nobody will ever see it. When you fire a sequence of commands into a tmux pane, the naive approach is to blast them in with a sleep between each one and hope the previous command finished. That's flaky and it's how a few other tools handle it.

Glazier instead serialises commands through tmux's own wait-for signalling, so each command genuinely waits for the previous one to finish before the next is sent. There are no fixed sleeps and no races. The one exception is the final command in a list, which is sent fire-and-forget. If your last command is a long-running dev server or tail -f, waiting on it would hang up forever.

I learned that last part the hard way.

It can mostly save a session!

Run glaze save inside a live session and it'll capture the structure back out into a profile: windows, panes, names, layouts, focus and starting directories. The "mostly" is doing some load-bearing work in that sentence and it's a deliberate choice, not a missing feature.

save will not export your pane commands, environment variables, hooks or tmux options. Why? Because each of those is a footgun:

Commands would re-execute on the next up. A forgotten rm -rf captured from some pane could ruin your whole day on replay.
Environment variables can only be read as the entire session environment. This means inherited secrets, tokens and keys getting written into a file you might commit. That's a big fat no from me, dawg.
Options read back as effective state, hopelessly tangling up with your tmux.conf and manual tweaks.

So, a saved profile is a scaffold. It gets the geometry right and you add back the commands and config you actually want by hand.

A real profile.

Enough talk. Here's the profile I actually use when working this website:

session {
  name = path.base

  envs = {
    HUGO_GITHUB_TOKEN        = "${github}"
    HUGO_ACTIVITY_GRAPH_DEMO = "${demo}"
  }

  window {
    name  = "editor"

    pane {
      commands = ["nvim"]
    }
  }

  window {
    name  = "terminal"
    focus = true

    pane {}
  }

  window {
    name = "server"

    pane {
      commands = ["hugo server --disableFastRender"]
    }
  }

  window {
    name = "git"

    pane {
      commands = ["lazygit"]
    }
  }
}

Running glaze up --var github=*** --var demo=true gives me the following windows:

My editor of choice; NeoVim.
A dedicated terminal session.
The Hugo server along with some HUGO_ specific environment variables; values sourced from the CLI.
Finally, lazygit to manage and commit my changes.

Further, the --var arguments aren't really necessary as you could just export GLAZE_var_name as well and Glazier will pick it up automatically.

Anyways, because the session is just a named thing, the rest of the lifecycle is tidy too. List what's running with glaze ls:

$ glaze ls
NAME      WINDOWS  PATH
glazier*  2        /home/wilhelm/Development/wilhelm.codes
scratch   1        /tmp

The asterisk marks the session I'm currently attached to. When I'm done, I tear it down by profile:

$ glaze down

down is idempotent and that's on purpose. Bringing down a session that isn't running is a no-op, not an error, so it's safe to drop in scripts without defensive checks.

Some over-engineered bits ...

To be frank a tool that shells out to tmux did not strictly need a fuzzed HCL parser, build provenance attestations on its release binaries or a CI pipeline that runs the test suite against multiple Go versions and operating systems.

But, that was never really the point. The point was learning how Terraform's parser ticks, working out how to drive tmux reliably without sleeps and over-engineering the ever-loving-shit out of an already-solved problem because it was fun. Every constraint I imposed upon myself taught me something new. This is ultimately the only metric I actually care about for a hobby project like this.

Where to get it?

It's up on GitHub with a shiny MIT license. If you've got Go installed:

$ go install github.com/wilhelm-murdoch/glazier/cmd/glaze@latest

Or, grab a prebuilt binary from the releases page. I currently build for Linux and macOS on both amd64 and arm64. Each one ships with a checksum and a signed provenance attestation, because of course it does.

In closing ...

I would confidently say Glazier has moved on from "experimental" to "stable". It works and I use it every single day. But, there are rough edges and there may be any number of unencountered failure modes. The down and ls commands only landed recently and I'm not sure if the latter should remain. I've also got a running list of ideas I haven't talked myself out of yet. Like, something similar to Terraform's *.tfvars files or defining typed variables.

If you're already happy with Tmuxinator or Smug, then stick with them. But if the idea of a declarative, self-validating, slightly-too-clever tmux profile appeals to you, or you just want to read some Go that wraps tmux in ways it was probably never meant to be wrapped, I'd love for you to take it for a spin.

I sincerely hope you find Glazier as useful as I had fun building it.

Let Me Show You My Bits

Wilhelm Murdoch — Thu, 18 Jun 2026 00:00:00 +0000

A while back, in Reading Between the Posts, I wired up the home page so the quiet gaps between articles would narrate themselves - "1 bit and 41 changelog events in between". There was just one tiny problem with that sentence. At the time I had written exactly zero bits.

So let me finally show you my bits.

What even is a bit?

A bit is the smallest unit of "I made a thing" I'm willing to commit to. It could be a quote that stuck with me, a link worth keeping, the odd YouTube video, or a one-line thought too small to earn its own long-form entry. Each one is a little markdown file in /bits and the only thing it really has to declare is what kind of bit it is:

---
type: quote
date: 2026-06-17
source: "Edsger Dijkstra"
---
"Simplicity is a great virtue but it requires hard work to achieve it."

type is the whole trick that everything else hangs off.

One shape per thought.

The thing I didn't want was for a pithy quote to render like a bare link or to render like a video. They're different shapes of thought, so they ought to look different.

I'd already learned this lesson building the changelog, which leans on one tiny partial per event type. So I stole from myself. There's a single lookup table mapping each type to an icon, an accent colour and a label:

{{ $meta := dict
  "quote" (dict "icon" "quote-right"    "colour" "rose"    "label" "quote")
  "link"  (dict "icon" "arrow-up-right" "colour" "blue"    "label" "link")
  "video" (dict "icon" "youtube"        "colour" "red"     "label" "video")
  "blurb" (dict "icon" "pen-nib"        "colour" "emerald" "label" "blurb")
}}

It then matches a micro-partial per type that decides how the content actually renders. Adding a brand new kind of bit is now "add one row, add one tiny template", which is about as many steps as I'm willing to tolerate.

Hugo, why are you like this?

My bits started life with two perfectly reasonable front-matter fields: type and url. Hugo took one look and quietly robbed me of both.

It turns out url is a reserved key which Hugo uses to treat as the page's permalink. So, the moment I put a https://... in there, the build fell over with a stern little message about unsupported protocols. type doesn't even have the decency to error. It silently moves out of .Params.type and into .Type, which also hijacks the layout lookup. So my .Params.type was resolving to nothing and every single bit was quietly rendering as the fallback.

Turns out hte fix for this was simply to rename url to link and read .Type instead of .Params.type. Half an hour of my life dedicated to two words I didn't know were already spoken for.

Coding is my passion.

Bits flapping in the wind.

Rather than dumping bits into the same fold-out list as the GitHub noise, I pulled them out as their own first-class timeline rows. The lower-signal changelog chatter stays tucked behind the "N changelog events in between" disclosure. So, the home page now reads in three tiers:

the loud headline articles
the medium-volume bits
the quiet changelog hum

The same interstitial machinery I built last time, but bits just get to stand a little taller than a commit.

The tag that went nowhere.

Bits are deliberately render: never in Hugo. They live inline on the bits page and never get their own URL. Except "no page" also quietly means "no place in the taxonomy", which means a tag only ever used by a bit has no /tags/... page to point at. If I link it anyway I've shipped a 404.

So, the tags only become links if there's actually somewhere to go:

{{ with site.GetPage (printf "/tags/%s" (urlize .)) }}
  <a href="https://wilhelm.codes/blog/let-me-show-you-my-bits/{{ .RelPermalink }}">#{{ .Data.Term }}</a>
{{ else }}
  <span>#{{ . }}</span>
{{ end }}

A tag with a real page becomes a link and a bit-only tag stays as plain text. No broken links and the nice part is it heals itself the moment a proper article picks up the same tag.

In closing ...

The front page has quietly turned into a proper little stream. Long-form when I've actually got something to say, bits when I don't and a year of squircles up top keeping a tally of it all.

Which is the entire point. The less effort it takes to post a half-formed thought, the more likely I am to actually post it. And the more I post, the more those gaps fill in.

And, as always, you can check everything out for yourself in the repo.

DEV Community: Wilhelm Murdoch

I Didn't Need a DAG. I Needed Cron.

Let's go shopping!

Big brain time!

One key to rule them all... with great care.

Finding the guests.

The nr helper.

It's also just a nice way to poke at the lab.

Jobs are code. Obviously.

Ansible does the boring part.

Cron, but with a seatbelt.

There actually are some ugly bits to this.

In closing ...

The Safest Login Page is the One I Never Published

The answer everyone gives you.

Tunnels match on path.

Why I think this is the better trade.

Does it work though?

Something worth pointing out.

Hark! A plot twist!

The one thing path scoping does not fix.

... so, naturally I put Nginx in front of it.

The origin is blind.

Umami logs nothing at all. Zilch.

In which I am humbled by a robot.

The small detail I liked most.

In closing ...

Would you like to know more?

What Good is a Number You Can't Call?

Some background.

Every single country had a speed bump.

The boring technical stuff.

Another free gift: the hotlines API.

Every Record Now Has a Source

The database lost some weight.

How I source vetted data.

What I removed, specifically.

The plant index is now a "Field Guide".

The front page got some filter updates!

Safe plants get a facelift!

It now has a blog... sort of.

Finally, some changes to the API.

What's next?

Why I Rebuilt Plant Smart

The toolchain aged like fine milk.

First things first, absolute parity.

I made the site cute on purpose.

The data enrichments will continue until "Morella" improves.

There was also quite a bit of fat to trim.

We ship from the homelab now.

Was the juice worth the squeeze?

My Blog Now Ships From My Homelab!

How complex can this possibly be?

The new shape of things.

A small intermission.

The part Cloudflare doesn't clearly advertise.

Finally, our favourite! YAML.

Only build off main.

We want a full clone, not a shallow one.

Diagrams render before anything else.

The build step is a stock Hugo image.

The deploy step is a stock Node image.

I did run into some speed bumps along the way.

I'm not deleting the old repository... completely.

In closing ...

Glazier Release: v0.1.5

Let's get v0.1.5 out of the way first.

v0.1.4 is where the features live.

Support for locals.

lol... lmfao.

Our first contributor has entered the chat!

In closing ...

Some Long Overdue Demolition

The demolition ...

The fonts had to go too.

Hugo, finally home alone.

Numbers, or it didn't happen.

An ambitious first pass.

Series

Tired LEDs

The `nr` helper.

Only build off `main`.

Let's get `v0.1.5` out of the way first.

`v0.1.4` is where the features live.