Cells for NetBSD is a NetBSD-native isolation stack built around a clear operating model, currently in its 3rd generation:

  • declare what you want
  • apply changes in a controlled way
  • operate with confidence day to day

It is designed for applications where full virtualization such as Xen is too heavy, while classic chroot is not strong enough from an isolation perspective.

The operational focus is practical NetBSD integration: central syslog, lightweight metrics export, and workflows that fit existing host operations without unnecessary platform ballast.

This makes the stack especially suitable for compact infrastructure and edge systems that need strong boundaries with low overhead.

If you want the technical deep dive, see the Architecture and Get Started sections.

The current architecture is a layered system with a strict split between desired state and runtime state:

Layer Model

Core components:

  • cellman Declarative control plane: load Lua desired state, build typed snapshots, run apply, and manage backup/restore and system operations.

  • cellui Interactive curses frontend built on libcellman for the same backend/API contracts as cellman.

  • libcellman Shared library for core control-plane logic and typed API access used by both cellman and cellui.

  • cellctl Runtime primitive layer for create/destroy/exec/supervise plus runtime stats export.

  • secmodel_cell Kernel authority for cell-aware authorization, process isolation, and telemetry counters.

State domains are explicit:

  • Desired state: Lua documents in /etc/cellman/*.lua
  • Runtime state: materialized host data under /var/cellman/*
  • Read state: merged projections from cellman ... list/show

For automation, read commands share one stable contract:

  • --view to select projection (compact|desired|runtime|merged)
  • -o for explicit field selection
  • -T for TSV output
  • -H for header-less TSV

Cells for NetBSD focuses on operational capabilities with strong NetBSD base integration and low runtime overhead.


Isolation Controls

  • Kernel-enforced process boundaries isolate workloads on the same host
  • Security profiles (low|medium|high) and reserved ports are part of cell policy
  • Optional supervise limits (nofile, as, core) can be set per workload

Reconcile Workflow

  • Change flow is explicit: dry-run, apply, verify
  • Drift is detected before rollout and can be used for CI/pipeline gating
  • Apply decisions are deterministic and hash-based across manifest/service/policy/apply state
  • Exit codes are automation-friendly (0 success, 1 failure, 2 dry-run drift)

Runtime Operations and Visibility

  • Standard lifecycle actions are available for single cells and bulk operations
  • Supervised services support restart/backoff behavior for resilient runtime operation
  • Service logs are forwarded to host syslog for centralized visibility
  • Runtime state can be queried in human and script-friendly formats
  • Snapshot metrics include CPU, process count, references, memory, and age
  • Prometheus metrics are available via cellctl stats -P
  • cellctl stats -P -h can be exposed via inetd as a lightweight metrics endpoint

NetBSD-Native Integration

  • Uses existing base-system mechanisms (syslog, inetd, standard shell tooling)
  • No external control plane services are required for normal operation
  • Keeps deployment lean and predictable on smaller hosts

Storage and Recovery

  • Persistent volume data and runtime overlays are handled separately
  • Built-in backup/restore exists for both volume and overlay workflows
  • Restore and delete paths enforce explicit confirmation and safety guardrails

CellUI

  • Interactive TUI for quick operational overview
  • Efficient handling of routine lifecycle and backup tasks
  • Useful during incident triage when fast status navigation matters
cellui full-width screen

Overall, the feature set is built for predictable change management, reliable runtime behavior, and strong integration into NetBSD operational workflows, including edge-oriented deployments.

This section demonstrates the current v3 workflow:

  1. Bootstrap host runtime once.
  2. Declare desired state in /etc/cellman/*.lua.
  3. Preview drift with cellman apply --dry-run --all.
  4. Converge runtime with cellman apply --all.

1. Bootstrap Host Runtime

Prepare runtime directories, base sets, and baseline configuration:

doas cellman system bootstrap

Create one volume, one cell, and one apply document in /etc/cellman.

/etc/cellman/01-volume-demo-data.lua

volume("demo-data", {
  mode = "0755",
})

/etc/cellman/02-cell-demo-web.lua

cell("demo-web", {
  autostart = true,
  create = {
    profile = "medium",
    reserved_ports = "8080",
  },
  supervise = {
    cmd = "/usr/libexec/httpd -I 8080 -X -f -s /var/www/demo-web",
  },
  mounts = {
    volume("demo-data", { target = "/var/www/demo-web", mode = "rw" }),
  },
  healthcheck = "test -f /var/www/demo-web/index.html",
})

/etc/cellman/03-apply-demo-web.lua

apply("demo-web", {
  dir("/var/www/demo-web", { mode = "0755" }),
  file("/var/www/demo-web/index.html", "<html><body>Hello from Cells</body></html>\n", {
    mode = "0644",
  }),
})

3. Preview Convergence

Run a dry run first. Exit code 2 means drift was detected, which is expected after new or changed declarations.

cellman apply --dry-run --all

4. Apply Desired State

Converge volumes and cells, execute apply actions, and start the supervised service according to desired state.


5. Verify Read Views

Use compact/merged views to confirm intent and runtime alignment:

cellman cell list --view compact
cellman cell show demo-web --view merged
cellman volume list --view merged

For scripting, use explicit fields and TSV:

cellman cell list --view runtime -T -H -o name,state,running,cid,procs,cpu1s,cpu10s,memory,age

6. Access the Cell and Metrics

Open a shell in the running cell:

doas cellman cell shell demo-web

Export Prometheus-compatible runtime metrics:


Next Steps

  • See cellman(8) for command-level operations
  • See cellman-spec(5) for the full DSL/action reference
  • Use cellui for interactive lifecycle and backup operations on the same backend

Cells for NetBSD is under active development and is now moving toward a structured integration-build model.


Source Code

The project is maintained in a dedicated source tree and now primarily developed on a branch based on netbsd-11.

Repository (NetBSD 11, active):
https://github.com/MatthiasPetermann/netbsd-src/tree/netbsd-11-cells-dev

Bug Reports (GitHub Issues): https://github.com/MatthiasPetermann/netbsd-src/issues


Integration Builds

Integration builds are published under the name NeoBSD:

https://neobsd.com/

NeoBSD builds:

  • track current NetBSD branches
  • integrate the latest Cells state
  • use a clear versioning scheme
  • are produced by an open-source build system
  • keep release patches fully transparent and traceable

This means each release can be audited end-to-end, including the exact patch set used for the published artifacts.


Important Notice

Integration builds are not official NetBSD releases.

They are independent builds derived from NetBSD branches with additional Cells-related integration work.

They are intended for practical validation of workflows and behavior in non-production environments.

It is an independent effort and is not aligned with or endorsed by the NetBSD core team.

For official NetBSD releases, please refer to:
https://www.netbsd.org/


Status

This project is currently in an early-access maturity phase.

It is suitable for development, evaluation, and controlled pilot-style environments. Interfaces, behavior, and internal structures may still change as the design is hardened.

The goal is to deliver a reliable NetBSD-native isolation stack with clear operational contracts. The project should be seen as a focused implementation path that is actively being stabilized.

This page summarizes how the project evolved and why the current model looks the way it does.

1st Generation: Exploration

  • Early kernel and tooling experiments under the former “jails” naming
  • Strong technical findings, but scope was too broad for reliable delivery
  • Result: valuable research, not production-ready

2nd Generation: Product Direction

  • Renamed to “Cells” to avoid confusion with FreeBSD jails
  • Clearer operational shape with kernel/runtime/tooling components
  • Main limitation: shell-based control layer became hard to maintain at scale

3rd Generation: Current Model

  • Full shift to file-first desired state and explicit apply-based convergence
  • More predictable behavior for operators and automation
  • Shared backend model for CLI and TUI, improving consistency and responsiveness
  • Safety checks are fail-closed by default

This FAQ covers the most common questions about scope, positioning, and project direction.


“If this is not a full container ecosystem, is security still a core goal?”

Not at all. Security is a core goal.

Yes. Security is one of the central goals.

Cells focuses on practical, host-level workload isolation with clear operational boundaries. It is intentionally focused, not diluted by trying to be every kind of platform at once.


“Is this just another container platform?”

Not in the usual ecosystem sense.

Cells for NetBSD is a focused NetBSD isolation stack with its own operating model and toolchain, built for predictable behavior and straightforward ops.


“Why the name ‘cells’ instead of ‘jails’?”

Earlier iterations of the project used the term “jails”. During community discussion it became clear that the name strongly suggests full-stack FreeBSD jail compatibility, which is not the goal of this work.

Following feedback from the BSD community and a public naming discussion, the term “cells” was adopted instead. The name reflects the idea of small, isolated execution domains while avoiding confusion with existing FreeBSD jail semantics.


“How is this different from FreeBSD jails?”

FreeBSD jails are mature and feature-rich.

Cells follows a different path: NetBSD-native, intentionally focused, and aimed at a clean operator experience with declarative workflows and clear boundaries.


“Why keep the model this compact?”

Because simpler systems are easier to run well.

The project favors a smaller set of strong primitives over sprawling complexity, so teams can move faster with fewer surprises.


“Looks easy to use”

Thank you. Ease of use is intentional.

That is intentional.

The goal is to keep advanced isolation approachable for regular NetBSD administration workflows and daily production use.

This website is operated in accordance with applicable German law.

Content is provided without warranty as to accuracy, completeness, or timeliness. External links are the responsibility of their respective operators. All content is subject to German copyright law.

NetBSD® is a registered trademark of The NetBSD Foundation, Inc.
All other product and service names are the trademarks of their respective owners and are used for identification purposes only.

For full provider information and detailed legal disclosures,
please refer to the complete Legal Notice.


AI notice: AI tools were used for code analysis and prototyping.