Daevix Docs

Configuration

Configure every Daevix component through command-line flags and DVX_ environment variables. This page gives the precedence rules, the defaults that differ per component, and the fail-closed settings that you cannot quietly turn off.

View as Markdown Edit on Tangled

Daevix is one binary, dvx, and every server component runs as dvx serve <component>. See CLI reference for the complete generated flag listing; this page explains the shape and the defaults.

How configuration works

There is no configuration file. Each dvx serve <component> command reads its settings from flags, and every flag has a matching environment variable. The precedence is flags, then environment variables, then built-in defaults. All environment variables start with DVX_.

A flag help line shows both parts. This line from dvx serve imds names the flag, the default, and the env var in brackets:

--imds-socket string   unix socket path for the IMDS-like metadata service agents mount (default: "/run/dvx/imds.sock") [$DVX_IMDS_SOCKET]

Set env vars in the manifest rather than on the shell for anything long-lived; the enclave DaemonSets configure their components that way, with values pulled from ConfigMaps and Secrets. For example, DVX_ENCLAVE_ID on the gateway DaemonSet comes from the dvx-enclave-identity ConfigMap.

To see the authoritative flag list for a component, ask the binary:

dvx
 dvx serve broker --help

Flags shared by most components

Most components take these flags. Defaults shown are the common ones.

FlagEnv varMeaningDefault
--addrDVX_ADDRTLS listen address for the component’s primary APIper component, see below
--tls-certDVX_TLS_CERTserving certificate (PEM)required
--tls-keyDVX_TLS_KEYserving key (PEM)required
--database-dsnDVX_DATABASE_DSNPostgreSQL DSN; empty runs in skeleton modeempty
--log-levelDVX_LOG_LEVELdebug|info|warn|errorinfo
--log-formatDVX_LOG_FORMATjson|textjson
--metrics-addrDVX_METRICS_ADDRdedicated TLS /metrics listener; empty disables itempty

Two components deviate. The gateway listens on a unix socket that Cilium’s Envoy dials, so it takes --envoy-socket (default /var/run/cilium/envoy/sockets/dvx-gateway.sock) instead of --addr, and it does not require --tls-cert/--tls-key for its primary path. The forensics daemon has no HTTP surface at all: no --addr, no TLS, only the flags listed in its help.

The gateway’s /metrics listener is also different: it takes its own --metrics-tls-cert and --metrics-tls-key, because the gateway has no shared serving certificate to reuse. Every other component reuses its --tls-cert and --tls-key for metrics.

Per-component API port defaults

Each component that serves a TCP API has its own --addr default:

ComponentDefault --addr
controlplane:8443
imds:8444
broker:8450
relay:8452
llmproxy:8480

Fail-closed settings

Some settings fail closed: a required companion or an empty value stops the process at startup instead of degrading behavior. Three of them matter most in operation.

Audit durability. Every component that accepts --audit-dsn (the ClickHouse audit store) also requires --audit-wal-dir when the DSN is set. The process refuses to start with an audit store but no write-ahead log directory, because audit evidence must survive a store outage. Related flags: --audit-wal-max-bytes (the spool ceiling; 0 uses the reviewed per-component default) and --audit-capture-or-deny (on by default; set false only deliberately, to return the authority audit tier to best-effort recording). --audit-capture-timeout bounds the block, default 5s.

TLS on API listeners. The components with an --addr require --tls-cert and --tls-key. The broker is the exception when it acts as its own certificate authority: with --local-issuer it mints its own serving certificate.

llmproxy inference audit. On dvx serve llmproxy, --kms-provider is required with --audit-dsn, because inference bodies are sealed per-org before storage; there is no plaintext audit body path.

Flags worth knowing by component

The full surface is large and the CLI reference lists it exhaustively. These are the flags that most operators change.

controlplane: --oidc-issuer and --oidc-audience mount the operator API behind token authentication; --zitadel-key enables Zitadel provisioning; --policy-publish-dir and --config-publish-dir fan policy and config snapshots out to registered enclaves; --rendezvous-signer-key provisions the interactive-access transport, further limited by --wireguard-access and --exec-access (both on by default); --kms-provider encrypts controlplane metadata at rest (empty stores values plaintext).

imds: --imds-socket (default /run/dvx/imds.sock) is the socket that agents mount; --vsock-relay with --vsock-dir (default /run/vc) serves Kata agent VMs; --config-snapshot, --policy-snapshot, and --rendezvous-sessions point at snapshot files that the broker’s sidecars deliver; --secret-broker-url reads secrets from the broker over mTLS instead of the deprecated local store.

gateway: --ca-cert/--ca-key turn on TLS termination of agent egress; --policy-snapshot (or the legacy --allow-dest list) sets egress policy; --k8s-attribution or --vm-attribution-file joins connections to agent identities; --http-capture records request and response bodies (on by default, but a no-op unless --kms-provider is set, since bodies must be sealed); --llmproxy-addr force-routes inference calls to llmproxy.

broker: --controlplane is the base URL that it pulls metadata from; --zitadel-key with --issuer authenticates the pull; --local-issuer makes it the enclave’s certificate authority; --operator-addr mounts the operator secret API; --dev-mode acknowledges a dev broker and enables the dev-only flag --dev-agent-specs, which the broker refuses to honor without it.

relay: --broker-url names the private broker listener that it proxies to; --rendezvous mounts the interactive-access WSS surface (off by default); the rendezvous timeout flags (--rendezvous-join-timeout, --rendezvous-idle-timeout, --rendezvous-max-lifetime) default to 0 and then use the built-in defaults.

llmproxy: --agent-ca names the trust bundle that a presented SVID must chain to; --policy-snapshot resolves per-agent credential mode and model gating; --upstream-default is the catch-all upstream (empty fails closed on an unresolvable upstream); --inspection-disclosure (detailed by default) and --escalation-timeout (default 5 minutes) control what the agent sees on a denial; --translate enables cross-format translation (off by default, which forwards every call byte-unchanged).

forensics: --enclave-id is required; --vc-dir (default /run/vc), --run-dir (default /run/dvx), and --proc-dir (default /proc) locate the Kata runtime state; --poll-interval re-checks containment policies every 30s by default.

Environment variables in the manifests

The deploy manifests set the env vars directly. The gateway DaemonSet is a representative example: DVX_ENVOY_SOCKET, DVX_ENCLAVE_ID, DVX_ENCLAVE_NAME, DVX_CA_CERT, DVX_CA_KEY, DVX_POLICY_SNAPSHOT, DVX_K8S_ATTRIBUTION, and DVX_LOG_LEVEL all appear in its env block. When you configure a component for Kubernetes, set the env var; when you run a component by hand, pass the flag. Both spellings appear in each flag’s help line, so --help is always the source of truth for either form.