For the complete documentation index, see llms.txt. This page is also available as Markdown.
High availability
Configure high availability for CARTO Self-hosted (Kots and Helm)
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:
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:
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).
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 and Configure an external in-memory cache.
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.
