• June 06 2026

CyberArk Secrets Manager Self-Hosted (Conjur Enterprise) – Complete Architecture, Deployment, HA, DR & Best Practices Guide 2026

📦 What is CyberArk Secrets Manager Self-Hosted?

CyberArk Secrets Manager Self-Hosted (previously known as Conjur Enterprise) is CyberArk's enterprise-grade secrets management platform designed for DevOps, Cloud, Kubernetes, CI/CD pipelines, applications, containers, and Infrastructure-as-Code (IaC) environments.

Modern applications require access to thousands of secrets such as:

▢ Database passwords

▢ API keys

▢ SSH keys

▢ Cloud credentials

▢ Service account passwords

▢ Certificates

▢ Encryption keys

Managing these secrets manually creates significant security risks. CyberArk Secrets Manager Self-Hosted provides a centralized platform to securely store, manage, rotate, audit, and distribute secrets across hybrid and multi-cloud environments.

Organizations can accelerate DevOps adoption while maintaining compliance, security, and complete visibility into secret usage.

---

📦 Why Organizations Need Secrets Management

In traditional environments, credentials are often stored in:

▢ Application configuration files

▢ Source code repositories

▢ Shell scripts

▢ CI/CD pipelines

▢ Environment variables

▢ Shared documents

This creates major attack surfaces for cybercriminals.

CyberArk Secrets Manager eliminates these risks by:

▢ Centralizing secret storage

▢ Enforcing least privilege access

▢ Providing detailed auditing

▢ Supporting automated secret retrieval

▢ Integrating with Kubernetes and DevOps tools

▢ Supporting cloud-native applications

---

📦 CyberArk Secrets Manager vs CyberArk Vault

Many CyberArk professionals confuse Secrets Manager with the traditional CyberArk Digital Vault.

The traditional Vault primarily secures privileged accounts for human users and administrators.

Secrets Manager focuses on securing machine identities and application secrets.

For a deeper understanding of the Vault architecture, read:

🔗 What is CyberArk Vault

🔗 CyberArk Vault Deep Dive Architecture

---

📦 Key Features of CyberArk Secrets Manager Self-Hosted

High Availability Architecture

▢ Leader-Standby-Follower architecture

▢ Automatic failover support

▢ Manual failover support

▢ PostgreSQL streaming replication

▢ Synchronous replication

▢ Asynchronous replication

▢ Multi-data center deployment

▢ Disaster Recovery support

---

Security Features

▢ Mutual TLS Authentication

▢ Server key encryption

▢ HSM Integration

▢ AWS KMS Integration

▢ Fine-grained access control

▢ Policy-based authorization

▢ Complete audit trail

---

Enterprise Integrations

▢ Active Directory Integration

▢ LDAP Integration

▢ SIEM Integration

▢ Kubernetes Integration

▢ Jenkins Integration

▢ GitLab Integration

▢ Azure DevOps Integration

▢ CyberArk PAS Integration

---

Scalability Features

▢ Horizontal scaling using Followers

▢ Multiple regional deployments

▢ Auto-scaling support

▢ Low-latency secret retrieval

---

📦 Secrets Manager Architecture Overview

CyberArk Secrets Manager follows a highly available Leader-Standby-Follower architecture.

                    +----------------+
                    | Load Balancer  |
                    +--------+-------+
                             |
                +------------+------------+
                |                         |
        +-------+-------+         +-------+-------+
        |   Leader      |         |   Standby     |
        +---------------+         +---------------+
                |
                |
        +-------+-------+
        |   Standby     |
        +---------------+

                |
         Followers Cluster
                |
      +---------+----------+
      |                    |
+-----------+      +-----------+
| Follower1 |      | Follower2 |
+-----------+      +-----------+

---

📦 Core Components Explained

1. Leader

The Leader is the central node of the Secrets Manager environment.

Responsibilities:

▢ Policy updates

▢ Secret creation

▢ Secret modifications

▢ User management

▢ Audit processing

▢ Write operations

There can only be one active Leader at any given time.

---

2. Standby

A Standby is an exact replica of the Leader.

Functions:

▢ Receives database replication

▢ Maintains synchronization

▢ Ready to become Leader

▢ Supports HA deployments

If the Leader fails, a Standby can be promoted automatically or manually.

---

3. Follower

Followers provide read-only access to applications.

Responsibilities:

▢ Authentication

▢ Authorization

▢ Secret retrieval

▢ Read scaling

Followers cannot perform write operations.

Attempting to write through a Follower results in an error.

---

📦 Replication Architecture

Replication is one of the most important concepts in Secrets Manager.

---

Synchronous Replication

In synchronous replication:

▢ Leader writes data

▢ Standby receives data immediately

▢ Transaction completes only after both nodes update

Benefits:

▢ Zero data loss

▢ Consistent database state

▢ Immediate failover readiness

CyberArk recommends having one synchronous Standby.

---

Asynchronous Replication

In asynchronous replication:

▢ Leader commits transaction first

▢ Replication occurs later

▢ Small delays may occur

Benefits:

▢ Better performance

▢ Geographic distribution

▢ Reduced latency

---

Follower Replication

Followers receive data asynchronously.

Characteristics:

▢ Read-only nodes

▢ Horizontally scalable

▢ Application-facing

▢ Low latency

▢ Global deployment support

---

📦 Auto-Failover Architecture

Secrets Manager supports automatic failover using:

▢ etcd

▢ Raft Consensus Algorithm

When Leader becomes unavailable:

▢ Cluster health is evaluated

▢ Standbys communicate via etcd

▢ Most up-to-date Standby is selected

▢ New Leader is promoted automatically

This minimizes downtime and maintains business continuity.

---

📦 Manual Failover

Organizations can also choose manual failover.

Advantages:

▢ Greater administrative control

▢ Suitable for regulated environments

▢ Simpler architecture

Disadvantages:

▢ Requires human intervention

▢ Longer recovery time

---

📦 Disaster Recovery Architecture

CyberArk recommends deploying DR Standbys in separate regions.

Example:

Primary Region

▢ Leader

▢ Sync Standby

▢ Async Standby

DR Region

▢ DR Standby

Benefits:

▢ Regional disaster protection

▢ Business continuity

▢ Data recovery capability

If an entire region fails, DR Standby can be manually promoted.

For additional HA and DR concepts, read:

🔗 CyberArk Primary DR Vault Environment

🔗 CyberArk Distributed Vault Environment

🔗 Learn about CyberArk Digital Vault Cluster Environment

---

📦 Production Deployment Layout

CyberArk recommends:

Cluster Layer

▢ 1 Leader

▢ 2 Standbys

Application Layer

▢ Minimum 2 Followers per Data Center

Load Balancers

▢ Cluster Load Balancer

▢ Follower Load Balancer

This architecture provides:

▢ High Availability

▢ Scalability

▢ Disaster Recovery

▢ Fault Tolerance

---

📦 Staging Environment Layout

Minimum recommended deployment:

▢ 1 Leader

▢ 1 Standby

▢ 1 Follower

▢ 2 Load Balancers

This setup closely resembles production environments and supports testing activities.

---

📦 Data Segregation Per Follower

By default:

▢ All secrets replicate to every Follower

Organizations can improve security by using replication sets.

Example:

India Region

▢ India-related secrets only

Europe Region

▢ Europe-related secrets only

US Region

▢ US-related secrets only

Benefits:

▢ Reduced risk

▢ Better compliance

▢ Regional data isolation

▢ Lower attack surface

---

📦 Load Balancer Requirements

CyberArk strongly recommends Layer-4 Load Balancers.

Supported Examples:

▢ F5

▢ AWS ELB

▢ HAProxy

▢ NGINX TCP Load Balancing

Requirements:

▢ Preserve source IP

▢ Health check support

▢ TLS pass-through

▢ Route traffic only to active Leader

---

📦 Port Requirements

Leader and Standby

▢ 443 – UI/API Access

▢ 444 – Health Check

▢ 5432 – PostgreSQL Replication

▢ 1999 – Audit Stream

▢ 22 – Administrative Access

---

Follower

▢ 443 – UI/API

▢ 444 – Health Check

▢ 22 – Administrative Access

---

📦 Server Key Encryption

By default, server keys reside on local nodes.

CyberArk recommends protecting them using:

AWS KMS

▢ Centralized key management

▢ Automated decryption

▢ Cloud-native protection

---

HSM

▢ Hardware-based protection

▢ Strong cryptographic security

▢ Compliance support

---

📦 Audit and Compliance

Secrets Manager records all activities.

Audit locations:

▢ audit.json

▢ audit.log

▢ Audit Database

Audited activities include:

▢ Secret retrieval

▢ Policy changes

▢ Authentication requests

▢ Authorization requests

▢ Administrative actions

CyberArk recommends forwarding audits to enterprise SIEM platforms.

Supported integrations include:

▢ Splunk

▢ QRadar

▢ ArcSight

▢ Sentinel

---

📦 System Requirements

Production Environment

Leader & Standby

▢ 4 CPU Cores

▢ 16 GB RAM

▢ 50 GB Storage

▢ SSD for Auto-Failover

Followers

▢ 4 CPU Cores

▢ 16 GB RAM

▢ 50 GB Storage

---

Development Environment

Leader & Standby

▢ 2 CPU Cores

▢ 4 GB RAM

▢ 20 GB Storage

Followers

▢ 2 CPU Cores

▢ 4 GB RAM

▢ 20 GB Storage

---

📦 Container Platform Support

CyberArk Secrets Manager supports:

▢ Docker

▢ Podman

▢ Kubernetes (Followers only)

▢ OpenShift (Followers only)

Important:

Leader and Standby nodes cannot run on Kubernetes.

Only Followers are supported on Kubernetes/OpenShift platforms.

---

📦 Certificates Requirements

CyberArk strongly recommends third-party certificates in production.

Required certificate attributes:

▢ Common Name (CN)

▢ Subject Alternative Names (SAN)

▢ Client Authentication

▢ Server Authentication

▢ Digital Signature

▢ Key Encipherment

Self-signed certificates should only be used for:

▢ Development

▢ Testing

▢ Proof-of-Concept environments

---

📦 Evoke Utility

The Evoke utility is the primary administration tool.

Functions include:

▢ Configure Leader

▢ Configure Standby

▢ Configure Follower

▢ Generate Seed Files

▢ Backup Secrets Manager

▢ Restore Secrets Manager

▢ Configure Auto-Failover

▢ Manage Replication Sets

▢ Encrypt Server Keys

▢ Decrypt Server Keys

The Evoke utility is installed on every Secrets Manager node.

---

📦 Integration with CyberArk PAS

One of the most powerful capabilities is integration with CyberArk Privileged Access Manager.

Benefits:

▢ Automatic secret synchronization

▢ Vault-to-Conjur replication

▢ Unified secret governance

▢ Reduced operational effort

This allows organizations to leverage existing privileged credentials already managed inside CyberArk.

If you are new to CyberArk, start with:

🔗 CyberArk Tutorial for Beginners

---

📦 Best Practices

▢ Deploy minimum 1 Leader and 2 Standbys

▢ Configure one synchronous Standby

▢ Deploy Followers near applications

▢ Use Layer-4 load balancers

▢ Enable audit forwarding to SIEM

▢ Use HSM or AWS KMS

▢ Use third-party certificates

▢ Implement disaster recovery Standbys

▢ Regularly perform evoke backups

▢ Test failover procedures periodically

---

Final Thoughts

CyberArk Secrets Manager Self-Hosted is one of the most powerful enterprise secrets management solutions available today. Its Leader-Standby-Follower architecture provides exceptional scalability, security, and resilience for modern DevOps and cloud-native environments.

With features such as auto-failover, disaster recovery, replication sets, HSM/KMS integration, Kubernetes support, and CyberArk PAS integration, organizations can securely manage machine identities and secrets at enterprise scale.

For professionals looking to master CyberArk Conjur and Secrets Manager technologies, practical hands-on training is essential.

🎓 CyberArk Conjur Self Paced Training

🎓 CyberArk Full Training – SecApps Learning

Mastering Secrets Manager today will prepare you for the growing demand for DevSecOps, cloud security, Zero Trust, and machine identity management roles in 2026 and beyond.