Cells for NetBSD ALPHA6 available!
Getting started is now even easier:
Prebuilt amd64 images available as DVD and USB images.
Cells for NetBSD ALPHA6 available!
Getting started is now even easier:
Prebuilt amd64 images available as DVD and USB images.
Three ways to look at the same machine - at the same time: a BIOS VGA console, a 256-color xterm, and a responsive web UI - all connected to the same cell and backup management backend.Which one would you pick?
Cells for NetBSD is a maturing NetBSD-native isolation stack with kernel-enforced boundaries, supervised service execution, and snapshot telemetry for practical host-side operations.
Cells for NetBSD - Kernel-enforced, jail-like Isolation with User-friendly Operations (netbsd-cells.petermann-digital.de)
#netbsd #modernretrocomputing #freebsd #openbsd #dragonflybsd




It’s becoming real... When you build clean interfaces from the ground up, the next GUI is not magic. It is a concrete architectural vision, solid technical design, and a few prompts away...
Cells for NetBSD is a maturing NetBSD-native isolation stack with kernel-enforced boundaries, supervised service execution, and snapshot telemetry for practical host-side operations.
Cells for NetBSD - Kernel-enforced, jail-like Isolation with User-friendly Operations (netbsd-cells.petermann-digital.de)
A small update on NetBSD Cells 
I’ve spent some time recently polishing things up and have updated the project page. I also built a new evaluation DVD image so it’s easier to try the current state of the project.
It now includes a few of the things I’ve been working on lately, like the reconcile engine in cellmgr, some early volume and backup management, and cellui for interactive administration.
If you’re curious about where the project currently stands, I wrote a short status report here:
https://www.petermann-digital.de/en/blog/netbsd-cells-status-report-2026q1/
Project page and download:
https://netbsd-cells.petermann-digital.de/
Feedback, thoughts, and questions are always very welcome.
"Can you show what Cells for NetBSD actually does?"
Sure.
Fresh NetBSD install, deploy a Luanti server from a manifest, backup, restore, inspect processes inside the cell, then nuke everything again.
My personal record is <4 minutes.
The video is slower because OBS + VM + music nearly killed my laptop.
Cells for NetBSD... Lightning Talk without the Talk
Pushing Cells for NetBSD even further... cellmgr becoming a scriptable reconcilation engine with full lifecycle management including backup/restore, with cellui as the go-to TUI for midnight commander enthusiasts. And why stop there, when you could have a PAM authenticated web UI with feature-parity as well?
@zolaris I used to prototype this in Go (using the great bubbletea library) but later decided for a rewrite in pure C and NetBSDs native curese library. I try to keep dependencies as low as possible for seamless integration with the build.sh system. Actually the "cellui" curses interface shown in this screenshot uses "cellmgr" as it backend. cellmgr is a hybrid of a end user cli with a stable machine runtime interface, completely written in sh. So we have a scriptable middleware layer. Took some iterations to get this right, and still some rough edges I will address.
Running a massive fleet of 26 API-Servers, served by a Nginx gateway as ingress. This time with midnight commander theme 
For example....
What about a nice Midnight Commander-style TUI to manage cells interactively?
Cells for NetBSD is a maturing NetBSD-native isolation stack with kernel-enforced boundaries, supervised service execution, and snapshot telemetry for practical host-side operations.
Cells for NetBSD - Kernel-enforced, jail-like Isolation with User-friendly Operations (netbsd-cells.petermann-digital.de)
RE: https://mastodon.bsd.cafe/@mpeterma/116180607527845598
Quick follow-up on the naming discussion around my NetBSD project (currently “Jails for NetBSD”):
I’m planning to close the poll tonight at midnight (2026-03-07 EST). That should give me the rest of the weekend to refactor the codebase for the new name and then continue with stabilization, review and new features.
If you haven’t voted yet, please do
Your input is very helpful.
A funny thing happened today: after a meeting I ended up on the phone with a former colleague and we drifted into the ongoing “is it really jails?” naming discussion around my NetBSD experiment.
He pointed me to the FreeBSD Handbook and suggested I look again at how jails are actually described there. That sent me down a small rabbit hole. The more I read, the less clear-cut the distinction felt.
At the lowest level, FreeBSD jails are essentially a kernel mechanism that attaches an identity to processes and restricts visibility and interaction. Many things people associate with “modern jails” today - VNET networking, ZFS-based setups, orchestration frameworks - often live a layer above that core mechanism in tools like BastilleBSD and similar projects.
Interestingly, FreeBSD’s own docs sometimes describe jails as the subsystem that enables containers, and the industry term “container” shows up quite regularly there as well. FreeBSD can even run OCI containers via the Linux compatibility layer. Which made me wonder: have “jails” gradually become something like a brand name for the FreeBSD flavor of containers in people’s minds?
I’m honestly still undecided. The more I read, the more it feels like the answer depends a lot on the perspective and background one brings to these terms.
Curious what the poll will say — please vote if you haven’t yet. And if the right name isn’t listed, feel free to drop suggestions in the comments 
I’ve been following the discussions about the name of my NetBSD project ("Jails for NetBSD") across a few platforms over the past days and really appreciate the thoughtful feedback.
The short version: the current prototype is probably closer to a cell or a cage than a strict jail, so the name might indeed not be perfect. The project originally started as an experiment inspired by FreeBSD jails, but while exploring NetBSD internals it evolved into something slightly different: controlled process isolation built around the secmodel framework, a different approach for the tool chain and configuration, and without resource limits and network virtualization.
Because of that, I’m open to renaming the project at this stage.
I’ve attached a small poll with a few candidate names — please vote if you like.
And if the right name isn’t listed yet, feel free to drop suggestions in the comments 
Project site: https://netbsd-jails.petermann-digital.de/
New checkpoint of the NetBSD jails prototype. Clean rebase on NetBSD 11 with no changes to existing upstream code except a bugfix. Also a new evaluation ISO based on NetBSD 11 RC1 (2026-03-05). Next experiments will explore non-user rlimits in the jail context and additional kauth gates (e.g. maxproc at fork).
Small follow-up on Jails for NetBSD.
While experimenting with resource budgeting via the secmodel evaluation interface, it became clear that pushing resource limits into the jail mechanism introduces complexity in sensitive kernel paths and risks undermining system stability. That runs counter to one of the core guardrails of the project: keep the mechanism simple, explicit, and low-risk.
As a result, resource control is now considered out of scope for Jails for NetBSD.
Jails remain focused on lightweight service isolation and operational structure inside the host. Systems that require hard resource guarantees should use virtualization boundaries such as Xen.
This keeps the design aligned with its original goal: pragmatic, minimally invasive process isolation on NetBSD.
A short write-up explaining this scope refinement will be published on the project website later this week.
Since the last article, the secmodel_jail / jailctl / jailmgr stack has moved closer to a coherent whole. The original guardrails remain unchanged: no modifications to existing kernel paths, no UVM hooks, no NPF integration, no hidden coupling. The scope stays explicit and the risk bounded.
Progress has focused on operations. Logging, lightweight supervision, and basic metrics are in place, shifting the question from "can this work?" to "can this be run?". Networking remains intentionally simple and host-based; for hard isolation, Xen is still the right boundary. Jails provide an operational frame inside the host, not a replacement for virtualization.
Resource budgeting is being prototyped again via the secmodel evaluation interface, touching allocation paths and scheduler run queues in a minimally invasive way, but it needs careful review.
There is now also a small landing page to make the ideas visible, including an experimental amd64 ISO based on NetBSD 10.1 for testing. If it sparks upstream interest or discussion around lightweight, explicit isolation on NetBSD, that is already a win.