Sentinel CLI

The sentinel CLI controls the Sentinel daemon (sentineld) over a local socket. The daemon runs as a systemd service, holds the robot's device identity, and manages the runtime container.

Commands

Command	What it does
`sentinel status`	Show daemon, stack, container, device identity, signaling, and config state. Problems are collected in an `errors:` section after the summary
`sentinel enroll [<key>]`	Enroll the robot with its license key. Prompts when the key is omitted; re-enrolling an already-enrolled robot asks for confirmation first. With the key as an argument, runs without prompts (for scripts)
`sentinel start`	Start the runtime stack. Requires enrollment (`sentinel enroll` first)
`sentinel start --camera-only`	Start the stack in the camera-only profile
`sentinel stop`	Stop the runtime stack. The daemon stays up and the robot stays reachable
`sentinel restart`	Stop, wait, and start again — this applies a pending configuration or runtime-version update
`sentinel logs`	Print the runtime container's logs. `-f` follows, `--tail N` sets the backlog
`sentinel doctor`	Check host prerequisites: Docker, GPU runtime, daemon reachability
`sentinel config status`	Show which configuration the stack runs with, and whether a newer one is available
`sentinel config pull`	Fetch the resolved configuration from the platform now
`sentinel data status`	Show episode reporting and cloud-sync state — per-episode, per-destination, and backlog totals
`sentinel data push`	Trigger a sync pass now instead of waiting for the timer
`sentinel token`	Mint a fresh device JWT and print it. `--json` prints `{token, expires_at}`
`sentinel version`	Print the CLI version

sentinel logs streams the runtime container; for the daemon's own logs use journalctl -u sentineld -f.

sentinel token composes with anything that speaks HTTP:

curl -H "Authorization: Bearer $(sentinel token)" ...

Stopping and starting vs. the daemon

sentinel stop stops the runtime container only. The daemon keeps running, keeps the robot's cloud connection, and reports state — so the robot shows as reachable (with the stack down) instead of vanishing. Stopping the daemon itself is a systemd operation:

sudo systemctl stop sentineld     # take the robot fully offline
sudo systemctl restart sentineld  # restart after an upgrade
journalctl -u sentineld -f        # follow daemon logs

Files

Path	Contents
`/usr/local/bin/sentinel`, `/usr/local/bin/sentineld`	The two binaries
`/etc/systemd/system/sentineld.service`	The daemon's systemd unit
`/etc/sentinel/sentineld.env`	Daemon environment overrides. Never overwritten by upgrades
`/var/lib/sentinel/identity/`	Device identity from enrollment. Treat as secret
`/var/lib/sentinel/config/`	Cached resolved configurations, keyed by content hash
`/var/lib/sentinel/datasets/`	Recorded episodes and the sync ledger — see Using your data
`/run/sentinel/`	Local API socket

Environment overrides

Set daemon overrides in /etc/sentinel/sentineld.env and restart the service. The ones you may actually need:

Variable	Purpose
`SENTINELD_CONFIG_URL`	The platform config endpoint. The installer sets it; without it the daemon has no cloud config and no runtime image to resolve
`SENTINELD_CONFIG`	Run from a local config file instead of the platform-served one
`SENTINELD_IMAGE`	Pin a specific runtime image (full ref) — overrides the config-pinned version

Everything else — authentication, image pulls, config fetching, telemetry — is automatic.

Commands

Stopping and starting vs. the daemon

Files

Environment overrides

On this page