Cells for NetBSD

Kernel-enforced, jail-like isolation with user-friendly operations.

Quick Navigation | Foreword | History | Unix/NetBSD Basics | End-to-End Recipes | Architecture | Developer Guide | Get Started | FAQ

Foreword

NetBSD Cells is built from an operator-first perspective: strong boundaries, predictable workflows, and less runtime complexity than VM-heavy service splits.

It follows a “why NetBSD” stance: cohesive system design, explicit kernel security hooks, and tooling that stays close to how Unix systems are actually run and debugged.

Start with Foreword, History and Evolution, and Unix and NetBSD Basics for Admins before diving into command-heavy sections.

Overview

NetBSD Cells v2 provides lightweight OS-level isolation on a shared NetBSD kernel, plus a unified control plane for declarative state and operational automation.

Conceptually, Cells are closest to FreeBSD jails: kernel-native compartments with strong isolation boundaries and host-level administration. For Linux users, the day-to-day model is similar to containers (per-workload runtime roots, isolated processes, explicit lifecycle), but implemented with NetBSD kernel security primitives rather than Linux namespaces/cgroups.

Isolation is enforced by secmodel_cell, integrated with NetBSD kauth authorization hooks. Cell identity is carried in credentials and checked in kernel authorization paths, including process visibility/signal boundaries, privileged operation checks, reserved port ownership, and controlled sysctl behavior.

The platform is designed for operators who want deterministic workflows, clear guardrails, and production-grade day-2 ergonomics.

Project history

Cells evolved in public from early secmodel_jail experiments to the current secmodel_cell direction, including architecture revisions driven by real load testing and community feedback.

Read History and Evolution for the timeline and source references.

Architecture

The system is built as a layered stack:

  • secmodel_cell in kernel space for isolation and policy enforcement
  • cellctl for low-level runtime commands and metrics snapshots
  • cellmgr for desired/runtime state, reconciliation, and backup flows
  • cellui for interactive terminal operations over cellmgr IPC

Read the full Architecture chapter for deeper design details, contracts, and deployment patterns.

Developer Guide

The project also includes an implementation-focused Developer Guide with source tree maps, dispatch and schema internals, reconcile/apply behavior, and UI adapter contracts.

Features

  • explicit desired/runtime/both scope model for mutations
  • strict machine-readable contracts with -T -H --view -o
  • dependency-aware reconcile pipeline via cellmgr apply
  • declarative per-cell provisioning with *.apply plans
  • volume and overlay backup/restore with safety checks

Get Started

Use the 5-Minute Admin Onboarding to bootstrap your first host and converge your first cell.

For full operations coverage, continue with the User Manual.

FAQ

For incident triage, recovery workflows, and common error patterns, see Troubleshooting.