Self-managed GitOps

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 . 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 , 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 guide. For example, if you installed Argo CD via Helm, you can add this manifest to your GitOps repository:

		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 , install Argo CD and connect it to the management cluster
• GitOps overview , why Git fits a whole cluster