Redis backend options for active-active Harbor deployment using Helm chart

[srbhklkrn]

Hi Harbor team,

We're in the process of deploying Harbor in an active-active setup across two data centers, using the official Helm chart. Our goal is to run two Harbor frontends sharing a common backend that includes:

• An external PostgreSQL database with high availability
• ECS S3 for image/chart storage
• And a shared HA Redis backend

We’ve hit a blocker around the Redis setup.

From the Helm chart defaults Harbor components are configured to use multiple Redis databases (e.g. DB 0 for core, DB 1 for jobservice, DB 2 for registry, DB 5 for trivy). However, we’re evaluating two options:

• Open-source Redis: Supports multiple DBs but lacks built-in high availability (HA)
• Enterprise Redis (HA): Supports HA but only provides a single DB index (usually DB 0)

Questions:

1. Can Harbor components safely share a single Redis DB in this type of deployment, or does it require multiple isolated DB indexes for correct behavior?
2. What are the risks or limitations of running all components on the same Redis DB (e.g., key collisions, performance bottlenecks)?
3. Are there any known or recommended strategies for deploying Harbor with HA Redis backends that only support a single DB?
4. Is Redis Sentinel or Redis Cluster support officially planned or supported in the Harbor Helm chart?

We intend to share the same backend between both Harbor frontends to ensure consistency, reliability, and full visibility across deployments.

Thanks in advance for your guidance!

[MinerYang]

Hi @srbhklkrn ,

Thanks for connecting with us. Before answering everything I want to make sure that I understood your use case correctly.

• You want deploy two Harbor instance that using a shared Postgres and a redis service.
• Harbor do support redis-sentinel natively to achieve the redis HA. But we don't recommended to using a single DB for all components since some of the operation accuracy may not been guaranteed as long as the performance of the service would be affect.
• If your enterprise redis is not using the sentinel mode to achieve the HA ? Then which mechanism or mode they are used for? Could you help us to get more background here?

Best,
Miner

[srbhklkrn]

Hi @MinerYang,

Thanks for the response. Let me clarify the setup and the reasoning behind our approach:

Yes, we are looking to deploy two Harbor instances (registry, portal, and core) across multiple datacenters. Both instances will connect to a shared HA PostgreSQL database, which is set up with cross-DC replication for high availability, and a shared enterprise Redis, also configured across the same two datacenters.

You're right, open-source Redis supports Sentinel-based HA. However, in our enterprise setup, we need a geo-distributed Redis deployment that continues to function even if one region or datacenter goes down. Our enterprise Redis uses CRDT (Conflict-Free Replicated Data Types) to allow active-active writes from multiple locations while ensuring consistency something Sentinel mode does not support out of the box.

The Harbor Helm chart uses open-source Redis with Sentinel mode, which works fine for single-DC deployments. But in our case, deploying Harbor in just one Kubernetes cluster in a single datacenter creates a risk of downtime. We need Harbor components to be distributed across multiple clusters and datacenters, so that one site can take over if the other becomes unavailable.

You might suggest running Harbor in two different clusters and enabling replication between them. In fact, that's our current setup—an active-passive model with replication across Harbor instances. However, managing per-project replication at scale (we have hundreds of projects) has become difficult and error-prone. We're trying to simplify the architecture by moving away from replication altogether and using shared backend services (PostgreSQL and Redis) so Harbor behaves like a single logical instance, even if deployed across multiple clusters.

Let me know if this makes sense, or if you need any further details.