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.
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.
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.
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.
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.
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.
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.
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.
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.
I ran curl ifconfig.me on four different servers and got the same address back four times. That single result invalidated the entire approach I had spent three days validating on EC2. This is the full path from that discovery to three services running on my own subdomains with valid certificates and zero inbound ports.