How to automate Kubernetes deploys with ArgoCD and GitOps

What is GitOps and why abandon manual scripts

Managing servers and applications in modern environments used to require running complex manual commands or fragile automation scripts directly in production. In practice, this means any connectivity glitch or typing typo during an update could take the entire system down. To solve this structural problem, the engineering community adopted the model known as GitOps, a methodology where the entire desired state of infrastructure and applications is stored in code repositories like GitHub or GitLab. If you have ever needed to version control Obsidian notes with Git and secure backup, you already know the basic logic of tracking changes line by line.

Instead of sending imperative commands to alter a server, the team simply updates declarative configuration files in the repository. The technology ecosystem then takes responsibility for reading those files and adjusting the real environment until it perfectly matches what was written. This paradigm shift turns the Git commit history into an immutable audit trail, where every infrastructure modification has an author, a date, and a clear documented justification.

How ArgoCD acts as the synchronization engine in Kubernetes

Kubernetes is a fantastic tool for managing containers, but its native API was not originally designed to monitor external code repositories automatically. This is precisely where ArgoCD comes in, a declarative continuous delivery tool designed specifically for the Kubernetes ecosystem. In practice, ArgoCD runs inside the cluster itself, continuously connecting to your Git repository to watch for any changes in configuration manifests.

When a developer approves a Pull Request changing a container image version, ArgoCD notices the discrepancy between the current cluster state and the desired state described in the repository. It visually signals the mismatch on its graphical dashboard or performs automatic synchronization, applying the new resources directly to Kubernetes. For teams already dealing with complex architectures, managing this consistency is just as crucial as structuring efficient microservices, a topic we cover when discussing how to structure microservices with gRPC and Protocol Buffers.

Practical installation and cluster setup for ArgoCD

To get your hands dirty, the first step is to create an isolated namespace inside your Kubernetes cluster and apply the official installation manifests provided by the ArgoCD project. Open your terminal and run the commands below to prepare the ground.

In the following example, we create the dedicated environment and download all necessary components to run the control panel and synchronization engine:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

After a few minutes, all pods will be running, and you can access the web interface using local port forwarding or by configuring a corporate load balancer. The default user will be automatically generated with the name 'admin', and the initial password can be obtained through a simple retrieval command in the terminal.

Structuring your first declarative application

With ArgoCD running, the next step is registering a Git repository containing your applications. Instead of using external CI/CD tools to apply manifest files via 'kubectl apply', ArgoCD itself will do the heavy lifting safely and controllably within the cluster perimeter.

Below is a classic example of an 'Application' manifest file used by ArgoCD to map a demonstration repository:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-web-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example/my-gitops-repo.git
    targetRevision: HEAD
    path: k8s/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

This file instructs ArgoCD to look at a specific repository folder and ensure that the production namespace precisely reflects those guidelines. If someone manually alters a resource directly inside the cluster, the 'selfHeal' option forces automatic correction back to the approved Git standard.

Operational advantages and security in continuous delivery

Adopting GitOps with ArgoCD brings massive security gains because it eliminates the need to expose production access credentials to external continuous integration servers like GitHub Actions or Jenkins. Since the ArgoCD agent itself runs inside the cluster, it only pulls read changes from public or private Git repositories, keeping the network perimeter strictly protected against external intrusions.

Another strong point is the ability to perform instant rollbacks. If a deployment fails due to an unexpected application bug, the team does not need to run complex reversion scripts. Simply revert a commit in the Git history or ask ArgoCD to synchronize the cluster with the previous stable version in a few clicks on the graphical interface.

Final considerations on operational maturity in GitOps

Migrating to a GitOps-based delivery culture requires a mindset shift across the entire engineering team, but the return on investment quickly pays off the initial effort. By eliminating manual processes and centralizing infrastructure state in declarative files, you gain predictability, speed, and total traceability in deliveries. Maintaining this operational rigor ensures that infrastructure growth keeps pace with business scale without unwelcome surprises during critical high-demand moments.