Foreword

Why this exists

NetBSD Cells starts from a practical operator question:

How do you isolate services on one host with stronger boundaries than plain chroot, but without paying the full complexity and footprint of running many virtual machines?

That question came from real system work, not from chasing trends. It came from small and medium hosts that still need clean boundaries, predictable operations, and fast incident handling.

This documentation is intentionally written so admins with limited Unix experience can still build a correct mental model and operate safely.

Why NetBSD

This project chooses NetBSD intentionally.

NetBSD favors coherence and explicit design:

kernel, base system, and toolchain are designed as one system
security decisions flow through kauth and secmodel hooks
operational behavior is inspectable with standard Unix tools
old and mixed hardware remains usable for serious workloads

That combination makes it possible to build an isolation model that feels native to NetBSD instead of copying Linux container internals.

Engineering stance

The spirit behind this documentation is simple:

understand systems deeply, do not only consume platforms
prefer deterministic workflows over hidden automation
keep mechanisms small, observable, and reviewable
document not only the happy path, but also boundaries and trade-offs

This is not anti-cloud and not anti-container ideology. It is a deliberate choice for workloads where a NetBSD-native shared-kernel model is the right tool.

Personal note

The broader motivation is close to the NetBSD homeserver work:

less abstraction for its own sake
more direct ownership of build, runtime, and operations
systems you can explain end-to-end

If a platform is clear enough to reason about under pressure, it is usually also the platform that is easiest to keep reliable over years.

Read this docs set effectively

Recommended flow: