Prerequisites
Before you begin, make sure your environment meets the requirements below. We recommend reviewing this checklist with your DuoKey representative during the planning phase.
Platform
| Requirement | Recommended |
|---|---|
| OpenShift | A current supported 4.x release (OKD equivalent supported) |
| Cluster topology | 3 control-plane nodes + ≥ 3 worker nodes across ≥ 3 failure domains |
| Container runtime | CRI-O (default in OpenShift) |
| Storage | OpenShift Data Foundation (ODF) or a CSI driver providing ReadWriteOnce block volumes and snapshot support |
| Ingress | OpenShift Ingress Router (built-in) with a wildcard DNS + TLS certificate |
| Object storage | S3-compatible bucket for backups (ODF NooBaa, MinIO, or external) |
Compute sizing (starting point)
These are baseline figures for a production HA deployment. Final sizing depends on the number of keys, clients, and request volume.
OpenShift worker nodes
| Profile | vCPU | RAM | Notes |
|---|---|---|---|
| Per worker (min 3) | 8 | 32 GB | Hosts frontend, backend, observability pods |
Dedicated VM tier
| VM | Count | vCPU | RAM | Disk |
|---|---|---|---|---|
| OpenBao | 3 (HA / Raft) | 2 | 4 GB | 50 GB SSD |
| PostgreSQL | 3 (1 primary + 2 replicas) | 4 | 16 GB | 200 GB SSD |
| GitLab | 1 | 4 | 8 GB | 100 GB |
The VM tier can be virtualized on your existing hypervisor (VMware, Proxmox, KVM/OpenStack). Keep OpenBao and PostgreSQL on separate physical hosts where possible to avoid a single point of failure.
DKE on-premise sizing
For Double Key Encryption (DKE) deployments, the dominant workload is key wrap/unwrap requests, which are lightweight but bursty — they spike when users open or save protected documents. Size for peak concurrency, not just total user count.
Per-component resources (HA baseline)
These are the request sizes per replica for the DuoKey components, with the minimum replica count for a highly available deployment. Images come from the Harbor registry.
| Component | vCPU / replica | RAM / replica | Storage | Min replicas (HA) |
|---|---|---|---|---|
| Cockpit UI (frontend) | 2 | 4 GB | 20 GB | 2 |
| Cockpit API (backend — DKE / KMS / KMIP endpoints) | 4 | 8 GB | 20 GB | 3 |
| DuoKey MPC KMS node (optional key-custody backend) | 4 | 8 GB | 20 GB | 3+ |
| PostgreSQL (Cockpit) | 4 | 16 GB | 100 GB | 3 |
| Redis cache | 4 | 8 GB | 50 GB | 3 |
| OpenBao (VM tier) | 2 | 4 GB | 50 GB | 3 |
| Monitoring — VictoriaMetrics | 8 | 16 GB | 200 GB | 1 |
| Logging — VictoriaLogs | 8 | 16 GB | 600–1000 GB | 1 |
The DKE, KMS and KMIP endpoints are all served by the Cockpit API. Key custody defaults to the built-in Software Vault; the DuoKey MPC KMS cluster and a Securosys HSM are optional external key-custody backends you can add when your deployment requires them. There is no third-party TSM and no message broker in the stack. See Key custody.
Sizing tiers by user count
The per-component resources above are derived from DuoKey's reference sizing. The user-count tiers below are indicative starting points to make planning easier — they are not a contractual mapping. Actual sizing depends on document activity and peak concurrency and is validated with DuoKey for your deployment.
The table below sizes the OpenShift application worker nodes (the pods above). It excludes the 3 control-plane nodes and the dedicated data/VM tier (PostgreSQL, OpenBao), which scale with the per-component table above.
| Tier | Users | App worker nodes | Per node | Notes |
|---|---|---|---|---|
| Pilot / PoC | ≤ 1,000 | 3 | 8 vCPU / 32 GB | Minimum HA, reduced replicas |
| Standard | ≤ 10,000 | 3–4 | 8 vCPU / 32 GB | Reference HA architecture |
| Large | ≤ 50,000 | 6 | 16 vCPU / 64 GB | Scaled-out replicas + HPA |
| Enterprise | 100,000+ | 8+ | 16 vCPU / 64 GB | Custom; typically multi-site |
- The Cockpit API is the hot path for DKE key wrap/unwrap and is CPU-bound during key operations — scale it first under heavy DKE load. If you have added a DuoKey MPC KMS cluster as your key-custody backend, its nodes are CPU-bound in the same way.
- PostgreSQL is used as a simple data store (no heavy queries), so it is RAM/IO-bound more than CPU-bound.
- Redis is a pass-through cache — modest CPU.
- Enable the HorizontalPodAutoscaler on the Cockpit API to absorb request spikes.
These figures are a safe starting point. Your DuoKey representative will refine them against your actual user population, document activity, peak concurrency, and availability targets (single-site vs multi-datacenter).
Software & operators
Install the following OpenShift Operators (via OperatorHub) before deployment:
- OpenShift GitOps (ArgoCD)
- External Secrets Operator (ESO)
- A PostgreSQL operator — CloudNativePG or Patroni (if running PostgreSQL in-cluster instead of on VMs)
- OpenShift Data Foundation (if using ODF for storage)
- Velero / OADP (OpenShift API for Data Protection) for backup
External software:
- OpenBao ≥ latest stable, configured with Raft integrated storage
- GitLab (self-hosted) or access to GitLab SaaS
- Redis ≥ 7 (sharded cluster) — in-cluster StatefulSet or on VMs
Network
Inter-datacenter latency & bandwidth (critical for PostgreSQL replication), NTP time synchronization, and the complete firewall flow matrix are covered in Network Requirements. The table below is the essential subset.
| Flow | Source | Destination | Port |
|---|---|---|---|
| User → app | Clients | Ingress Router | 443/TCP |
| App → secrets | Worker nodes | OpenBao VMs | 8200/TCP |
| App → database | Worker nodes | PostgreSQL primary/replicas | 5432/TCP |
| GitOps → source | ArgoCD | GitLab | 443/TCP, 22/TCP |
| Backup | Cluster / Velero | Object storage | 443/TCP |
| OpenBao → HSM (optional) | OpenBao VMs | HSM | per HSM vendor |
Requirements:
- Wildcard DNS record (e.g.
*.duokey.example.local) pointing at the Ingress Router VIP. - TLS certificates for the application hostname(s) — internal CA is fine for air-gapped sites.
- Recommended network segmentation: separate VLANs for application, secure (HSM), and backend/storage traffic.
- For air-gapped installs: a mirror registry (e.g. Quay / mirror.registry) for OpenShift release and operator images.
Key custody: vault backends
The Cockpit API manages keys through a configurable vault backend:
- Software Vault (default) — the built-in key-custody backend used out of the box; no external cluster or hardware to provision.
- DuoKey MPC KMS (optional) — DuoKey's own multi-party-computation cluster of 3 or more nodes. Each key is split into shares so no single node ever holds a complete key, and operations are computed jointly across the nodes. Deployed as part of your on-premise stack (your own DuoKey MPC nodes) and reached by the backend over OAuth2. Size the latency to and within the cluster — see Network Requirements.
- Securosys HSM (optional) — a hardware root of trust via PKCS#11 / KMIP, where policy or certification requires it. Provide network reachability from the backend to the Securosys HSM (or Securosys Cloud HSM) on a dedicated, hardened VLAN, plus the HSM client credentials / partition.
Add a DuoKey MPC KMS cluster or a Securosys HSM as your key-custody backend when your deployment has a specific hardware- or MPC-custody requirement; otherwise the built-in Software Vault covers on-premise deployments out of the box. Third-party TSM backends are not part of the on-premise deployment.
Access & skills
- Cluster-admin access to the OpenShift cluster.
- Administrative access to the VM hypervisor and DNS.
- Familiarity with
oc/kubectl, GitOps concepts, and OpenBao operations.
Once these are in place, continue to Installation.