[Ep.16] Tuning OpenShift GitOps for performance at scale

Wed, 15 Apr 2026 00:00:00 +0000

Argo CD is a powerhouse for GitOps. It is easy to get started with and helps you manage clusters and applications. As the number of clusters, applications, and repositories grows, performance can suffer: refreshes take longer, the UI may feel sluggish, and the experience turns frustrating.

This article is about performance tuning: which options exist, which scenarios matter, and which settings might help in your environment.

Introduction

GitOps has become a common way to manage configuration drift, and Argo CD is one of the most widely used tools for it. It keeps the desired state defined in Git aligned with what actually runs in the cluster. On Kubernetes you can use Argo CD to manage multiple clusters from a single management cluster (other topologies exist) and to synchronise multiple repositories. A typical pattern is two Argo CD instances: one for cluster configuration and one for application rollout (though many variants work).

What holds across setups is that Argo CD tends to slow down as its configuration grows and as the repositories it syncs from get larger and busier.

For example, imagine you have a single repository with thousands of commits. By default, Argo CD synchronises the whole repository, including the history. This is one screw that can be tightened.

Argo CD Components

Argo CD is made up of several cooperating components. In rough data-flow order, they are:

Repo Server: Connects to Git repositories, clones and syncs them, and generates manifests (for example with Helm or Kustomize). It uses Redis for caching.
Redis: Caches generated manifests and other data the other components reuse (default 24h).
Server: Exposes the API and UI; it reads from Redis to verify if it is still valid.
ApplicationSet Controller: Reconciles ApplicationSet resources and creates Application objects that the application controller picks up.
Application Controller: Reconciles desired state with live state in the cluster—creating, updating, and deleting resources as needed.

You may also see extra pods (for example Dex or a GitOps plugin). They are not central to the core sync path covered here; tuning them is mostly a matter of resources and replicas.

TL;DR: an overview

When starting with this article, I did not expect to fall down into the rabbit hole. The article became bigger and bigger and I am pretty sure that there will be settings that I missed, even though I search the actual source code.

If you find anything missing, please let me know. I am happy to add it.

The following overview table summarises the settings discussed in this article. Default and example recommended values are indicative—always validate in your environment. If you want a quick overview, start here.

Setting Default Recommended Standalone Argo CD OpenShift GitOps (ArgoCD CR)

Setting	Default	Recommended	Standalone Argo CD	OpenShift GitOps (ArgoCD CR)
Git shallow clone (depth)	Full history	1	Repository Secret with stringData.depth / data.depth (base64).	`apiVersion: v1 kind: Secret metadata: name: my-repo namespace: openshift-gitops labels: argocd.argoproj.io/secret-type: repository stringData: url: https://github.com/org/repo.git depth: "1" type: git type: Opaque`
ARGOCD_REPO_SERVER_PARALLELISM_LIMIT	0 (unlimited)	20 then tune (avoid OOM)	`argocd-cmd-params-cm` → reposerver.parallelism.limit, or env on `argocd-repo-server` Deployment.	`apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: openshift-gitops namespace: openshift-gitops spec: repo: env: - name: ARGOCD_REPO_SERVER_PARALLELISM_LIMIT value: "20"`
ARGOCD_GIT_LS_REMOTE_PARALLELISM_LIMIT	0 (unlimited)	20 when Git rate limits bite	Env on `argocd-repo-server` Deployment (or `argocd-cmd-params-cm` if your version maps it).	`apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: openshift-gitops namespace: openshift-gitops spec: repo: env: - name: ARGOCD_GIT_LS_REMOTE_PARALLELISM_LIMIT value: "20"`
ARGOCD_EXEC_TIMEOUT	90s	180s or higher for heavy Helm/Kustomize	Env on `argocd-repo-server` Deployment.	`spec: repo: env: - name: ARGOCD_EXEC_TIMEOUT value: 180s`
ARGOCD_EXEC_FATAL_TIMEOUT	10s	Leave default unless you change SIGTERM→SIGKILL grace	Env on `argocd-repo-server` Deployment.	`spec: repo: env: - name: ARGOCD_EXEC_FATAL_TIMEOUT value: 10s`
ARGOCD_GIT_ATTEMPTS_COUNT	1	3–5 on flaky networks	Env on `argocd-repo-server` Deployment.	`spec: repo: env: - name: ARGOCD_GIT_ATTEMPTS_COUNT value: "3"`
ARGOCD_REPO_CACHE_EXPIRATION	24h	Often keep 24h; shorten only with care	Env on `argocd-repo-server` Deployment.	`spec: repo: env: - name: ARGOCD_REPO_CACHE_EXPIRATION value: 24h`
ARGOCD_REVISION_CACHE_LOCK_TIMEOUT	10s	Raise if large charts hit lock timeouts (e.g. 30s)	Env on `argocd-repo-server` Deployment.	`spec: repo: env: - name: ARGOCD_REVISION_CACHE_LOCK_TIMEOUT value: 30s`
ARGOCD_SERVER_REPO_SERVER_TIMEOUT_SECONDS	60	Align with repo render time (e.g. 180)	Env on `argocd-server` Deployment.	`spec: server: env: - name: ARGOCD_SERVER_REPO_SERVER_TIMEOUT_SECONDS value: "180"`
Application Controller Sharding	Disabled / single replica	Enable for multi-cluster; algorithm + replicas	HA StatefulSet, argocd-cmd-params-cm controller.sharding.algorithm, ARGOCD_CONTROLLER_REPLICAS / ARGOCD_CONTROLLER_SHARD on pods.	`spec: controller: env: - name: ARGOCD_CONTROLLER_SHARDING_ALGORITHM value: round-robin sharding: enabled: true replicas: 3 minShards: 2 maxShards: 5`
timeout.reconciliation	3m	600s–3600s with webhooks	`argocd-cm` data.timeout.reconciliation.	`spec: extraConfig: timeout.reconciliation: 600s`
timeout.reconciliation.jitter	60s (if unset, controller default applies)	Keep a fraction of timeout.reconciliation (often tens of seconds); 0s = no random spread	`argocd-cm` data.timeout.reconciliation.jitter → env ARGOCD_RECONCILIATION_JITTER on the controller.	`spec: extraConfig: timeout.reconciliation: 600s timeout.reconciliation.jitter: 60s`
controller.status.processors	20	50–100 at large scale	`argocd-cmd-params-cm` controller.status.processors.	`spec: controller: processors: status: 50`
controller.operation.processors	10	Raise when the sync queue backs up	`argocd-cmd-params-cm` controller.operation.processors.	`spec: controller: processors: operation: 25`
ARGOCD_APPLICATION_CONTROLLER_REPO_SERVER_TIMEOUT_SECONDS + controller.repo.server.timeout.seconds	60	120–300 for slow manifest RPCs	`argocd-cmd-params-cm` controller.repo.server.timeout.seconds (or env ARGOCD_APPLICATION_CONTROLLER_REPO_SERVER_TIMEOUT_SECONDS on the controller).	`spec: controller: env: - name: ARGOCD_APPLICATION_CONTROLLER_REPO_SERVER_TIMEOUT_SECONDS value: "180"`
ARGOCD_APPLICATION_CONTROLLER_KUBECTL_PARALLELISM_LIMIT + controller.kubectl.parallelism.limit	20	Match or slightly below operation processors (e.g. 50)	`argocd-cmd-params-cm` controller.kubectl.parallelism.limit.	`spec: controller: env: - name: ARGOCD_APPLICATION_CONTROLLER_KUBECTL_PARALLELISM_LIMIT value: "50"`

Git shallow clone (depth)

Full history

Repository Secret with stringData.depth / data.depth (base64).

apiVersion: v1
kind: Secret
metadata:
name: my-repo
namespace: openshift-gitops
labels:
argocd.argoproj.io/secret-type: repository
stringData:
url: https://github.com/org/repo.git
depth: "1"
type: git
type: Opaque

ARGOCD_REPO_SERVER_PARALLELISM_LIMIT

0 (unlimited)

20 then tune (avoid OOM)

argocd-cmd-params-cm → reposerver.parallelism.limit, or env on argocd-repo-server Deployment.

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
name: openshift-gitops
namespace: openshift-gitops
spec:
repo:
env:
- name: ARGOCD_REPO_SERVER_PARALLELISM_LIMIT
value: "20"

ARGOCD_GIT_LS_REMOTE_PARALLELISM_LIMIT

0 (unlimited)

20 when Git rate limits bite

Env on argocd-repo-server Deployment (or argocd-cmd-params-cm if your version maps it).

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
name: openshift-gitops
namespace: openshift-gitops
spec:
repo:
env:
- name: ARGOCD_GIT_LS_REMOTE_PARALLELISM_LIMIT
value: "20"

ARGOCD_EXEC_TIMEOUT

90s

180s or higher for heavy Helm/Kustomize