This pattern makes every change to a cluster a reviewed pull request, and can even let Argo CD manage its own installation. It builds on [Set up Argo CD](/docs/hetzner/apalla/clusters/gitops/set-up-argo-cd). Like GitOps in general, it is one way to operate a cluster, not a requirement: you can still apply changes directly with `kubectl`.

## How a change reaches the nodes

Because a cluster is one declarative `Cluster` object, a change travels a single path from Git to running nodes:

1. Edit the `Cluster` manifest (or one of its topology values) in your repository and open a pull request.
2. A reviewer approves and merges it.
3. Argo CD syncs the change to the `Cluster` object in the management cluster.
4. Syself Autopilot reconciles the running cluster to match that object, rolling control-plane and worker nodes as needed.
5. The rollout completes on its own, with no imperative step from you.

## Adopt an existing cluster

As described in the [GitOps introduction](/docs/hetzner/apalla/clusters/gitops/overview), you can add your `Cluster` and `HetznerBareMetalMachine` manifests to your GitOps repository, and your GitOps operator will start managing them for you. If the manifests you add to the repository have the same names as those already in the Syself Autopilot management cluster, the operator will start managing them without recreating the resources.

## Reproducible clusters

The committed `Cluster` manifest is the full declaration of the cluster, so you can recreate the cluster by re-applying the file, in the same region or a new one. Keeping the manifest current in Git is what makes recovery a re-apply rather than a reconstruction.

## Reconcile the defaults Syself Autopilot fills in

When Syself Autopilot creates a cluster, it fills in default `spec.topology` variables. If you also manage the `Cluster` from Git, Argo CD sees those platform-set fields as a difference and may try to revert them, which causes sync thrash. Resolve it one of two ways:

- Copy the defaults from the live object (the Argo CD `DIFF` tab shows them) into your committed manifest, so Git and the cluster agree.
- Or leave them to the platform and tell Argo CD to ignore them with `ignoreDifferences` on the `Cluster` resource.

## Let Argo CD manage itself

The same process can be applied to the deployment of Argo CD or Flux themselves. If you haven't set up Argo CD yet, follow the [Set up Argo CD](/docs/hetzner/apalla/clusters/gitops/set-up-argo-cd) guide. For example, if you installed Argo CD via Helm, you can add this manifest to your GitOps repository:

```yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: argocd
  namespace: argocd
spec:
  project: default
  source:
    chart: argo-cd
    repoURL: https://argoproj.github.io/argo-helm
    targetRevision: v7.0.0
    helm:
      releaseName: argocd
  destination:
    name: "in-cluster"
    namespace: argocd
```

Now all your operations can be made from Git!

## Keep topology and app repositories separate

Keep your cluster-topology declarations in a different repository from your application manifests. A cluster change and an application change then review and roll out on their own tracks, and the blast radius of each pull request stays small.

## Related

- [Set up Argo CD](/docs/hetzner/apalla/clusters/gitops/set-up-argo-cd), install Argo CD and connect it to the management cluster
- [GitOps overview](/docs/hetzner/apalla/clusters/gitops/overview), why Git fits a whole cluster