Single Node vs High Availability

After choosing your installation method, decide whether to run a single node or high availability (HA).

When To Use This Page

Use this page after choosing an installation method and before production sizing or infrastructure provisioning.

Comparison

	Single Node	High Availability
Use case	Evaluation, dev, small teams	Production, mission-critical
Nodes	1	2+ (3+ recommended)
Database	Bundled or external	External PostgreSQL required
Storage	Local PVC	Shared object storage (S3, GCS, Azure Blob)
Failover	None — manual recovery	Automatic
Downtime for maintenance	Yes	No — rolling updates
Horizontal scaling	No	Yes

HA Requirements

To run High Availability, you need:

External database — Managed PostgreSQL (AWS RDS, Azure Database for PostgreSQL, or Google Cloud SQL)
Shared object storage — S3, GCS, or Azure Blob so all nodes share binaries
Load balancer — Ingress (Kubernetes) or Route (OpenShift) with health checks
Multiple replicas — artifactory.artifactory.replicaCount of 2+ (3+ recommended)
Shared keys — Master Key and Join Key in Kubernetes Secrets

📘
Migration Path
You can start with a single-node deployment and migrate to HA later by adding an external database, shared storage, and additional replicas. See High Availability Planning.

Practical Decision Thresholds

Use these thresholds as a quick decision aid:

Signal	Start with Single Node	Start with HA
Availability target	Non-critical workloads	Strict uptime/SLA targets
Team size / usage	Small team, low concurrency	Multiple teams, sustained parallel CI/CD usage
Operational model	Evaluation or short-lived environments	Long-lived production with planned maintenance windows
Recovery tolerance	Manual recovery acceptable	Automatic failover required

Next Steps

Plan implementation details in High Availability Planning
Continue workload and infrastructure sizing in Capacity Planning