Appliance Daemon

celld is the appliance source of truth. It owns host identity, pairing, SQLite state, operation records, persisted runtime descriptors, and backend orchestration.

Data Layout

celld uses DEVCELL_DATA_DIR when set. Otherwise it uses /var/lib/devcell when running as root on Linux and ~/.devcell/appliance during local user-mode development.

• state/: SQLite and durable control-plane state
• images/: kernel, initrd, rootfs, snapshots, and workspace image artifacts
• logs/: host and per-cell logs
• sockets/: local control sockets and guest transport endpoints
• cells/: per-cell metadata and backend descriptors
• tls/: host TLS identity
• pairing/: pairing challenges and paired-client token hashes

Startup

At startup celld ensures the layout exists, loads or creates host TLS identity, opens SQLite, registers the host row, reconstructs backend state from persisted cells/runtime records, and fails interrupted operations conservatively.

Runtime Records

Each cell can have a persisted runtime record:

• backend name, such as fake, container, or firecracker
• runtime state, such as ready, running, stopped, failed, or destroyed
• backend descriptor JSON, including Firecracker runtime paths and vmconfig.json when available
• last backend error
• created and updated timestamps

cell inspect and cell logs --source celld expose this information so failed runtime preparation can be debugged through the same API the Swift app uses.

Local Auth

--require-auth protects cell and operation APIs with paired bearer tokens. Host negotiation and pairing RPCs remain open so a new client can pair.

nix develop -c go run ./cmd/celld --data-dir ~/.devcell/appliance --require-auth

HTTPS is the default. Use plain HTTP only for local tests:

nix develop -c go run ./cmd/celld --http-dev --data-dir /tmp/devcell-appliance