GitOps Deployment Strategies Push vs. Pull

GitOps is an operating model that uses Git as the single source of truth for declarative infrastructure and application state, then synchronizes that state to running systems automatically. The term was introduced by Alexis Richardson, CEO of Weaveworks, in 2017 and later gained broad traction in the cloud-native community. By extending familiar Git workflows such as pull requests, code reviews, and branching into operations, GitOps has become a core practice in modern DevOps, especially when paired with declarative platforms like Kubernetes.

The Birth of GitOps and Core Principles

What is GitOps?

An operational methodology that declaratively defines all infrastructure configurations and application settings in a Git repository and uses this repository as the single source of truth to automatically synchronize the actual system state.

The term GitOps first appeared in August 2017 in the Weaveworks blog post “GitOps - Operations by Pull Request.” In that post, Alexis Richardson drew on his company’s Kubernetes management experience to describe a Git-centric operating approach and define the idea of GitOps. Later, CNCF (Cloud Native Computing Foundation) formed the GitOps Working Group to standardize GitOps principles and best practices, and in 2021, the OpenGitOps project published the official definition and principles of GitOps.

The Four Core Principles of GitOps

The core principles of GitOps as defined by the OpenGitOps project are as follows.

Declarative: The desired state of the system must be defined as declarations rather than commands. Like Kubernetes YAML manifests, it describes “what should be” and delegates “how to do it” to the system.

Versioned and Immutable: All declarative definitions must be stored in a version control system like Git, with change history preserved immutably to enable audit trails and allow rollback to previous states at any time.

Pulled Automatically: Approved changes must be automatically applied to the system by software agents. Rather than humans manually executing commands like kubectl apply, automated processes must continuously reflect the Git state to the system.

Continuously Reconciled: Software agents must continuously observe the actual system state and compare it to the desired state defined in Git, automatically reconciling when differences occur.

Push-Based Deployment Strategy

What is Push-Based Deployment?

An approach where external CI/CD pipelines send deployment commands directly to the cluster after build completion, operating similarly to traditional CI/CD pipelines.

The push-based approach can be implemented using existing CI/CD tools such as Jenkins, GitLab CI, and GitHub Actions. When build and test are completed in the CI pipeline, the CD stage uses tools like kubectl, Helm, and Kustomize to send deployment commands directly to the Kubernetes cluster.

How Push-Based Deployment Works

Stage 1: Source Code Changes and CI Pipeline Start

When a developer modifies application code and pushes to the Git repository, the CI pipeline is triggered and goes through verification processes including build, unit tests, integration tests, and static analysis. When all verifications pass, a container image is built and pushed to a container registry (Docker Hub, AWS ECR, Google GCR, etc.).

Stage 2: Manifest Update

When a new image is created, the CI/CD pipeline automatically updates the image tag in Kubernetes manifest files (Deployment, Service, etc.) and commits these changes to a separate config repository or deployment-related path in the same repository.

Stage 3: Cluster Deployment

The CD pipeline applies the updated manifests directly to the Kubernetes cluster. In this process, the CI/CD server must hold authentication information such as kubeconfig files or service account tokens to access the cluster.

Stage 4: Deployment Verification

After deployment, the pipeline verifies rollout status, performs health checks, runs smoke tests if necessary, and performs automatic or manual rollback if problems are found.

Advantages and Disadvantages of Push-Based Approach

Advantages:

• Low adoption cost as existing CI/CD tools and pipelines can be used as-is
• Intuitive implementation with workflow familiar to developers
• Full control over deployment timing and content from CI/CD pipeline
• Same approach can be applied to various environments (VMs, serverless, etc. beyond Kubernetes)

Disadvantages:

• Security risk as CI/CD server must have cluster access permissions
• No automatic detection or recovery when state drift occurs after deployment
• Inconsistency with Git state when someone modifies the cluster directly with kubectl
• Manual re-execution or separate retry logic required on pipeline failure

Pull-Based Deployment Strategy

What is Pull-Based Deployment?

An approach where a GitOps operator installed inside the Kubernetes cluster detects changes in the Git repository and automatically synchronizes the cluster state to the desired state defined in Git.

The pull-based approach is a deployment strategy that better aligns with the original intent of GitOps. ArgoCD and Flux are representative implementations, and an operator inside the cluster detects changes in the Git repository periodically or through webhooks and reflects them to the cluster.

How Pull-Based Deployment Works

Stage 1: Source Code Changes and Image Build

When a developer modifies application code and pushes to the Git repository, the CI pipeline is triggered to perform build and test. When verification passes, a new container image is pushed to the registry. This part is identical to the push-based approach.

Stage 2: Manifest Repository Update

The CI pipeline can update the image tag in the Kubernetes manifests stored in the config repository and commit that change. Alternatively, image tag auto-update features such as ArgoCD Image Updater or Flux Image Automation can detect new images and update the manifests automatically.

Stage 3: GitOps Operator Change Detection

The GitOps operator running inside the cluster (ArgoCD Application Controller, Flux Source Controller, etc.) detects changes in the Git repository at configured intervals (default 3 minutes) or through webhook notifications and compares the current cluster state with the desired state defined in Git.

Stage 4: Automatic Synchronization (Reconciliation)

When drift is found between Git state and cluster state, the operator automatically adjusts the cluster to match the Git state. This adjustment process is called the Reconciliation Loop and runs continuously to maintain consistent state at all times.

Stage 5: State Monitoring and Self-Healing

Even after deployment, the operator continuously monitors cluster state. Even if someone makes direct changes with kubectl or Pods are unexpectedly deleted, it automatically recovers (Self-Healing) to the state defined in Git.

Advantages and Disadvantages of Pull-Based Approach

Advantages:

• High security as cluster access permissions are not exposed externally
• Self-Healing feature that automatically detects and recovers from state drift
• Git repository acts as the only source of truth, ensuring consistency
• Continuous state synchronization through Reconciliation Loop
• Automatic retry and recovery on failures

Disadvantages:

• Requires installation and operation of dedicated GitOps tools (ArgoCD, Flux)
• Need to learn GitOps workflow separately from existing CI/CD pipelines
• Initial setup and configuration may be more complex than push-based approach
• Need to check operator logs instead of pipeline logs when debugging

Push vs Pull Comparison

The two deployment strategies have fundamental differences, and the appropriate approach should be chosen based on organizational context and requirements.

Major GitOps Tool Comparison

ArgoCD

ArgoCD is a Kubernetes-native GitOps tool developed by Intuit and released as open source in 2018. It is currently a CNCF Graduated project and one of the most widely used GitOps tools in the cloud-native ecosystem.

Key Features:

• Intuitive web UI dashboard to visually check application status and synchronization state
• Native multi-cluster management support to centrally manage multiple Kubernetes clusters
• Support for various deployment strategies (Blue/Green, Canary, Progressive Delivery) through integration with Argo Rollouts
• Fine-grained permission management through RBAC (Role-Based Access Control)
• SSO (Single Sign-On) integration support (OIDC, SAML, LDAP, etc.)
• Large-scale application templating and auto-generation through ApplicationSet

Suitable Environments:

• Large teams with users of various roles who need to check deployment status
• Multi-cluster environments requiring centralized management
• Cases requiring complex deployment strategies (Canary, Blue/Green)
• When powerful UI and visualization are important

Flux

Flux is a GitOps tool developed by Weaveworks, the company that coined the term GitOps. It is currently a CNCF Graduated project and forms one of the two major GitOps tools alongside ArgoCD.

Key Features:

• Modular architecture provided by a set of controllers called GitOps Toolkit
• Native support for Helm and Kustomize for natural integration with existing Kubernetes package management approaches
• Image auto-update feature (Image Automation Controller) for automatic deployment when new images are detected
• Lightweight design with low resource usage
• CLI-centric workflow suitable for automation and scripting
• Deployment status notifications to Slack, Microsoft Teams, Discord, etc. through notification controller

Suitable Environments:

• CLI and automation-centric workflow preferences
• Resource-constrained environments requiring lightweight solutions
• Heavy use of Helm and Kustomize
• Cases wanting to selectively use only needed features through modular architecture

ArgoCD vs Flux Comparison

Tool Selection Guide

Choosing the right GitOps tool depends on your organization’s context and requirements. The following criteria can help guide that decision.

When to Choose ArgoCD:

• When team members of various roles (developers, operators, managers) need to intuitively check deployment status
• When centralized management of multi-clusters is needed
• When advanced deployment strategies like Canary and Blue/Green are required
• When the team is early in its GitOps adoption journey and visual feedback helps learning

When to Choose Flux:

• When CLI and automation-centric workflow is preferred and UI is not essential
• When resources are limited or lightweight solution is needed
• When Helm and Kustomize are core tools
• When the team wants to enable only the features it needs through a modular architecture

When to Maintain Push-Based Approach (Jenkins, GitLab CI, etc.):

• When existing CI/CD pipeline investment is significant and immediate transition is difficult
• When the organization is in the early stages of GitOps adoption and plans to transition gradually
• When needing to deploy to various environments (VMs, serverless, etc.) beyond Kubernetes in the same way
• When integration with legacy systems is essential

Conclusion

GitOps has become a core model for deployment automation in cloud-native environments since it emerged at Weaveworks in 2017. Push-based and pull-based approaches each have clear tradeoffs. Push-based deployment is easier to adopt because it can reuse existing CI/CD tools, but it has limitations in security and state consistency. Pull-based deployment provides stronger security and self-healing capabilities, but it requires dedicated tooling and a different operational model. ArgoCD is a strong fit for larger teams that benefit from a powerful UI and multi-cluster support, while Flux works well for teams that prefer lightweight, automation-focused workflows. The right strategy depends on organizational scale, technical maturity, security requirements, and existing infrastructure. Regardless of which approach you choose, the core value of GitOps is a consistent, traceable deployment process built around Git as the single source of truth.