Configuration reference
DRC configuration is explicit. Server and worker processes require DRC_MODE=local or DRC_MODE=hosted; missing or unsupported values fail startup.
Core settings
| Setting | Required | Meaning |
|---|---|---|
DRC_MODE |
yes | local or hosted. Selects the authoritative storage/control-plane mode. |
DRC_API_HOST |
hosted | Bind address. Use 0.0.0.0 behind a controlled network boundary. |
DRC_API_URL |
hosted clients | Public API URL used by CLI and integrations. |
DRC_DATABASE_URL |
hosted | PostgreSQL control-plane connection. |
DRC_REDIS_URL |
hosted | Redis coordination connection. |
DRC_ARTIFACT_BUCKET |
hosted | Immutable artifact-store bucket or container. |
DRC_SEGMENT_SIGNING_KEY_PATH |
local | Managed Ed25519 key for durable local segment signing. |
DRC_TLS_REQUIRED |
exposed API | Requires TLS when the API is not loopback-only. Local Compose may set this to false only with a loopback host bind; hosted API Compose may set it to false only behind an explicitly trusted TLS-terminating proxy. |
DRC_TLS_TERMINATED_BY_PROXY |
hosted reverse proxy | Explicitly authorizes plain HTTP from the private API to a trusted TLS-terminating proxy; never enable it on a directly exposed API. |
DRC_JWT_PRIVATE_KEY_PATH |
authenticated API | Managed JWT signing key path or secret reference. |
Use the root .env.example as the only configuration template. Copy it to .env at the repository root; supply secrets through a managed secret store in production.
Local authority
Local capture uses StoragePlaneAdapter → WAL → signed segments → verified reconstruction. A durable local workspace must provide DRC_SEGMENT_SIGNING_KEY_PATH. Ephemeral signing keys are test-only.
Hosted authority
Hosted capture uses PostgreSQL receipt → bounded Redis promotion state → immutable artifact store. A hosted process does not silently fall back to local files when a required authority is unavailable.
Enterprise identity and observability
Hosted sign-in supports GitHub and Google OAuth when both provider credentials are configured. Register these exact callback URLs with each provider:
${DRC_WEB_ORIGIN}/api/v1/auth/oauth/github/callback${DRC_WEB_ORIGIN}/api/v1/auth/oauth/google/callback
GitHub and Google remain visible as first-class sign-in buttons even before configuration, but the server only completes the flow when the matching client ID and secret are present. Team SSO is self-service OIDC: a workspace administrator adds and validates an issuer in Workspace Settings → SSO, then members choose that named connection from the SSO sign-in page. API keys and external identity assertions remain tenant-scoped. An external assertion is accepted only when its canonical payload, signature, issuer, audience, and time window validate; DRC_IDENTITY_ASSERTION_SECRET is a server-side secret and is never returned by the API.
Identity email delivery is provided by the service configured in DRC_IDENTITY_EMAIL_DELIVERY_URL. DRC authenticates to the delivery service with the shared token in DRC_IDENTITY_EMAIL_DELIVERY_TOKEN (or DRC_IDENTITY_EMAIL_TOKEN), sent as the x-drc-email-token header; the value must match the DRC_IDENTITY_EMAIL_TOKEN configured on the delivery endpoint. DRC sends a JSON request for each verification, password-reset, and workspace-invitation message. The request includes kind, to, email, subject, text, html, action_url, token, and expires_at; the delivery service should send the supplied html or text content without logging the token. Verification links use ${DRC_WEB_ORIGIN}/email-verification/complete?token=..., password reset links use ${DRC_WEB_ORIGIN}/password-reset/complete?token=..., and invitation links use ${DRC_WEB_ORIGIN}/invitations/accept?token=.... Tokens are stored only as SHA-256 hashes, expire after 60 minutes for verification, 30 minutes for password reset, or 7 days for invitations, and are single-use. Set DRC_WEB_ORIGIN to the public browser origin so links resolve to the deployed app. The delivery endpoint should return any 2xx response after accepting the message; non-2xx responses fail the request so the caller can retry.
Use Prometheus, Grafana, Datadog, and OpenTelemetry integrations through the deployment's approved observability boundary. Istio and Linkerd service-mesh deployments must keep mTLS enabled at exposed service boundaries.
Security settings
- Set TLS requirements explicitly and validate certificates before accepting traffic.
- Keep signing, encryption, database, object-store, and provider credentials separate.
Boolean values
Use true or false in configuration. Components normalize case but do not treat an unset security setting as an opt-in production fallback.