30. 09. 2025
Development, DevOps, Kubernetes
18. 12. 2024
Mattia Codato
Automation, Development, DevOps
GitOps: Push vs Pull? Choosing the Right Approach for Production Deployments
Starting a new project is often an opportunity to reevaluate established practices. In our case, deploying a containerized application to production with OpenShift led us to revisit our GitOps strategy. Using ArgoCD as our GitOps tool raised a fundamental question: What is the best way to move changes into production—push or pull?
Understanding Push and Pull in GitOps
GitOps relies on managing infrastructure and application deployments declaratively through Git repositories. This approach ensures version control, traceability, and automation. Within this paradigm, there are two primary methods for deploying changes:
- Push-based GitOps: The CI/CD pipeline actively pushes changes to the cluster
- Pull-based GitOps: An automated GitOps tool (e.g., ArgoCD) running within the cluster continuously pulls changes from a dedicated Git repository
Each method has its strengths, and the choice between them depends on factors such as security, operational efficiency, and team structure.
Why We Chose the Pull Model with ArgoCD
For this project, we adopted a pull-based GitOps approach. This decision was influenced by several critical considerations, especially around security and the separation of responsibilities between development and operations teams.
How the Pull Model Works with ArgoCD
In our workflow, ArgoCD is the automation tool responsible for synchronizing the cluster’s state with the declared configuration in a Git repository. Here’s how it works:
- Developers create and maintain application code in their repository
- When a new release is ready, developers submit a pull request targeting the repository containing ArgoCD deployment configurations
- A GitOps operator – a team member responsible for managing deployments – reviews and validates the PR
- Upon approval, the PR is merged into the repository
- ArgoCD detects the change, synchronizes the cluster, and deploys the application to production.
This workflow ensures a clear separation of responsibilities:
- Developers focus on application logic
- GitOps operators oversee deployment and production readiness
The inclusion of a review step adds rigor, minimizes errors, and enforces organizational standards, ensuring smooth and secure deployments.
Repository Separation and Access Control
To enhance security and operational control, we maintained a strict separation between:
- The application code repository
- The deployment configuration repository
Developers do not have direct push access to production environments. Instead, they propose changes to deployment configurations through PRs, which are carefully reviewed before being applied.
This separation:
- Implements an additional layer of oversight
- Complies with security best practices
- Creates a transparent and auditable pipeline
Enhanced Security in the Pull Model
The pull model offers significant security advantages:
- Credential management: CI/CD pipelines in push-based GitOps require elevated permissions to interact with production environments, increasing the risk of credential exposure. In pull-based GitOps, credentials remain securely within the cluster’s control plane.
- Reduced attack surface: ArgoCD autonomously fetches changes from the repository and applies them, eliminating the need for external systems to access sensitive environments.
By keeping sensitive data isolated and minimizing external touchpoints, the pull model aligns with modern SecDevOps principles.
When Push-Based GitOps Might Be Used
While the pull model met our requirements and is generally the recommended approach, push-based GitOps could be considered in highly specific scenarios, such as:
- Teams requiring extremely rapid deployments with no intermediate steps
- Simple setups where a deployment pipeline directly applies changes to a controlled, non-critical environment
However, these scenarios come with significant trade-offs in security, auditing, and operational flexibility, making push-based GitOps unsuitable for most production environments.
Conclusion
The pull-based GitOps model is the preferred approach for production deployments, particularly when security, compliance, and auditability are priorities. For our project, the pull model provided the optimal balance of security, operational efficiency, and best practices. Leveraging ArgoCD and clearly separating responsibilities between development and operations allowed us to create a robust, scalable, and secure deployment workflow.
In a modern SecDevOps context, where protecting sensitive environments is critical, pull-based GitOps is the best choice for managing production deployments.
These Solutions are Engineered by Humans
Did you find this article interesting? Are you an “under the hood” kind of person? We’re really big on automation and we’re always looking for people in a similar vein to fill roles like this one as well as other roles here at Würth Phoenix.
Mattia Codato
Software Developer - IT System & Service Management Solutions at Würth Phoenix
Author
Latest posts by Mattia Codato
25. 09. 2025
CTF Writeups, Development, Events
Preparing for WP CTF 2025
02. 06. 2025
Development, Front-end, Icinga News, Icinga Web 2, NetEye, PHP
Content Security Policy (CSP) + NetEye 4.42