Automation on Tom Meurs

Infrastructure as Code for People Who Need to Understand

Sat, 30 May 2026 19:45:00 +0100

Someone opens a cloud console, clicks through a wizard, accepts a few defaults, and a resource appears. The dashboard goes green and everyone moves on. That’s still how a lot of infrastructure gets built in 2026, and I’ve built some of it that way myself.

I can’t work like that for long. When I click a button and infrastructure appears, it feels borrowed. I want the configuration written down somewhere I can read it back, and I want to know why something exists, not only that it exists. The console gives me a green tick. It doesn’t give me any of that.

cert-manager: Automatic TLS Certificates in Kubernetes

Sun, 12 Apr 2026 21:38:00 +0100

TL;DR cert-manager watches Certificate resources, fetches the certificate from Let’s Encrypt, your own CA or Vault, stores it in a Secret and renews it 30 days before it expires. I run one DNS-01 ClusterIssuer through Cloudflare and one wildcard certificate, copy that Secret into the namespaces that need it, and let two Prometheus alerts tell me when a renewal is stuck. Nothing left to remember.

For years my certificates renewed the way most people’s do. A calendar reminder, a manual certbot run, and the hope that I’d get to it before the thing expired. It worked, right up to the morning a service started throwing cert errors at me and I had no idea why. The renewal cron had been failing for weeks. Quietly.

Working with an AuDHD brain: why I automate everything

Sat, 27 Dec 2025 14:00:00 +0100

For a long time I thought the problem was me.

I have AuDHD , autism and ADHD together. The ADHD is ADHD-PI, the inattentive kind, without the hyperactivity most people picture when they hear the word. For years I treated the whole thing as a defect I’d train away. I bought the planners. I read the productivity books. Every week I told myself that Monday I’d finally be disciplined.

Kyverno Policies: Governance as Code for Kubernetes

Mon, 14 Jul 2025 10:00:00 +0200

I used to keep a wiki page titled “Cluster conventions”. Resource limits on everything. No :latest tags. No deploys in the default namespace. It was a good page. Nobody read it. Six months in, half the cluster broke those rules and I only found out when something fell over.

A rule that lives in a doc is a suggestion. A rule the API server refuses to accept is governance. That gap is the whole reason this post exists.

Automating Semantic Versioning with GitLab CI

Tue, 27 May 2025 19:44:00 +0200

Picture the end state first. You merge a branch to main, walk away to get coffee, and by the time you’re back the project has a new version tag, a fresh changelog entry, and a GitLab release with notes written from your commits. Nobody decided “is this 1.4.0 or 1.3.5?” because nobody had to. The version fell out of the work itself.

That’s where I want to get to in this post. I run a self-hosted GitLab and I do not want versioning to be a thing I think about. A version number that someone picks by hand is a tiny black box: it depends on whether that person remembered the rules, was paying attention, and agreed with everyone else about what counts as a breaking change. I would rather the number be a consequence of the commits, something I can inspect and reproduce.