#Containerization — Seconds to Midnight

Post: Deployed I2P Reseed server on Kiota

damian.buho@proton.me (Damián Búho) — Wed, 02 Sep 2026 02:59:00 GMT

I2P is a peer-to-peer network which uses “Garlic Routing” to maintain privacy. Reseed nodes help you get connected to I2P for the first time, and even though you should only have to use them once in a great while, they are very important services.

I have my own distribution/image that automates some fuss with installation.

Feeling like a very niche Atlas.

Post: What is image distillation?

damian.buho@proton.me (Damián Búho) — Tue, 16 Jun 2026 02:59:00 GMT

There are at least four ways to go about building container images:

Small distributions, like Alpine
Cut-down server versions (e.g., debian-slim)
Whatever tf Ubuntu Chiseled is
Distroless

I use a fifth one.

Pain

In my experience, no one really likes building Alpine images, but because they're so lean, people feel forced to. MUSL, busybox, ash, python issues, package names often differ, command flags vary slightly, and so on.

I've used Ubuntu/Debian as an image base since 2018 because my developers were Debian-oriented and felt much more confident whenever they had to operate inside containers to debug.

In production, though, Debian-based images are far from perfect. Debian has long confused 'paleolithic' with 'stability.' Meanwhile, Canonical adds useless thingamajigs like Pebble—complete with a bunch of Go stdlib vulnerabilities—or ruins RISC-V compatibility with an unnecessary move to vector extensions.

Distroless images are pure and perfect — and also feel like a war crime when you're actually building them. Every single dependency has to be hand-crafted, and you constantly feel phantom pain from missing basic shell tools.

Don't get me wrong: I love it, but it's a kink.

Distillation

To keep a cozy environment while working on a project, while simultaneously stripping down the attack surface of the production image, I use a technique I call image distillation.

It's fairly obvious (I'm pretty sure many people do this, I didn't invent anything), but I haven't found an established term for it yet (I'd be glad to be proven wrong if you know one).

Build in whatever base image you like: Alpine, Ubuntu, or whatever Red Hat is calling their server distro this week.
At the end of that build stage, COPY everything you actually need (binary + libraries + runtime data) into a single folder (mine is usually called /export).
Add a final stage with FROM scratch or FROM distroless, with a single COPY --from=builder /export /.

You get the fat-free security of distroless in production with the developer pleasantries of a full OS during build time.

You won't get any progress in understanding the meaning of life or finding true love, though.

It's just a slim container image, what did you expect?

Post: What is B19 images and how I wrap things in containers

damian.buho@proton.me (Damián Búho) — Tue, 09 Jun 2026 02:59:00 GMT

A big part of my portfolio consists of so-called b19-style images.
(b19 means nothing—you just can't get a proper namespace these days.)

It started as an internal effort for my personal and commercial projects, but ended up as a set of conventions unified across 100+ various images (both wrappers and originals). I wanted every container to behave in a predictable way, agnostic of the tech stack, whether it's a source-based or upstream-based project.

I'm not urging anyone to adopt this directly yet—I need some time in public to polish everything—but if you're tasked with a similar unification job or manage a fleet, feel free to steal the conventions.

The conventions are anchored in B19/Ubuntu and flow organically into all downstream projects.
The conventions are unopinionated (though the defaults can be).

What's inside?

Basic container decency

Follows 12-factor app guidelines
Reasonable, secure, and safe defaults with minimal user input required
Images should be immutable; all state lives in volumes
Support for XDG and other industry standards
Proper telemetry everywhere
File operations use locks, always keeping concurrency in mind

The Dockerfile orchestrates

No shell sagas
No mile-long RUN commands—one RUN per stage
Minimal layers

Switches, toggles, handles

B19-style images expose switches for all kinds of behavior: there's no such thing as "too many switches." Where possible, switches are set via environment variables (relying on various mounts and binds is messy).
Configuration files are generated via Jinja2 templates driven by environment variables.

Everything is `.d`

Numbered hooks everywhere. Everything can be extended or overridden via simple drop-in shell scripts in downstream projects. Hooks can be inherited:

Build is build.d
Healthcheck is healthcheck.d
Entrypoint is entrypoint.d

Designed with off-grid in mind

Do not assume connectivity is guaranteed
Do not assume fast or stable connectivity
Timeouts, backoffs, and retries everywhere

In other words, a b19 distribution comes with all the things you would end up adding to an official image anyway—right out of the box.