Scenario: You’ve just deployed an app using helm install. A few months pass, and you realize it’s time for an upgrade. You check the version history and see you’re a few releases behind. As you scan the release notes, you find a long list of upgrade instructions—more complex than you expected.
Wouldn’t it be nice to upgrade simply by changing a value in a file?
In this post, I’ll discuss GitOps and how I use Argo CD to manage applications in my home lab, making upgrades and deployments effortless.
Prerequisites:
Before you continue, please ensure you have the following:
- Access To A Kubernetes Cluster
- Helm
- A GitHub Account
What Is GitOps
GitOps is a methodology that uses Git as the single source of truth for managing infrastructure and application deployments. Instead of manually applying changes to a Kubernetes cluster, you define the desired state in a Git repository. I love analogies, so here ya go 😊:
Think of GitOps like a recipe and a personal chef.
- The recipe (Git repository) defines exactly how your dish (application) should be prepared.
- The chef (Argo CD) follows the recipe step by step, ensuring the dish turns out as expected.
- If someone accidentally adds the wrong ingredient (a manual change in the cluster), the chef quickly corrects it to match the recipe.
- When you want to tyouak the dish (upgrade your app), you simply update the recipe, and the chef takes care of the rest.
With GitOps, you don’t have to micromanage the cooking process—just define what you want, and your system ensures consistency every time.
What is Argo
Just like a chef needs the right tools to follow a recipe, GitOps needs a tool to enforce the desired state—and that’s where Argo CD comes in.
Argo CD is a declarative, GitOps-based continuous delivery tool for Kubernetes. It continuously monitors your Git repository and automatically syncs your cluster to match its defined state. If anything drifts—whether due to a manual change or an update—it detects and corrects it, ensuring consistency.
With Argo CD, you can:
- Automate application deployments and updates.
- Roll back easily if something goes wrong.
- Get real-time visibility into your Kubernetes apps.
Installing Argo CD
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
- Once installation is complete, verify with
kubectl get pods -n argocd
. All of the pods should be in a running state - Finally , you need a way to connect to the UI. By default, the Argo CD API server is not exposed with an external IP. There are a multitude of ways to do this, but for this guide, you’ll use a NodePort
- Run
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "NodePort"}}'
- Now when you check your services,
argocd-server
’s type should be NodePort.argocd-server NodePort 10.156.137.122 <none> 80:31182/TCP,443:30794/TCP
- To access the UI, head the following address
http://NODE-IP:FORWARDED-PORT
- You should now be greeted with the argo login screen 🎉
- To retrieve the admin password, run the following command:
kubectl get secrets/argocd-initial-admin-secret -n argocd -o json | jq -r '.data.password' | base64 --decode; echo
Connecting a GitHub Repo
Now that you have a running instance of argo, you need our single source of truth. For this guide, you’ll be using GitHub. To demonstrate, I’ll be using a helm app. You can grab your own, or fork the one that I’ve already set up.
Now that you’ve established a github repo you need a way for argo to connect to it. Since you’re using github, there are two connection methods you can chose from(HTTPS and SSH). FOr this guide you’ll be using SSH. If you don’t already has SSH key pair configured for your github account, follow this guide.
Connecting Github To Argo
Now that you have our keys configured in GitHub, you can connect Argo to Github. In Argo, go to Settings –> Repositories –> Connect Repo. You will now be presented with the form. Fill out the following.
- Name - The name of your repo
- Project -
Chose default
- Repository URL - This is the git clone link. Ensure you pick the SSH one.
- SSH Private Key Data - This will be the contents of the your key private file (the one without the .pub extension ) you generated in the previous section.
After clicking connect, you should see a Successful ✅ connection status.
Creating An Application
Its time to create our App. In Argo go to Applications –> + New App and fill out the following:.
- Application Name - Name of your app.
- Project Name -
default
- Sync Policy -
Automatic
- Repository URL - When you click the textbox, you should see the repo you connected from the previous section.
- Revision - HEAD
- Path - This will be the name of your GitHub app. If you forked the one I shared, your path will be
nginx
- Cluster URL -
https://kubernetes.default.svc
- Namespace - In your cluster, create a namespace for this app. and place it here.
- Click Create
You should now see your shiny new application! It should start syncing, but if it doesn’t, you can sync it manually. After a few seconds, your new app should be Healthy 💚
When you click on an app in Argo, you’re presented with a more in depth few of all of the kubernetes resoources that are apart of this app.
Ok, lets validate that our app is actually working. By default, when an application is deployed in Kubernetes, it is assigned a ClusterIP. This type of IP address restricts access to within the cluster, meaning the application cannot be reached from outside the cluster.
Based on the [helm values() I set for this app, it is using a node port. The same way you retrvied the Ip for this argo instance will be the same way you retvive teh IP for this nginx app. To get the exact port, run the following kubectl get svc -n {NAMESPACE OF APP}
.
nginx NodePort 10.125.10.26 <none> 80:31622/TCP,443:32676/TCP
Now that you have your port, in your browser go to the following URL: http://NODE-IP:31622
You should see the nginx welcome page !
Git Ops in Action
Let’s walk through making a simple configuration change to demonstrate GitOps in action. With Argo CD, you don’t need to manually update your Kubernetes resources. Just make the change in your Git repository, and Argo CD will take care of applying it.
For example, let’s scale our application by updating the number of replicas. In the values.yaml file of your repo, modify the replica count from 1 to 2:
nginx:
replicaCount: 2
service:
type: NodePort
Once you commit and push the change, go to Argo CD and click the Sync button on your application. You’ll notice that an additional pod is created automatically 🎉.
When you sync an app in Argo CD, it compares the desired state (from your Git repo) with the current state (in your cluster) and makes the necessary adjustments to bring them in line. That’s the poyour of GitOps.
Conclusion
In this guide, you walked through the process of setting up Argo CD, connecting your Git repository, and deploying your first application using GitOps principles. You saw how seamless and poyourful it is to manage Kubernetes applications with Argo CD—from automatically syncing changes to visualizing the entire deployment flow.
By integrating your deployments with Git, you gain version control, audit trails, and a clear source of truth—all essential components for modern DevOps practices. This was just a simple example using an NGINX app, but the same workflow applies to more complex, production-grade applications.
If you’re new to GitOps, Argo CD is a great starting point to embrace this approach. Try experimenting with more configurations, explore Helm charts, and keep building. Happy shipping! 🚀