GitOps for Telecom: ArgoCD Patterns for 5G Deployments

Telecom change management was built around CABs, MOPs, and signed-off Excel sheets. GitOps does not replace that culture — it gives it a substrate. Every change is a commit. Every rollback is a revert. The audit trail writes itself.

This is how operators are running 5G cores under ArgoCD in 2026.

Why GitOps fits telecom

Three reasons:

1. Auditability. Regulators and internal compliance want to know who changed what, when, and why. Git gives you that for free — commit author, timestamp, signed commit, PR with reviewer approval.
2. Drift detection. A 5G core with 9 NFs across 5 regions has a state space too large to track manually. ArgoCD continuously reconciles cluster state against Git and tells you when they diverge.
3. Disaster recovery. The cluster is the cache. Git is the source of truth. Lose a cluster, rebuild from Git in hours.

Repository layout

The pattern that holds up at scale:

telco-gitops/
  apps/                          # ArgoCD Application manifests
    root.yaml                    # app-of-apps root
    eu-west-1/
      5gc.yaml
      monitoring.yaml
      cnf-infra.yaml
    us-east-1/
      5gc.yaml
      ...
  charts/                        # Helm charts (or git submodule)
    5gc/
  values/                        # per-environment overlays
    eu-west-1/
      5gc-values.yaml
    us-east-1/
      5gc-values.yaml
  policies/                      # OPA/Kyverno policies

Keep applications, charts, and values in the same repo for small teams, separate repos for large ones (charts repo owned by platform team, values repo owned by network engineering). Cross-repo references work but add CI complexity.

App-of-apps

The app-of-apps pattern lets one ArgoCD Application manage many. The root app points at apps/, and each manifest in there is itself an Application:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: root
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://git.example.com/telco-gitops
    targetRevision: main
    path: apps
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Now adding a region is a PR adding apps/ap-south-1/5gc.yaml. The root app picks it up, ArgoCD creates the child Application, the child syncs the chart to the right cluster.

ApplicationSets are the modern evolution — generators (list, cluster, git) produce Applications from a template. For a fleet of 20+ regions, ApplicationSets beat manually managing app-of-apps.

Progressive rollouts: canary and blue-green for NFs

ArgoCD itself does not do progressive delivery. Argo Rollouts does, and it integrates cleanly.

Canary for stateless control plane NFs

AUSF, NSSF, NRF, AMF (mostly stateless): canary is straightforward.

strategy:
  canary:
    steps:
      - setWeight: 10
      - pause: { duration: 10m }
      - analysis:
          templates:
            - templateName: nf-success-rate
      - setWeight: 30
      - pause: { duration: 30m }
      - setWeight: 60
      - pause: { duration: 1h }

The analysis step queries Prometheus for SBI 5xx rate, NRF registration count, latency p99. Fail any threshold and the rollout aborts.

Blue-green for stateful or session-aware NFs

SMF and UPF hold session state. Canary risks splitting sessions across versions. Blue-green keeps a full v2 stack running, drains v1 by stopping new session admission, and cuts over once v1 is empty.

For UPF specifically, N4 association migration during cutover is the trick. SMF reassociates UPFs gracefully if you sequence it right. Some vendors support this natively; others do not, and you need a maintenance window.

Sync waves and dependency ordering

ArgoCD honors argocd.argoproj.io/sync-wave annotations. Lower waves sync first.

This matters most on initial deployment. After steady state, restart ordering is handled by init containers (see the Helm article).

Drift handling

selfHeal: true is tempting and dangerous. It makes ArgoCD overwrite any manual cluster change to match Git. Good for discipline, bad when an SRE is mid-incident-response and ArgoCD reverts their emergency fix.

Mature teams run with:

• automated.prune: true (delete resources removed from Git)
• automated.selfHeal: false (alert on drift, do not auto-correct)
• A separate playbook for accepted drift: either revert it manually or PR the change into Git.

For production 5G cores, manual sync with auto-prune is the most common pattern in 2026. Auto-sync is reserved for dev and staging.

Secrets in GitOps

Git must not hold plaintext secrets. Three viable options:

1. Sealed Secrets (Bitnami). Encrypts to a cluster-specific key. Simple, works offline. Re-encryption needed when key rotates.
2. External Secrets Operator with Vault/AWS Secrets Manager. Cluster pulls secrets at runtime. Requires Vault availability for sync.
3. SOPS with age or KMS. Files encrypted in Git, decrypted by ArgoCD via the SOPS plugin. Clean for small teams.

Subscriber keys for UDR never go in Git, regardless of encryption. They live in HSM or a dedicated secrets backend with hardware-backed keys.

Audit trail in practice

Compliance asks: "Who changed the AMF replica count to 12 last Tuesday?"

With GitOps:

git log --all --follow -p values/eu-west-1/5gc-values.yaml | grep -B5 "replicaCount: 12"

You get the commit, the author, the PR number, the reviewer, the JIRA ticket linked from the PR description, and the diff. That is the entire chain of custody.

For signed audit, enable signed commits (git config --global commit.gpgsign true) and require signed commits in branch protection. Now "who" is cryptographically verifiable.

What ArgoCD will not solve

• Schema validation — use OPA/Kyverno admission policies and conftest in CI.
• Drift you cause yourself by editing the chart and not bumping the version (Helm sees no change).
• Cross-cluster orchestration — ArgoCD manages clusters individually. Multi-cluster app coordination needs something on top (Argo Workflows, Crossplane).
• Network state — Multus NetworkAttachmentDefinitions in Git, but the underlying SR-IOV VF allocation on nodes is out of band.

> GitOps in telecom is less about deployment speed and more about deployment honesty. The cluster runs what Git says. There is no other source of truth.

If your 5G core's running config is not reconstructable from a single git clone, you are not doing GitOps yet.