> For the complete documentation index, see [llms.txt](https://docs.carto.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.carto.com/carto-self-hosted/configuration/performance-ha/high-availability.md).

# High availability

This guide details configuring High Availability (HA) for CARTO Self-Hosted deployments on Kubernetes. HA ensures continuous service during pod or node failures by running multiple replicas of the components that are critical to the platform. Configure it through the **Admin Console** (Kots) or through your `customizations.yaml` (Helm).

## Kots

### Enabling high availability mode

To enable the high availability configuration on your CARTO Self-Hosted deployment, you'll have to check the following option in your configuration:

<figure><img src="/files/ZxKpmLbH8Rkyy603bw6R" alt=""><figcaption></figcaption></figure>

This change will enable the default options for high availability on your Self-Hosted installation, and we'll deploy multiple replicas for the services that are considered critical for CARTO platform's usage.

### Customize your high availability options

In case you'd like to customize the high availability configuration, these are the available options:

<figure><img src="/files/XrRFIVVDIbuUS9iah99g" alt=""><figcaption></figcaption></figure>

#### Number of replicas for critical components:

* **Minimum Number of Replicas:** This setting determines the minimum number of copies of each CARTO service running at any given time. Increasing this value enhances fault tolerance by providing more replicas to handle requests during failures. The default value is 2.
* **Maximum Number of Replicas:** This setting defines the upper limit on the number of replicas for each service. This allows you to scale your deployment up or down based on usage. The default value is 3.

## Helm

For Helm-based deployments the same high-availability principles apply, but (unlike the Admin Console's single "high availability" toggle) replicas are configured **per component** in your `customizations.yaml`:

* For each critical component, set `<component>.replicaCount`, or enable autoscaling with `<component>.autoscaling.enabled: true` and `<component>.autoscaling.minReplicas` / `maxReplicas` (e.g. `mapsApi.autoscaling.minReplicas`, `workspaceApi.autoscaling.minReplicas`).

For the full list of components and their values, see [Advanced Helm customizations](/carto-self-hosted/reference/advanced-helm-customizations.md).

## Limitations and dependencies

* **Stateful dependencies provide their own HA.** CARTO's replica settings don't make the metadata database or the in-memory cache highly available. That comes from running them as **external, managed, highly-available services** (for example a multi-AZ managed PostgreSQL, and a managed Redis/Valkey with Sentinel or Cluster). See [Metadata Database](/carto-self-hosted/planning/prerequisites/metadata-database.md) and [Configure an external in-memory cache](/carto-self-hosted/configuration/data-and-storage/configure-an-external-in-memory-cache.md).
* **Node spreading:** when HA is enabled in the Admin Console, CARTO automatically spreads each critical component's replicas across nodes (pod anti-affinity). With Helm you configure affinity / topology spread yourself.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.carto.com/carto-self-hosted/configuration/performance-ha/high-availability.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.