> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/harness-cloud-operations/harness_saas_architecture.md).
# Harness SaaS Architecture
Click to view full size image
This diagram provides a high-level overview of Harness SaaS infrastructure. It runs across two regions, **us-west1** and **us-west2**, for fault tolerance. The core infrastructure contains two Kubernetes clusters: a primary cluster and a failover cluster. The failover cluster runs all Harness services with zero pods. This configuration enables rapid application recovery during a regional outage. During an outage in Google Cloud Platform (GCP) **us-west1** or one of its zones, pods in the **us-west2** failover cluster scale up. Traffic can then move to **us-west2** in about 20 to 25 minutes.
Both clusters connect to GCP managed data services for persistent storage and other data services. Additionally, they connect to a few non-GCP managed data services, such as MongoDB Atlas and Managed Timescale DB, which are VPC-peered with the GCP project to minimize network latency and enhanced security.
Click to view full size image
This diagram provides a detailed view of the Harness SaaS primary cluster. Clients, including automation tools, Harness users, and Harness agents, make Secure Sockets Layer (SSL) requests to \*.harness.io. Cloud DNS resolves this hostname to the Google Cloud load balancer (GCLB) IP address. The load balancer routes requests to Cloud CDN for static content and delegate JARs, or to the primary Kubernetes cluster in **us-west1**.
Cloud Armor provides an additional layer of security by protecting against DDoS attacks and enforcing Web Application Firewall (WAF) rules. SSL termination also occurs at the GCLB.
The primary Kubernetes cluster is divided into 3 logical clusters (**Prod1**, **Prod2**, and **Prod3**). Harness customer accounts are distributed across these 3 logical clusters to achieve scalability, reduce the blast radius of releases, and adhere to compliance requirements. Each logical cluster has its own set of Harness services and data stores. Releases typically follow a staged approach, starting with Prod1, then Prod2 after a day, and finally Prod3 after a week.
Harness uses a microservices architecture. Requests route to the appropriate microservices through the NGINX Ingress Controller. Prod3 uses a dedicated ingress controller. Prod1 and Prod2 share a separate ingress controller. The Gateway Service routes requests to Prod1 or Prod2 based on the account identifier. Prod3 has its own Gateway Service.