DuoKey On-Premise on OpenShift
Deploy the complete DuoKey platform inside your own datacenter, running on Red Hat OpenShift. This deployment model gives organizations with strict data residency, sovereignty, or air-gap requirements full control over their key management infrastructure — without giving up the high availability and operational maturity of a cloud deployment.
Platform engineers, OpenShift/Kubernetes administrators, and security teams who are responsible for installing and operating DuoKey on infrastructure they own and manage.
Why deploy on-premise?
| Driver | What you get |
|---|---|
| Data sovereignty | All cryptographic material and metadata stay within your physical perimeter. Nothing leaves your network. |
| Regulatory compliance | Meet residency mandates (e.g. FINMA, GDPR, national-security frameworks) that require data to remain in-country or on-site. |
| Air-gap capable | The reference architecture can run fully disconnected from the public internet. |
| Full control | You own the upgrade cadence, the backup policy, the hardware, and the network boundary. |
| No cloud lock-in | Standard OpenShift workloads — portable across any OpenShift footprint (bare metal, OpenStack, VMware, or a managed on-prem cluster). |
What gets deployed
A production DuoKey on-premise deployment is a hybrid of containerized workloads on OpenShift and a small set of dedicated, hardened virtual machines for the most sensitive stateful components.
A hybrid of containerized workloads on OpenShift and a small set of hardened VMs for the most sensitive stateful components, rooted in DuoKey key custody.
| Layer | Components | Runs on |
|---|---|---|
| Application | Cockpit frontend, API backend | OpenShift pods |
| Delivery | OpenShift GitOps (ArgoCD), GitLab | ArgoCD in-cluster; GitLab on a VM |
| Secrets | OpenBao (HA, Raft consensus), optional HSM | Dedicated VMs |
| Data | PostgreSQL (HA), Redis cache | VMs / StatefulSets |
| Observability | VictoriaMetrics, VictoriaLogs, Grafana | OpenShift pods |
| Backup / DR | Velero, object storage, off-site replication | In-cluster + object store |
Key characteristics
- Highly available by design — frontend and backend pods use pod anti-affinity to spread across worker nodes and availability zones; OpenBao and PostgreSQL run in clustered, replicated configurations.
- GitOps-driven — every change to application manifests is reconciled automatically by ArgoCD, giving you a fully auditable, declarative deployment.
- Secrets never touch disk — credentials are fetched from OpenBao on demand
and injected into in-memory (
tmpfs) volumes; no raw secret is ever written to cluster storage or committed to Git. - Disaster-recovery ready — automated, encrypted backups with an off-site / secondary-site restore procedure.
How to use this guide
Work through the sections in order:
- Architecture — understand the reference design and how the pieces fit together.
- Prerequisites — size your hardware, network, and OpenShift cluster (incl. DKE sizing by user count).
- DNS Records — create the internal and external records (incl. the DKE endpoint).
- Container Images & Harbor Registry — get the DuoKey images (and mirror them for air-gap).
- Installation — deploy DuoKey step by step.
- Cockpit Configuration — set the environment variables (DB, URLs, secrets, DKE) — stored in OpenBao, injected at deploy.
- Security — integrate and lock down the deployment:
- Secret Manager Integration — Software Vault, DuoKey MPC KMS, Securosys HSM, OpenBao
- Identity, SSO & Access Control — OIDC, MFA, RBAC
- Network Security — firewall, WAF, load balancer, mTLS
- Platform Hardening — SCC, etcd encryption, FIPS, CIS/STIG
- Compliance & Audit — SIEM, retention, frameworks
- Operations — run and protect the deployment:
- Release Notes — version tags, image digests, and what changed.
Every on-premise deployment is reviewed with DuoKey engineering. Contact your DuoKey representative or [email protected] to plan your rollout.