Docs/Configuration & storage

Configuration & storage

Keep runtime settings, project metadata, and credentials in their proper locations.


Daemon storage

Dieter data defaults to ~/.dieter, overridden by DIETER_HOME or the CLI’s --store PATH. This is the central location for metadata, transcripts, queues, local execution state, logs, and managed runtime/worktree data. Shared project and settings records replicate between account daemons; execution records retain their owner.

Repositories stay ordinary Git working trees. Dieter does not write its metadata into them, although agents intentionally edit repository files when doing work. Use the daemon API or CLI for operations instead of editing central storage.

Agent configuration

SettingPurpose
DIETER_HOMECentral daemon data root
$DIETER_HOME/harnesses.yamlOptional per-daemon model/capability registry override
DIETER_HARNESS_CONFIG / --harness-configExplicit registry path
CODEX_HOME, CLAUDE_CONFIG_DIR, PI_AGENT_DIR, OMP_PROFILE, DSH_HOMEProvider-specific configuration selection
DIETER_CODEX_ACCOUNT_HOMESExplicit OS path-list of up to eight quota profile directories

See Agents & models for credentials and runtime behavior, and the environment reference for every daemon variable. The daemon also reads $DIETER_HOME/.env (mode 0600, or --env-file PATH); it never overrides variables that are already set.

Gateway settings

Keep the real .env at $DIETER_GATEWAY_HOME/.env with mode 0600; process environment values override it. Start from deploy/gateway/gateway.env.example . Every variable is listed in the environment reference .

SettingPurpose
DIETER_GATEWAY_HOMEGateway SQLite and private identity root; default ~/.dieter-gateway
DIETER_PUBLIC_URLPublic HTTPS origin
DIETER_GATEWAY_ISSUERDurable authentication namespace; preserve the original origin when moving a gateway endpoint
DIETER_GATEWAY_ADDRListener; loopback behind a same-host reverse proxy
DIETER_GATEWAY_PROXY_MODE1 for reverse-proxy TLS termination
DIETER_GATEWAY_TLS_CERT, DIETER_GATEWAY_TLS_KEYDirect TLS certificate and key
DIETER_GITHUB_CLIENT_ID, DIETER_GITHUB_CLIENT_SECRETGitHub OAuth App credentials
DIETER_GITHUB_ALLOWED_USER_IDSComma-separated immutable numeric GitHub IDs
DIETER_AUTH_SECRETGateway authentication secret
DIETER_NATIVE_SESSION_TTLNative session lifetime
DIETER_NATIVE_REDIRECT_URISExact allowlisted native OAuth callbacks
DIETER_RTC_STUN_URLS, DIETER_RTC_TURN_URLSICE services for Screens and data-only WebRTC API routes
DIETER_RTC_TURN_SECRETHex-encoded coturn REST secret, at least 32 bytes
DIETER_RTC_TTLSigned ICE configuration lifetime; default five minutes

The signed deployment bundle accepts canonical printable UTF-8 turnSharedSecret text and hex-encodes its exact bytes for Dieter while giving coturn the text. Follow the deployment guide when using the bundle; do not double-encode or silently replace an existing secret.

The gateway stores control metadata and normalized credential-free quota snapshots. Provider credentials and raw provider responses stay off the gateway.

Restart and recovery

Graceful shutdown preserves continuation state. Managed service updates stage a verified daemon/helper pair and prepare its harness runtime before activation. An in-flight turn stays pinned to its runtime until completion. Terminal restart persistence requires tmux; remote execution processes end on daemon shutdown.

Never launch a second daemon beside an existing service to change configuration. Inspect dieter daemon status and use the platform’s managed service lifecycle. Development tests must use isolated state and random loopback ports.

Release compatibility and protocol

The authoritative schema lives in api/proto. Gateway, daemon/CLI, and native clients share one release version; the gateway publishes minimum client and daemon releases. just generate regenerates the Go and Swift bindings; the Kotlin build generates its own. There is no historical API compatibility branch, REST application API, or browser application.

Improve this page on GitHub ↗

Type to find a guide.