## From Push to Pull: How I Fully Embraced GitOps with Argo CD in My Confdroid developer cloud
After several days of experimentation, I have now fully implemented Argo CD — and the difference in day-to-day operations is night and day.
Here’s a clear before-and-after look at how my Kubernetes workflow has changed.
## The Old Way (Push-Based Deployments)
Before Argo CD, my setup looked like this:
– A single Git repository containing all raw Kubernetes manifests (YAML files) for both applications and core cluster components.
– A CI/CD pipeline that used `kubectl` to connect to the cluster and (re)deploy everything — from the CNI and storage classes to Longhorn and other infrastructure pieces.
– This pipeline acted as a safety net: if the cluster ever got into a bad state, a single pipeline run could restore it to a known-good configuration.
– New applications could be added or updated simply by pushing changes to the repo. The pipeline would pick them up and apply them to the cluster.
– Troubleshooting and manual adjustments were done directly with `kubectl` or a UI like the Kubernetes Dashboard, or in my case Headlamp. While convenient, this also opened the door to accidental changes — scaling a deployment and forgetting to update the manifests, for example.
Every git push triggered a push-based deployment. It worked well, but it relied heavily on discipline and perfect execution.
## The New Way (Pure GitOps with Argo CD)
The old repository and pipeline still exist and continue to handle all low-level cluster reconfiguration (CNI, storage, base infrastructure, Argo CD configuration itself, including Keycloak integration). That safety net remains untouched.
What changed is the introduction of a dedicated second repository dedicated to Argo CD-managed applications.
Here’s how it works now:
– Application manifests have been moved into the new Git repository.
– Argo CD is installed and configured via the original pipeline.
– Once running, Argo CD connects to the new repository and continuously synchronizes the cluster state with the desired state defined in Git. This requires one-off registration of the application via UI or CLI.
– Synchronization can be triggered from the beautiful Argo CD web UI or via the CLI — the result is identical. Best though is setting auto-sync, which is what this is all about. This can be on done application level as required / desired.
– Any drift is automatically corrected. If someone manually scales a deployment with `kubectl` or changes a ConfigMap in the dashboard, Argo CD will immediately revert it back to match the Git definition.
– No more “I scaled it temporarily and forgot to update the YAML” accidents.
– All changes — even small tweaks — must now go through Git. This enforces a true pull-based GitOps model. **Stability over convenience!**
## Why This Feels So Much Better
Argo CD brings several powerful advantages:
– It operates in a pure pull model, which is inherently more reliable than the previous push approach.
– It can manage itself (though I chose not to enable that yet), multiple clusters, projects, and even different environments or stages — all without needing an external database.
– The web UI is excellent. For every application, you can see pods, ReplicaSets, Services, ConfigMaps, and more at a glance.
– As a massive bonus, it integrates beautifully with the Trivy Operator running in my cluster, displaying up-to-date vulnerability scan results directly in the Argo CD dashboard for each application.
## Final Thoughts
Implementing Argo CD took me roughly four hours from start to finish, some fine-tuning pending — time extremely well spent.
The cluster now feels significantly more robust and predictable. By moving to a strict GitOps workflow, I’ve eliminated an entire class of human errors while gaining much better visibility and control.
This setup brings me noticeably closer to my goal of running cloud-native applications the way they were meant to be operated: declaratively, version-controlled, and automatically reconciled.
GitOps isn’t just a nice-to-have anymore — it has become the foundation of how I want to run Kubernetes going forward.
If you’re still managing Kubernetes with direct kubectl applies or traditional CI/CD push pipelines, I highly recommend giving Argo CD a try. The improvement in stability and peace of mind is immediate and very real.
In the next post of this series, I’ll share the exact steps I took to install and configure Argo CD with Keycloak integration, along with my recommended folder structure and best practices.
Until then — happy deploying!
—
Did you find this post helpful? You can support me.
[](https://www.buymeacoffee.com/grizzly_coda)
[](https://hetzner.cloud/?ref=EY14C8Tema9j)
[](https://confdroid.substack.com/subscribe?params=%5Bobject%20Object%5D)
[](https://feedback.confdroid.com/)
## Related posts
– [Kubernetes – Adventures – Pilot](https://confdroid.com/kubernetes-adventures-pilot/)
– [Kubernetes – Argo-CD – Custom Installation](https://confdroid.com/kubernetes-argocd-custom-installation/)
Author Profile
