GitOps and Immutable Infrastructure: How ArgoCD and Flux Are Making Deployments

From Push-Based CI/CD to Pull-Based GitOps

Traditional continuous deployment follows a push model: a CI pipeline builds the application, runs tests, and then pushes the artifact to the production environment. Jenkins, GitHub Actions, GitLab CI — these tools execute deployment scripts that SSH into servers, run kubectl apply commands, or call cloud provider APIs to update running services. The CI system is the actor; the production environment is the passive recipient. This model works, but it has a fundamental weakness: the CI system must have credentials to modify production, the deployed state can diverge from what is defined in code (configuration drift), and there is no continuous mechanism to detect or correct that divergence.

GitOps inverts this model. Coined by Alexis Richardson, CEO and founder of Weaveworks, in a March 2017 blog post titled “Operations by Pull Request,” GitOps proposes that the desired state of infrastructure and applications is declared in a Git repository, and an agent running inside the cluster continuously reconciles the actual state with the declared state. If someone manually modifies a Kubernetes deployment (a common source of drift), the GitOps agent detects the discrepancy and reverts it to match the Git-defined state. Git becomes the single source of truth — every change is versioned, auditable, and reversible through standard Git operations (commit, revert, branch).

The two dominant GitOps tools — ArgoCD and Flux — have both achieved CNCF (Cloud Native Computing Foundation) Graduated status, the highest maturity level in the CNCF ecosystem. Both graduated in late 2022: Flux on November 30 and ArgoCD on December 6. ArgoCD, originally open-sourced by Intuit in January 2018 and donated to the CNCF, has surpassed 20,000 GitHub stars and is used in production by companies including Red Hat, Tesla, IBM, Adobe, and Capital One. A July 2025 CNCF End User Survey found ArgoCD running in nearly 60% of Kubernetes clusters for application delivery, with 97% of respondents using it in production. Flux, originally created by Weaveworks and now maintained by the CNCF community after Weaveworks’ closure in February 2024, provides a lighter-weight, composable GitOps toolkit. Together, they have made GitOps the dominant deployment pattern for Kubernetes-based environments.

How ArgoCD and Flux Work

ArgoCD operates as a Kubernetes controller that watches Git repositories containing application definitions (Kubernetes manifests, Helm charts, or Kustomize overlays). When a developer merges a change to the Git repository — updating a container image tag, modifying resource limits, adding an environment variable — ArgoCD detects the change and synchronizes the Kubernetes cluster to match. The ArgoCD web UI provides real-time visualization of application state: which resources are synced, which are out of sync, and what the differences are. Rollbacks are as simple as reverting a Git commit.

ArgoCD supports multiple synchronization strategies. “Auto-sync” applies changes immediately when Git is updated — suitable for development and staging environments. “Manual sync” requires an operator to approve synchronization — appropriate for production environments where changes should be reviewed before deployment. ArgoCD also supports “sync waves” (ordering resource deployment) and “sync hooks” (running pre/post-sync jobs), enabling complex deployment orchestrations such as database migrations before application updates. ArgoCD excels at the app-of-apps and ApplicationSet patterns for managing hundreds of applications declaratively, which is why platform engineers now represent 37% of ArgoCD users according to the 2025 CNCF survey — reflecting its rising role in internal developer platforms.

Flux takes a more modular approach. Rather than a monolithic application, Flux is composed of specialized controllers: Source Controller (watches Git repositories, Helm repositories, and OCI registries for changes), Kustomize Controller (applies Kustomize overlays to the cluster), Helm Controller (manages Helm chart releases), Notification Controller (sends alerts to Slack, Teams, or webhook endpoints), and Image Automation Controllers (automatically updates container image tags in Git when new images are pushed to a registry). This composability means teams can adopt only the Flux components they need. Flux’s image automation capability is particularly powerful: when a CI pipeline pushes a new container image, Flux detects it, updates the image tag in the Git repository, and then reconciles the cluster — fully automating the deployment pipeline without any CI system needing cluster credentials.

After Weaveworks shut down in February 2024, questions arose about Flux’s future. The project has stabilized under CNCF stewardship: ControlPlane hired core maintainer Stefan Prodan, and AWS, Microsoft, Cisco, and other vendors stepped up with maintainer commits. Innovation pace has slowed compared to the Weaveworks era, and commercial support has largely disappeared, but the project remains actively maintained with no critical bugs or security issues left unaddressed. ArgoCD has pulled significantly ahead in adoption — the CNCF 2023 annual report counted 927 code authors for the Argo project versus 188 for Flux — but Flux remains the preferred choice for teams that value its modular, composable architecture.

Immutable Infrastructure: Never Modify, Always Replace

GitOps is deeply connected to the principle of immutable infrastructure — the idea that running servers and containers should never be modified in place. Instead of SSHing into a server to install a security patch or update a configuration file (mutable infrastructure), you build a new server image with the patch applied and replace the old server entirely (immutable infrastructure). The old server is destroyed, not modified. This approach was given its name by Chad Fowler in a 2013 blog post, “Trash Your Servers and Burn Your Code,” while Martin Fowler’s site at Thoughtworks documented the closely related “Immutable Server” pattern. Operationalized through containerization, immutable infrastructure eliminates configuration drift — the gradual divergence between what you think is running and what is actually running.

In a Kubernetes context, immutable infrastructure means that containers are treated as disposable units. You never exec into a running container to change a file. You never kubectl edit a deployment in-place. Instead, you update the container image, push the new version to a registry, update the image tag in the Git repository, and let ArgoCD or Flux roll out new pods with the updated image while terminating the old ones. The running state is always a faithful reproduction of what is defined in Git.

The benefits compound at scale. When every environment (development, staging, production) is defined in Git, promoting a change from staging to production is a Git merge — not a manual deployment script. When compliance requires an audit trail of every change to production, Git provides it automatically: who changed what, when, and why (via commit messages). When a deployment breaks production, rolling back is a Git revert, not a frantic scramble to remember what the previous configuration looked like. Infrastructure becomes as versioned and reviewable as application code.

The Organizational Shift: GitOps Is a Culture Change

Adopting GitOps is not merely installing ArgoCD. It requires a fundamental shift in how operations teams work. The first cultural change: operators must stop making ad-hoc changes to production. No more “quick fix” kubectl commands that are never documented. No more “I’ll just change this config map real quick.” Every change must go through Git — a pull request, a code review, a merge. This discipline is uncomfortable for operations teams accustomed to the speed and flexibility of direct access, and the transition period often involves friction as urgent fixes that could be applied in seconds now require a commit-review-merge cycle.

The second organizational shift is the convergence of developer and operator workflows. In a GitOps model, developers and operators use the same tools (Git), the same processes (pull requests, code review), and the same artifact (the Git repository). This aligns with the broader DevOps philosophy but goes further: there is no separate “deployment tool” that only operators know how to use. A junior developer who understands Git can understand (and contribute to) the deployment process. This democratization reduces the “bus factor” risk where deployment knowledge is concentrated in a single SRE.

The third shift involves secrets management, which remains the thorniest practical challenge in GitOps adoption. If Git is the source of truth for everything, how do you handle secrets — database passwords, API keys, TLS certificates — that should not be stored in plaintext in a Git repository? The solutions include Sealed Secrets (encrypting secrets that only the cluster can decrypt), External Secrets Operator (fetching secrets from external vaults like HashiCorp Vault, AWS Secrets Manager, or Google Secret Manager at deployment time), and SOPS (Mozilla’s Secret Operations tool, which encrypts secret values within YAML files using KMS keys). None of these solutions is as simple as putting secrets in a .env file, and the complexity of GitOps-compatible secrets management is a genuine adoption barrier.

Beyond Kubernetes: GitOps for Everything

The GitOps model was born in the Kubernetes ecosystem, but its principles — declarative state, version-controlled configuration, continuous reconciliation — apply broadly. Terraform already follows a GitOps-adjacent pattern: infrastructure is defined in HCL files stored in Git, and terraform apply reconciles the cloud environment with the declared state. OpenTofu, the open-source fork of Terraform created in response to HashiCorp’s BSL license change in August 2023, follows the same model and has gained significant traction — as of 2025, half of Spacelift’s deployments run on OpenTofu. Tools like Atlantis and Spacelift extend both Terraform and OpenTofu by running plan/apply through pull request workflows, bringing the same review-and-approve-via-Git process to cloud infrastructure management.

Crossplane, which achieved CNCF Graduated status in October 2025, extends Kubernetes-style declarative management to any cloud resource — databases, message queues, DNS records, even SaaS subscriptions — using Kubernetes custom resources. With over 3,000 contributors from 450+ organizations and users including Nike, NASA Science Cloud, and SAP, Crossplane has validated the “GitOps for everything” vision. A developer defines an AWS RDS database instance as a YAML manifest in Git, and Crossplane provisions and manages it, with ArgoCD ensuring the manifest stays in sync. This model — where every piece of infrastructure, from Kubernetes workloads to cloud resources to DNS records, is declared in Git and continuously reconciled — is the logical endpoint of the movement.

The trajectory is clear: manual infrastructure operations — clicking through cloud consoles, running ad-hoc CLI commands, SSHing into servers — is becoming as anachronistic as manual code deployment via FTP. Organizations that adopt GitOps report measurable improvements: Adobe’s Creative Cloud infrastructure team reduced rollback times from 45 minutes to 3 minutes with ArgoCD, and the 2025 CNCF survey found that 93% of organizations plan to continue or increase their GitOps adoption. Faster software delivery was the top-cited reason for embracing GitOps (71% of respondents), followed by improved configuration management and greater deployment consistency (66% each). The cost is upfront: learning curve, tooling setup, secrets management, and the cultural discipline of never touching production directly. For organizations managing 10+ microservices on Kubernetes, the ROI is unambiguous.

Frequently Asked Questions

Sources & Further Reading

• CNCF End User Survey Finds Argo CD as Majority Adopted GitOps Solution — CNCF
• ArgoCD Documentation — Argo Project / CNCF
• Flux Documentation — FluxCD / CNCF
• Cloud Native Container Management Platform Weaveworks Shuts Its Doors — TechCrunch
• Why Flux Isn’t Dying After Weaveworks — The New Stack
• Cloud Native Computing Foundation Announces Graduation of Crossplane — CNCF
• GitOps Goes Mainstream: ArgoCD Surpasses 20,000 GitHub Stars — DevOps Tales
• Sealed Secrets — Bitnami Labs
• External Secrets Operator — External Secrets Project
• Immutable Server — Martin Fowler