Skip to main content
GitOps tools (Argo CD, Flux) wrap the same Helm chart described in Install with Helm. The values are identical — the only difference is that the chart is rendered and applied by a controller running in your cluster, with desired state stored in Git instead of in your local shell.
The chart is distributed through a private registry. Your GitOps controller needs a token to pull it — request an access token from the Tensormesh team and store it as a registry credential your controller references (shown in each example below). When authenticating with a token the username field can be any non-empty value.

​
Argo CD

First register the registry credentials Tensormesh gave you (one-time), then add an Application that pulls the chart over OCI:
registry-creds.yaml
# Argo CD repo-credential for the private registry. Uses the username + token from Tensormesh.
apiVersion: v1
kind: Secret
metadata:
  name: tensormesh-registry
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repo-creds
stringData:
  type: helm
  enableOCI: "true"
  url: ghcr.io/tensormesh-production/charts
  username: tensormesh                  # any non-empty value works with a token
  password: <TOKEN_FROM_TENSORMESH>
application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tensormesh-operator
  namespace: argocd
spec:
  project: default
  source:
    repoURL: ghcr.io/tensormesh-production/charts   # OCI registry host + path
    chart: tensormesh-operator
    targetRevision: 0.1.0                            # pin the chart version
    helm:
      releaseName: tensormesh-operator
      values: |
        operator:
          replicas: 1
        engine:
          enabled: true
          spec:
            l1:
              sizeGB: 60
        openshift:
          enabled: false             # set true on OpenShift clusters
  destination:
    server: https://kubernetes.default.svc
    namespace: tensormesh-operator
  syncPolicy:
    syncOptions:
      - CreateNamespace=true
      - ServerSideApply=true
    automated:
      prune: true
      selfHeal: true

​
CRD ordering

The LMCacheEngine CRD ships inside the chart’s templates/ directory and is annotated with Helm’s InstallOrder so it is applied before any CR. Argo CD respects the same annotation by default, so a fresh install converges in one sync. If you split the chart into multiple Applications (for example, CRDs in one, operator in another), use Argo CD sync waves to enforce ordering: 
metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "-1"   # CRD app

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "0"    # operator + engine app

​
Flux

Create a registry secret from the Tensormesh credentials, then point an OCI HelmRepository at it: 
# One-time: store the credentials Tensormesh gave you as a registry secret.
kubectl create secret docker-registry tensormesh-registry \
  -n flux-system \
  --docker-server=ghcr.io \
  --docker-username='tensormesh' \
  --docker-password='<TOKEN_FROM_TENSORMESH>'
flux.yaml
---
apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
  name: tensormesh
  namespace: flux-system
spec:
  type: oci
  interval: 1h
  url: oci://ghcr.io/tensormesh-production/charts
  secretRef:
    name: tensormesh-registry
---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: tensormesh-operator
  namespace: tensormesh-operator
spec:
  interval: 10m
  chart:
    spec:
      chart: tensormesh-operator
      version: 0.1.0
      sourceRef:
        kind: HelmRepository
        name: tensormesh
        namespace: flux-system
  install:
    createNamespace: true
  values:
    operator:
      replicas: 1
    engine:
      enabled: true
      spec:
        l1:
          sizeGB: 60
    openshift:
      enabled: false

​
Multi-cluster

For fleets, use Argo CD ApplicationSets (or Flux Kustomizations) to roll the same release across many clusters with per-cluster overrides: 
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: tensormesh-operator
  namespace: argocd
spec:
  generators:
    - clusters: {}                  # all registered clusters
  template:
    metadata:
      name: 'tensormesh-operator-{{name}}'
    spec:
      project: default
      source:
        repoURL: ghcr.io/tensormesh-production/charts   # requires the repo-creds Secret above
        chart: tensormesh-operator
        targetRevision: 0.1.0
        helm:
          values: |
            engine:
              spec:
                l1:
                  sizeGB: 60
            openshift:
              enabled: {{metadata.labels.openshift}}
      destination:
        server: '{{server}}'
        namespace: tensormesh-operator
      syncPolicy:
        syncOptions: [CreateNamespace=true]
        automated: { prune: true, selfHeal: true }
Label your registered clusters with what they are (openshift=true, gpu=a100, etc.) so the ApplicationSet template can branch on them.

​
Verifying a GitOps install

The verification steps in Install with Helm all apply unchanged — Argo CD and Flux ultimately invoke the same Helm render, so the live resources look identical to a helm install.

​
Trade-offs

GitOps is best when:
  • Desired state must live in version control (audit, code review on every change).
  • The same release needs to roll out to many clusters consistently.
  • You want self-healing — drift gets reverted automatically.
Plain helm install is faster for one-off clusters, lab environments, and the initial spike before you formalize a GitOps workflow.

​
Next steps

Helm install reference

Every chart value the GitOps manifests above can override.

OpenShift

Set openshift.enabled: true in your Application for OpenShift targets.