Posts

Supply chain security in modern container ecosystems is often treated as a post-build afterthought: a secondary scanner runs against a finished image and tries to infer what packages are inside. When building native FreeBSD OCI images at Daemonless, we decided to make supply chain transparency a first-class citizen from day one. With recent updates to our custom build system (dbuild), every container image generated across our entire fleet now produces multi-format Software Bill of Materials (SBOM) artifacts directly at build time. ...

When you run FreeBSD in a homelab across multiple servers, VNET jails, or VMs, routine maintenance quickly reveals a hidden inefficiency. Every time you provision a new jail or update your fleet, each instance independently connects to public pkg.FreeBSD.org mirrors to download identical packages. If you have a dozen jails running services that need Python, SQLite, or FFmpeg, your WAN connection downloads the exact same binary archives a dozen times. ...

When the mission is to build native FreeBSD OCI images that run in Jails without a heavy background daemon on the host, the project name basically writes itself: daemonless.io. The goal is simplicity, transparency, and architectural purity. So, it is only natural that the very first thing we did was install a suite of tools designed specifically to manage, supervise, and run… daemons. It is a bit like starting a “Car-Free” lifestyle and then immediately buying a fleet of high-end electric scooters. Technically, the name still holds up, but you’re still getting around on wheels. We might be “daemonless” on the host, but inside the container, we’ve hired the most efficient, C-based babysitter in the business. ...

There is a distinct, visceral satisfaction in typing make config && make install clean. If you’ve spent any meaningful amount of time in the Unix world, you know exactly what I mean. The FreeBSD Ports tree is an ethos—a commitment to understanding exactly what is running on your metal. But let’s be honest: while Ports are a masterpiece for traditional software, they hit a brick wall with modern, cloud-native applications. I’ve been running into this wall a lot lately while building daemonless.io—a project dedicated to bringing first-class, native OCI images to FreeBSD. ...

I’ve been running containers on FreeBSD for a while now, and I’ve settled into a workflow that just works. Here’s how I manage everything. The Stack Component Choice Host OS FreeBSD 15 Runtime Podman + ocijail Orchestration Ansible Images Daemonless (FreeBSD-native) Storage ZFS (lz4 compression) Networking VNET jails + bridge No Docker daemon. No Linux VMs. Podman talks to ocijail, which runs containers as native FreeBSD jails. Directory Structure Every service gets its config stored in /containers/<service>/. Simple and predictable: ...

I’ve been a FreeBSD user since the late 90s. From 2002 to 2010, I was a ports committer working on the GNOME and Multimedia teams. I have always felt more “at home” with FreeBSD. There is a logic and cohesiveness to the Base System + Ports approach that just clicks for me in a way Linux distros often don’t. But the world changed. The OCI (Docker) container workflow took over, and for good reason: immutable infrastructure and easy updates are incredible for sanity. ...

I have owned ahze.net for a very long time. For most of that time, this domain has been a quiet corner of the internet—mostly used for internal lab services, mail, or just sitting idle. I’ve rarely had anything public-facing or inviting for the outside world to see. I’m changing that today. I’ve decided to start documenting my projects, my experiments with FreeBSD, and the growth of the Daemonless ecosystem here. This site is currently running inside a Daemonless Hugo container on my own infrastructure, which feels like the right way to kick things off. ...

My homelab has evolved significantly over the years. Currently, it’s a mix of heavy iron and efficient ARM devices, all orchestrated with Ansible. The Fleet Mars (TrueNAS): The primary storage engine. Bulk ZFS datasets, backups, and media library. Saturn (FreeBSD 15): The CI/CD Core. Runs Gitea, Woodpecker, and DNS. Jupiter (FreeBSD 15): The heavy lifter. Runs local storage and media services. OPNsense: The perimeter. Handling the network, firewall rules, and VLANs. Pluto (FreeBSD 14): My dedicated test box. Sunshine (Synology DS418): Secondary backup server to Mars. Venus (Linux/Fedora): For the few things that absolutely refuse to run on FreeBSD (yet). PiAware: ADS-B flight tracker (built following this guide). Pibox (Linux/ARM64): My low-power, always-on utility box. Everything is managed via Ansible stored in a private Gitea repo. Secrets are vaulted. Deployment is a single playbook run.

I use both. I like both. But they feel very different. Linux feels like a bazaar. You grab a kernel here, a package manager there, a init system from over there (usually systemd these days), and stitch it together. It’s powerful, chaotic, and moves fast. FreeBSD feels like a cathedral (to borrow the classic metaphor). The OS is a complete, cohesive unit. The kernel and userland are developed together. ifconfig works the same way it did 20 years ago. ZFS is a first-class citizen, not an external module. ...