There are two options for Hybrid GitOps Runtime installation via Helm, each catering to specific use cases:

* **Clean cluster installation with only GitOps**

The _clean cluster_ installation option is suitable for environments where you want to deploy the GitOps Runtime on a cluster without Argo CD.

* **Cluster with existing Argo CD**

If you have a cluster with Argo CD already installed, you can extend it with Codefresh's GitOps capabilities.

| Prerequisite | GitOps only | GitOps with Argo CD |

|------------------------------------- |:------------: |:-------------: |

| [Set native Argo CD resource tracking to `label](#gitops-with-argo-cd-set-native-argo-cd-resource-tracking-to-label) | N/A | ✅ |

`--set <argo-project>.crds.install=false`<br>

where:<br>

See [Argo's readme on Helm charts](https://github.com/argoproj/argo-helm/blob/main/README.md){:target="\_blank"}.

To avoid potentially incompatible changes or mismatches, ensure that the native Argo CD instance uses the same upstream version of Argo CD as that used by Codefresh.

* [ArtifactHub](https://artifacthub.io/packages/helm/codefresh-gitops-runtime/gitops-runtime){:target="\_blank"}:

{% include

max-width="60%"

%}

{% include

image.html

* For GitOps installation with Argo CD, verify the following:

* [Minor version of Argo CD's Helm chart](#side-by-side-gitops-minor-versions) is identical to the version used by Codefresh

* [Native Argo CD's resource tracking is set to `label`](#side-by-side-gitops-set-native-argo-cd-resource-tracking-to-label)

* For ingress-based runtimes only, verify that these ingress controllers are configured correctly:

* [Ambassador ingress configuration](#ambassador-ingress-configuration)

* [AWS ALB ingress configuration](#aws-alb-ingress-configuration)

**Shared Configuration Repository**

The [Shared Configuration Repository]({{site.baseurl}}/docs/installation/gitops/shared-configuration/) is a Git repository with configuration manifests shared between all the Hybrid GitOps Runtimes within the same account. Codefresh identifies the Git provider from the URL of the Shared Configuration Repo, and for cloud providers, automatically populates the Git Provider and the API URL fields.

On-premises Git providers require you to define the API URL:

* GitHub Enterprise: `https://<server-url>/api/v3`

* GitLab Server: `<server-url>/api/v4`

{% include

image.html

lightbox="true"

max-width="40%"

%}

Before initiating the installation, Codefresh automatically validates the `values.yaml` file to verify that the supplied values are correct.<br>

If the Helm installation is terminated with the error message: `Job has reached the specified backoff limit`, get more detailed information on the reason for the validation failure with:

`kubectl logs jobs/validate-values -n ${NAMESPACE}`, replacing `{NAMESPACE}` with the namespace of the Hybrid GitOps Runtime.

**Runtime Name**

If you define a custom name for the Hybrid GitOps Runtime, it must start with a lower-case character, and can include up to 62 lower-case characters and numbers.

**GitOps with Argo CD and Argo Rollouts**

* `fullnameOverride` configuration for resource conflicts

Installing GitOps Runtime on the same cluster as Argo CD can cause conflicts when resources in both native and Codefresh's Argo CD instances have the same name or attempt to control the same objects.

* Resource tracking with `annotation`

Installing GitOps Runtime on the same cluster as Argo CD require that each Argo CD instance uses different methods to track resources. Using the same tracking method can result in conflicts when both instances have applications with the same names or when tracking the same resource. Setting the GitOps Runtime's Argo CD resource tracking to `annotation` prevents such conflicts.