Sotero

Install guide · RHEL

Sotero Runtime RHEL Installation and Developer Setup Guide

Install, configure, verify, operate, integrate, upgrade, and remove Sotero Runtime 0.0.2 on Red Hat Enterprise Linux (RHEL) x86_64. The shortest successful path: install the package, run the daemon once to create configuration, validate it, configure and start the registered systemd service, and confirm that both supervisor and health report success.

AudienceDevelopers and technical evaluators
Packagesotero-runtime-0.0.2-linux-x86_64.rpm
Supported distribution/archx86_64 (verified on RHEL 10.2)
Default transportLocal Unix domain socket

Before you begin

What the installer adds

The package installs a self-contained Sotero daemon, shared developer resources, and a systemd service registration. The service runs under a dedicated, unprivileged sotero-daemon system account — not root, and not your own login user. This means the background service's configuration and state live in a different location from the one you create when trying the daemon interactively as yourself.

ComponentInstalled location
Daemon command/usr/bin/sotero-daemon
Shared files and examples/usr/share/sotero-runtime
systemd unit/etc/systemd/system/sotero-daemon.service
Service environment file/etc/sotero-daemon/environment
Per-user configuration and state (interactive)~/.sotero/ (only used if you run sotero-daemon interactively as yourself)
Service configuration and state/var/lib/sotero-daemon/.sotero/ (used by the systemd-managed instance, owned by the sotero-daemon account)

Requirements

  • RHEL x86_64. This guide was verified end to end on RHEL 10.2; other current RHEL releases are expected to work the same way.
  • A user account with sudo rights for package installation and service management.
  • Terminal access for initial configuration, health checks, and developer operations.
  • The official .rpm and, when supplied, its matching .sha256 checksum file.

Download Sotero Runtime

  1. Open the Download link from the site navigation and sign in with Google, Microsoft, or your Sotero email and password. Create an account if you don't already have one.
  2. Review and accept the End User License Agreement. Marketing or product-contact consent, when presented separately, is optional.
  3. Choose RHEL x86_64 and download sotero-runtime-0.0.2-linux-x86_64.rpm.
Security check. Verify the package before installing. RHEL packages are RPM-signed as well as checksummed — check both. A NOKEY result on the signature means the package's digests are genuine but Sotero's public signing key has not been imported on this machine yet; import it from your release channel to get a fully verified pgp OK result, or at minimum confirm the digests are OK as shown below.
cd ~/Downloads
sha256sum -c sotero-runtime-0.0.2-linux-x86_64.rpm.sha256
rpm -Kv sotero-runtime-0.0.2-linux-x86_64.rpm

If no checksum sidecar is supplied, your release administrator should provide the expected SHA-256 value through a trusted channel.

Install with dnf

sudo dnf install -y ./sotero-runtime-0.0.2-linux-x86_64.rpm

What happens automatically. The package creates a dedicated sotero-daemon system account, installs /etc/systemd/system/sotero-daemon.service, and enables it (systemctl enable) — but does not start it yet, the same "register, don't start" posture as macOS and Windows. It also installs /etc/sotero-daemon/environment.example as a template for the one required secret.

Installing over an existing 0.0.2 installation refreshes the installed files while preserving both ~/.sotero/ and /var/lib/sotero-daemon/.sotero/.

Configure the first run

Choose how to provide the required secret

The required [control].signing_key_secret performs two security jobs: it encrypts the persisted JWT signing key and authenticates Control API operations. It must contain at least 32 bytes.

ScenarioRecommended choice
Local evaluation on one machineRun sotero-daemon interactively and press Enter to generate a secure value.
Multiple machines that must trust the same credentialsUse the same high-entropy secret supplied through your approved secret-management process.
systemd-managed serviceStore the value in /etc/sotero-daemon/environment. A systemd service does not inherit variables exported in your shell's .bashrc or a terminal session.

Run the setup wizard

  1. Open a terminal and run sotero-daemon without sudo.
  2. At the hidden Signing key secret prompt, enter an approved shared secret or press Enter to generate one for local use.
  3. Wait until the daemon reports that it is ready on ~/.sotero/daemon.sock.
  4. Press Ctrl+C to stop this temporary foreground process.
  5. Run sotero-daemon config validate. Continue only when it reports that configuration is complete.

Start and verify the background service

The package already registered sotero-daemon as a systemd service. It runs as the dedicated sotero-daemon account, so it uses its own configuration, separate from the one you just created as yourself: /var/lib/sotero-daemon/.sotero/sotero.toml.

  1. Give it the one required secret via the environment file (never generated on the machine itself — reuse the same value across every machine that needs to trust each other's credentials).
  2. Start the service and confirm it is active.
sudo cp /etc/sotero-daemon/environment.example /etc/sotero-daemon/environment
sudo nano /etc/sotero-daemon/environment

Fill in a real value for SOTERO_CONTROL_KEY_SECRET, save, and exit. Generate one with openssl rand -hex 32 if you don't already have one to reuse:

openssl rand -hex 32
sudo systemctl start sotero-daemon
systemctl status sotero-daemon
Real, verified gotcha: sudo sotero-daemon service status (plain root) checks root's own — nonexistent — configuration and always reports Health unreachable, even when the service is genuinely healthy. Impersonate the service account instead, and run it from a directory that account can read (e.g. /tmp) — running it from your own home directory crashes with an unhandled PermissionError, because sotero-daemon cannot even traverse into your home directory to look for a (nonexistent) relative sotero.toml there.
cd /tmp
sudo -H -u sotero-daemon sotero-daemon service status
sudo curl --unix-socket /var/lib/sotero-daemon/.sotero/daemon.sock http://localhost/healthz
sudo curl --unix-socket /var/lib/sotero-daemon/.sotero/daemon.sock http://localhost/readyz

Use the ready endpoint for deployment checks because it verifies the registry, policy catalog, signing and replay store, and Control authentication — not only whether the process exists.

Service lifecycle commands

TaskCommand
Show status and healthsudo -H -u sotero-daemon sotero-daemon service status (run from /tmp or similar)
Startsudo systemctl start sotero-daemon
Restart after configuration changessudo systemctl restart sotero-daemon
Stopsudo systemctl stop sotero-daemon
Re-register the systemd unitsudo sotero-daemon service install
Unregister the systemd unitsudo sotero-daemon service uninstall

install, uninstall, start, stop, and restart via the sotero-daemon service ... wrapper all require sudo on Linux. Plain systemctl start|stop|restart|status sotero-daemon work identically and are equally valid.

View live logs any time with:

sudo journalctl -u sotero-daemon -f

Use Sotero Runtime as a developer

Use the Unix socket from an application

RHEL defaults to a Unix domain socket, not a browser-addressable TCP port. Copy the packaged thin client into your Python project under an importable filename.

cp /usr/share/sotero-runtime/thin-client.py ./sotero_thin_client.py
python -m pip install "httpx>=0.27" "PyJWT[crypto]>=2.8" "cryptography>=42"
from pathlib import Path
from sotero_thin_client import ThinClientRuntime

runtime = ThinClientRuntime()
runtime.onboard(
    daemon_url="http://daemon",
    socket_path=Path.home() / ".sotero" / "daemon.sock",
)

When Control API authentication is required, supply the secret through SOTERO_CONTROL_KEY_SECRET or the api_key argument using your application's secret-management mechanism. Do not hard-code it.

Install the bundled Claude Code skills

sotero-daemon install-skills
# Default destination: ~/.claude/skills

Run this command without sudo. It updates bundled Sotero skill directories but does not touch unrelated skills. Restart Claude Code if it was already running and does not detect the newly installed skills.

Useful operator commands

PurposeCommand
List registered agentssotero-daemon agent list
Show recent audit entriessotero-daemon logs --last 100
Follow the audit logsotero-daemon logs --follow
Print local Control credentials for a trusted toolsotero-daemon print-credentials --json
Validate configuration without startingsotero-daemon config validate
Dashboard note. With the default Unix socket transport, a normal browser cannot connect directly to the daemon. The command sotero-daemon show dashboard will explain this. Use the external Sotero control-plane UI, or explicitly configure TCP, only when your deployment requires it.

Configuration and file reference

Interactive (~), your own account, vs. service, /var/lib/sotero-daemon/.sotero — same filenames, different parent directory:

ItemFilename
Configurationsotero.toml
Agent registryregistry.db
Signing and JWT keystorekeys.db
Replay and nonce security storesecurity.db
Audit logaudit.jsonl
Unix socketdaemon.sock
Default editable policyexamples/policy.rego
Secret (environment)inside sotero.toml (interactive) or /etc/sotero-daemon/environment (service)

When changes take effect

  • Changes to sotero.toml and SOTERO_* environment variables require a service restart.
  • A configured agents.json file and a configured Rego policy file are watched and hot-reloaded.
  • When both sotero.toml and a matching environment variable contain a value, sotero.toml wins.
  • For the systemd-managed instance, put required secrets in /etc/sotero-daemon/environment — a shell export in your own session never reaches a systemd-started process.

Logs and troubleshooting

SymptomWhat to check
command not found: sotero-daemonOpen a new terminal, then run /usr/bin/sotero-daemon --help. Confirm /usr/bin is on PATH.
Configuration is incomplete and exit code 78Set [control].signing_key_secret in /etc/sotero-daemon/environment (service) or sotero.toml (interactive), then validate and restart.
service status reports Health unreachable even though the service is activeImpersonate the account: sudo -H -u sotero-daemon sotero-daemon service status, run from a directory it can read (e.g. /tmp).
sudo -H -u sotero-daemon crashes with PermissionErrorRun it from a directory the account can traverse — cd /tmp first. It cannot read your own home directory.
A shell environment change has no effectsystemd does not inherit shell exports. Put the setting in /etc/sotero-daemon/environment and restart.
Browser cannot open localhost UIDefault transport is a Unix socket. This is expected; use a socket-capable client or the external UI.

Detailed diagnostics

sudo systemctl status sotero-daemon
sudo journalctl -u sotero-daemon -n 100 --no-pager
ls -la ~/.sotero
sudo ls -la /var/lib/sotero-daemon/.sotero
sotero-daemon config validate

Upgrade Sotero Runtime

  1. Back up ~/.sotero/ and /var/lib/sotero-daemon/.sotero/ before a major upgrade, especially sotero.toml, keys.db, registry.db, security.db, and audit.jsonl.
  2. Download and verify the newer official .rpm.
  3. Install it over the existing version with dnf install. The package preserves both state directories and re-registers the systemd unit.
  4. Run sotero-daemon config validate, restart the service, and confirm active and healthy.
sudo dnf install -y ./sotero-runtime-<new-version>-linux-x86_64.rpm
sudo systemctl restart sotero-daemon
sudo -H -u sotero-daemon sotero-daemon service status # run from /tmp

Uninstall Sotero Runtime

Preserve or remove user data deliberately. The standard removal below stops and unregisters the systemd service and deletes the installed product files, but leaves both ~/.sotero/ and /var/lib/sotero-daemon/.sotero/ in place, so a reinstall can resume with the same configuration, keys, registry, and audit history.

Remove the application and service

sudo dnf remove -y sotero-runtime

Verify the binary and unit are gone:

test ! -e /usr/bin/sotero-daemon && echo "binary removed"
systemctl status sotero-daemon # expect: "could not be found"

This does not remove the dedicated sotero-daemon system account, ~/.sotero/, or /var/lib/sotero-daemon/.sotero/.

Optionally remove all user data

Irreversible. Deleting these directories removes configuration, signing keys, registry data, security state, policies, and audit history. Back them up first if any of this must be retained.
cp -a ~/.sotero ~/Desktop/sotero-backup
sudo cp -a /var/lib/sotero-daemon/.sotero /root/sotero-service-backup
rm -rf ~/.sotero
sudo rm -rf /var/lib/sotero-daemon/.sotero
sudo userdel sotero-daemon
sudo groupdel sotero-daemon
sudo rm -rf /etc/sotero-daemon

Quick reference

GoalCommand
Validate configurationsotero-daemon config validate
Start (service)sudo systemctl start sotero-daemon
Restart (service)sudo systemctl restart sotero-daemon
Stop (service)sudo systemctl stop sotero-daemon
Check status and health (service)sudo -H -u sotero-daemon sotero-daemon service status (from /tmp)
Check liveness (service)sudo curl --unix-socket /var/lib/sotero-daemon/.sotero/daemon.sock http://localhost/healthz
Check readiness (service)sudo curl --unix-socket /var/lib/sotero-daemon/.sotero/daemon.sock http://localhost/readyz
Follow service logssudo journalctl -u sotero-daemon -f
Follow audit eventssotero-daemon logs --follow
Install Claude Code skillssotero-daemon install-skills

Expected steady state: configuration complete, supervisor active, health healthy, and both health endpoints returning success.

Ready to install?

Download the Sotero Runtime RPM package from the site navigation, then follow this guide.