Skip to main content

​
Deployment and hardening

Kheish is easiest to operate safely when deployment boundaries are explicit.
  • dedicate a state root per environment or daemon instance
  • dedicate a workspace root appropriate for the agent’s trust boundary
  • manage route credentials through auth_ref plus kheish-daemon secrets ..., not inline route-file secrets
  • set and protect KHEISH_AUTH_STORE_MASTER_KEY for every daemon that reads or mutates the encrypted auth store
  • prefer KHEISH_AUTH_STORE_MASTER_KEY_FILE and control-plane token files in containerized deployments
  • enable control-plane auth before any non-local exposure
  • separate production, staging, and development daemons
  • treat connector config, hook config, and MCP config as deployable artifacts

​
External integration boundaries

Review these surfaces before production use:
  • ingress connectors
  • output routing targets
  • hook executors
  • shell execution
  • MCP server credentials
In containerized deployments, the recommended production boundary is one daemon container plus separate connector services talking to it through remote_http. The official daemon image is not meant to be the universal home for every platform-specific sidecar runtime.

​
Persistence and recovery

Back up the state root if sessions, public channels, or queued deliveries are operationally important. The daemon persists critical runtime state there, including session journals, channel records and event logs, scheduler state, daemon-managed persona records, the compact persona index, encrypted auth slots, debug artifacts, and delivery queues.

​
Validation

Validate production changes on an isolated daemon with:
  • a fresh state root
  • fresh sessions
  • populated auth_ref slots and a known KHEISH_AUTH_STORE_MASTER_KEY
  • explicit route identifiers and model settings
  • real connector or output targets only when you are ready to test end to end