how-to operator public

Deploy DRC

Choose hosted DRC for a managed workspace or self-managed DRC when your organization owns the runtime and data services.

Self-managed topology

Private Cloud and air-gapped deployments use the supported Helm or Compose distribution package supplied for your deployment. The deployment can be restricted to internal-DNS-only and proxy-only network paths, with data residency and object-store replication selected by the operator. Use the versioned customer deployment package and its release-specific values.

Your DRC representative provides the current package. Instructions that reference internal source, build, or CI paths are not part of the customer installation contract; follow the values and runbooks that ship with the package you received.

The supported self-managed topology is:


clients and capture agents
        ↓ TLS
DRC API replicas ───── PostgreSQL
        │                 │
        ├──────────── Redis coordination
        └──────────── immutable object storage
                         │
                    DRC workers

PostgreSQL is the control-plane authority. Redis is coordination and bounded promotion state, not the sole durable copy. Object storage is the immutable artifact authority after the upload and database link are verified.

Install with the supported path

Use the on-prem Compose or Helm deployment supplied with the release. Provide explicit values for:

DRC_MODE=hosted
PostgreSQL connection and migration ownership
Redis connection
immutable artifact-store endpoint and credentials
TLS certificate and key references
managed evidence and signing-key references
API bind address and public URL

Run the distribution package’s preflight, migration, and smoke-test commands in order. The checks fail closed when a required authority is missing. A passing configuration check is not a substitute for a staging failure-recovery test.

For a private release, keep container registry credentials and any image overrides in the deployment environment rather than committing them. Record the exact image digests or release tags in the rollout record before starting customer workloads.

Scaling

Scale API replicas independently from workers. Keep PostgreSQL connection limits, Redis capacity, object-store throughput, WAL disk pressure, and worker concurrency within the values tested by your deployment. Do not advertise a throughput or availability target without matching evidence from your environment.

Backups and recovery

Back up PostgreSQL, WAL, and immutable evidence artifacts under one retention policy. Test restore into an isolated environment, replay a known verification workload, and record measured RPO/RTO before relying on the backup.

Upgrades

Apply migrations before starting a binary that requires them. Use the release upgrade and rollback checks, and never delete old evidence or signing keys as part of a normal application rollback.