2026¶

Three Places to Put Provisioning: Init Tasks, Startup Files, or the Image

Getting a playground published is not the same as getting it usable. Between "the VM booted" and "a stranger can do the thing you built this for" sits a pile of work: packages, repositories, config files, seeded data, services that need to be running. The iximiuz Labs manifest gives you two places to put that work, and your Dockerfile is a third.

I picked the third for all six of my images. This is what the other two do, when each one is right, and the reasoning that made me choose the one I did.

The Vulnerability Gate That Blocked Every Build

I chose Alpine for the runtime image because it is smaller. That decision made my pipeline permanently unbuildable, and fixing it exposed two more failures hiding behind the first. This is the full chain, the redesign that resolved it, and the principle I now apply to every scanning gate I write.

The Version Override Maven Silently Ignored

I set <thymeleaf.version>3.1.4.RELEASE</thymeleaf.version>, rebuilt, and Trivy reported the same two critical CVEs in Thymeleaf 3.1.3. The property was not a typo and the build did not warn. Maven had read it, found nothing that consumed it, and moved on. This is what actually clears a transitive CVE in a Spring Boot project, and why the obvious mechanism works for some libraries and does nothing for others.

Six Errors from Building systemd Rootfs Images, and How I Fixed Each

None of these appeared in documentation. Each one cost me somewhere between twenty minutes and an afternoon, and every fix turned out to be a one-line change once I understood the cause. Here they are with the symptom, the root cause and the resolution, in the order I hit them.

Six Things That Break When You Actually Use a Debugging Container

Building the image is the easy part. What actually accumulates over months of running DebugBox against real clusters is a list of things that look like bugs the first time and turn out to be the correct behaviour of something underneath: musl, network namespaces, kube-proxy, ps column order. Six of them, with what actually caused each one.

The Machine I Actually Work From

Every other post in this series is about a machine that runs a service: Jenkins, SonarQube, Nexus, the jump host that only forwards SSH. This one is about the machine I actually sit at. dev-machine-rootfs is a full DevOps workstation, more than 40 tools installed at build time, that boots ready in a browser tab instead of accumulating over a year of apt install on whatever laptop I happen to be using.

Four Machines, One Playground: Composing a CI/CD Stack That Boots Ready

The first time I stood this up by hand it took a few hundred commands across four servers. It now takes one click and about ninety seconds, and anyone can launch the same thing in a browser. This is the composition: how four machines are wired, how a fixed resource budget was allocated, and the one step that stays manual on purpose.

Why I Built My Own CI/CD Stack (And What I Learned)

Most engineers use CI/CD tools. I wanted to understand them well enough to build the infrastructure underneath them: my own servers, my own domain, my own certificates, and eventually my own machine images. This is the reasoning, the honest cost, and an index to everything the project produced.

Publishing a Custom Playground on iximiuz Labs: Custom Rootfs, Manifest, and labctl

iximiuz Labs boots each playground machine as a Firecracker microVM, and it will boot your OCI image as the root filesystem rather than one of its own. That is the interesting capability, and going from a Dockerfile to a public URL a stranger can click takes three moving parts: an image that boots, a manifest that describes the machines, and two labctl commands.

This is that path end to end, using the five playgrounds I actually publish, plus the parts I got wrong on the way.

Building an OCI Image That Boots as a microVM, Not a Container

I write a Dockerfile and what comes out the other end is a bootable server. Not a container image that happens to run systemd, but a root filesystem that a hypervisor mounts as a block device and boots with its own kernel. Running any of these images with docker run fails immediately, and that is the correct behaviour.