Warden Runtime

Warden is the project name for Clawdie’s isolated execution and service layer on FreeBSD.

It does not replace Bastille or FreeBSD jail terminology. It describes how Clawdie uses those primitives together.

Current Model

the FreeBSD host runs the main orchestrator
Bastille manages the jailed service and worker layer
worker execution happens inside jailed runtimes
persistent service jails provide git, web, and optional database functions

In practice:

FreeBSD enforces isolation
Bastille creates and manages jails
Clawdie dispatches work and services into the Warden layout

Canonical Roles

Current main uses these runtime classes:

Role	Runtime	Shape	Persistence	Network
`worker`	FreeBSD jail	thin	ephemeral	shared
`networked-worker`	FreeBSD jail	thin	ephemeral	VNET
`controlplane`	host process	—	persistent	host
`db`	FreeBSD jail	thick	persistent	VNET
`git`	FreeBSD jail	thin	persistent	VNET
`cms`	FreeBSD jail	thin	persistent	VNET
`browser-vm`	Linux VM	image	persistent	bridged

The controlplane is NOT a jail — it runs on the host as part of the main agent service.

The database jail is provisioned by setup/db.ts, the git jail by setup/git.ts; neither uses the generic jail profile table.

Canonical Network Layout

The internal Warden subnet comes from AGENT_SUBNET_BASE / WARDEN_SUBNET_BASE on bridge warden0. Repo examples often use 10.0.1.0/24, but live installs can use any private /24.

Reserved addresses:

<subnet>.1 gateway on warden0
<subnet>.2 git
<subnet>.3 cms
<subnet>.4 Local AI Models (ollama / llama.cpp)
<subnet>.5 optional db
<subnet>.101+ workers
<subnet>.150 browser/gui profile

Internal names should use AGENT_INTERNAL_DOMAIN=<agent>.home.arpa.

Naming Rules

public domain: AGENT_DOMAIN
internal jail/service domain: AGENT_INTERNAL_DOMAIN
platform service names derive from the fixed service identity (clawdie), not from ASSISTANT_NAME
do not use .local as the internal default
do not reintroduce the old operator-jail model into the active runtime

Operator Model

There is no operator jail on current main.

SSH and Ansible target the FreeBSD host
the host manages Bastille, PF, services, and ZFS
db, git, and cms stay as host-managed service jails
workers remain sandboxed execution jails, not SSH-managed servers

Canonical operator reference:

Host operator model

Patch behavior

thin jails share the Bastille release tree
thick jails keep their own copied base userland
updating the host does not automatically patch either kind of jail userland
thin jails are easier to keep aligned because one Bastille release update can move many jails together

Long-Term Direction

keep host orchestration on the FreeBSD host
keep only the optional db jail thick
keep the rest of the service and worker jails thin unless a new role proves a real need for a copied base
keep worker execution isolated from those services
add browser automation through the separate VM class, not by bloating the jail model