ArchitectureDiagram.ai logoArchitectureDiagram.ai
Back to blog

GitOps Architecture Diagram: ArgoCD, Flux, and CI/CD Pipelines (2026)

How to draw a GitOps architecture diagram covering GitOps principles, ArgoCD deployment flows, Flux Kustomization, multi-cluster GitOps, and prompt templates for AI-generated diagrams.

R
Ryan·Senior AI Engineer
·

A GitOps architecture diagram shows how Git becomes the single source of truth for your infrastructure and application deployments. In a GitOps workflow, the desired system state is declared in Git, and an automated operator continuously reconciles the live cluster state toward that declaration — without a CI pipeline pushing changes to the cluster.

This guide explains what a GitOps architecture diagram must capture, shows the architectural differences between ArgoCD and Flux, and provides ready-to-use prompt templates for generating accurate GitOps diagrams in seconds.

Push-based vs. pull-based CD: the core diagram difference

Traditional CI/CD diagrams show a pipeline pushing to a cluster — the CI runner calls kubectl apply or helm upgrade with credentials stored in the pipeline environment. GitOps diagrams show the opposite: a controller running inside the cluster that continuously pulls desired state from Git and applies it. This distinction is the most important thing a GitOps architecture diagram must communicate:

  • Push-based: CI pipeline → cluster. Credentials live in the CI environment. Diagram shows an outbound arrow from CI runner to the API server.
  • Pull-based (GitOps): GitOps operator inside cluster → Git repo. No inbound credentials. Diagram shows an inbound arrow from the operator to the Git repo, and a separate reconciliation loop arrow within the cluster.

The four components of a GitOps architecture

  • Config repository: A Git repo (or repos) containing Kubernetes manifests, Helm charts, or Kustomize overlays that declare the desired cluster state. Show separate repos for app configs and infrastructure configs when they differ.
  • CI pipeline: Builds container images from source, runs tests, pushes to a container registry, and updates the image tag in the config repo — but does not deploy to the cluster. Show the CI pipeline writing to the config repo, not to the cluster.
  • GitOps operator: ArgoCD, Flux, or a custom controller running in the cluster. Watches the config repo for changes and applies them to the cluster via the Kubernetes API. Show reconciliation loops with a self-loop arrow or a recurring cron symbol.
  • Container registry: Stores built images (ECR, GCR, GHCR). The operator optionally polls the registry for new image tags (Flux Image Automation) and auto-commits tag updates to the config repo.

Prompt templates for GitOps diagrams

ArgoCD with app-of-apps pattern

"ArgoCD GitOps pipeline. GitHub Actions CI builds and pushes Docker images to ECR and updates image tags in a config repo. ArgoCD runs in a dedicated ops cluster and manages Application CRDs. A root Application (app-of-apps) points to a Helm chart that generates child Applications for each microservice. Each child Application syncs from its own directory in the config repo. ArgoCD deploys to three target clusters: staging, production-us, and production-eu. Sync policy is automated with self-healing enabled. ArgoCD sends Slack notifications on sync failure. Show the source repo, ECR, ArgoCD server, app-of-apps hierarchy, and the three target clusters."

Flux with image automation

"Flux GitOps stack in a single Kubernetes cluster. The GitHub repository contains Kustomize overlays for base, staging, and production environments. Flux GitRepository watches the repo for changes every 60 seconds. Flux Kustomization applies the staging overlay automatically; the production overlay requires a manual gate (GitHub Environments approval). Flux Image Reflector polls ECR for new image tags matching the semver constraint '^1.x.x'. When a new tag is found, Flux Image Automation commits the new tag to the config repo. SOPS encrypts secrets in the repo using an AWS KMS key; Flux decrypts on apply. Show the Git repo with three overlays, Flux controllers, ECR, KMS, and the reconciliation loops."

Multi-cluster GitOps fleet management

"GitOps fleet of 20 Kubernetes clusters managed by ArgoCD ApplicationSets. A central ArgoCD instance in the management cluster uses an ApplicationSet with a cluster generator to deploy the same application stack to all 20 tenant clusters. Each cluster has its own namespace in the config repo for tenant-specific overrides. ClusterSecretStore (External Secrets Operator) pulls secrets from AWS Secrets Manager into each tenant cluster. A separate ApplicationSet deploys platform services (cert-manager, external-dns, prometheus) to all clusters. ArgoCD Projects enforce RBAC so each team can only see and sync their own Applications. Show the management cluster, ApplicationSet, fleet of tenant clusters, secrets flow, and RBAC boundaries."

GitOps with progressive delivery (Argo Rollouts)

"GitOps pipeline with progressive delivery using Argo Rollouts. A new image tag commit to the config repo triggers an ArgoCD sync. ArgoCD applies the updated Rollout CRD. Argo Rollouts starts a canary strategy: 10% of traffic to the new version via Istio VirtualService weights. Prometheus scrapes the new pods and feeds metrics to the Rollout analysis template (error rate, p99 latency). If analysis passes after 5 minutes, Rollouts advances to 50%, then 100%. If analysis fails, Rollouts automatically rolls back. Show the full flow from git commit → ArgoCD sync → Argo Rollouts canary → Prometheus analysis → promote or rollback."

ArgoCD vs. Flux architecture comparison

DimensionArgoCDFlux v2
Architecture styleCentralized server + agentsFully decentralized controllers per cluster
Multi-clusterHub cluster manages spoke clustersEach cluster has its own Flux installation
UIBuilt-in web UI (comprehensive)CLI-first; Weave GitOps for UI
Image automationArgoCD Image Updater (external)Built-in Image Reflector + Automation
SecretsPlugin-based (Vault, ESO)SOPS native, ESO integration
Progressive deliveryArgo Rollouts (separate install)Flagger (separate install)

Frequently asked questions about GitOps architecture diagrams

What is the difference between GitOps and CI/CD?

CI/CD is a broad term covering the automation of build, test, and deployment. GitOps is a specific CD approach where Git is the authoritative source of truth and deployments happen via a pull-based reconciliation loop rather than a push from a pipeline. A traditional CI/CD diagram shows a pipeline pushing to a cluster; a GitOps diagram shows an operator inside the cluster pulling from Git.

How do I diagram secret management in a GitOps workflow?

Show the secret management tool (SOPS + KMS, Vault, External Secrets Operator) as a separate component with arrows indicating the secret fetch path. Secrets should never appear in the Git repo in plaintext — your diagram should show either encrypted blobs in Git (SOPS) or references to an external secret store (ESO pointing to AWS Secrets Manager, Vault, etc.) that are resolved at deploy time.

What is the app-of-apps pattern in ArgoCD?

The app-of-apps pattern uses a root ArgoCD Application that manages a Helm chart or Kustomize tree that generates other Application CRDs. This lets you manage an entire cluster's Application inventory declaratively through GitOps. In your diagram, show the root Application as a parent node with arrows to child Application nodes, each pointing to their own config repo directory.

Related guides: Kubernetes architecture diagram examples, platform engineering diagrams, DevSecOps architecture diagrams, and CI/CD pipeline use case.

Ready to try it yourself?

Start Creating - Free