GitOps with Argo CD on Kubernetes

Deploy apps via Git commits using Argo CD on a local Kubernetes cluster.

Introduction

30 Second Summary

Imagine if every change you made to a document automatically updated every copy of it everywhere, with no extra steps. That is exactly how modern DevOps teams deploy software using a practice called GitOps.

In this project, you will install Argo CD on a local Kubernetes cluster, connect it to a GitHub repository containing your application manifests, and deploy an application purely by pushing changes to Git.

What You'll Build

A complete GitOps delivery pipeline running on your local Docker Desktop Kubernetes cluster, where Git is the single source of truth for your application's desired state.

By the end of this project, you'll have:

  • An Argo CD instance running on your local Kubernetes cluster with full Web UI access.
  • A GitHub repository serving as the single source of truth for your application's desired state.
  • A Kubernetes Deployment and Service managed entirely through automated sync, with no manual kubectl apply required.
  • Secret Mission: Enable self-healing and intentionally break your cluster to watch Argo CD automatically restore the desired state.

Are there any prerequisites?

You should have basic familiarity with Kubernetes concepts like Deployments, Services, and namespaces. You also need to know Git fundamentals (clone, commit, push) and have a GitHub account ready to go.

Your environment should already have Docker Desktop with Kubernetes enabled, kubectl, and Helm installed.

Install Argo CD and Access the Dashboard

Before you can deploy applications through Git, you need a GitOps controller running inside your cluster.

In this step, you will install Argo CD on your local Kubernetes cluster, set up the CLI tool, and log in to the Argo CD Web UI.

In this step, get ready to:
  • Install Argo CD v3.4.4 on your Docker Desktop Kubernetes cluster.
  • Install the Argo CD CLI and add it to your PATH.
  • Access the Argo CD dashboard at https://localhost:8080 and log in as admin.
Install Argo CD on your Docker Desktop Kubernetes cluster

Argo CD runs as a set of pods inside your cluster. You need to create a dedicated namespace for it and apply the official installation manifests.

  • Verify your kubectl context is pointed at Docker Desktop by running this command:
kubectl config current-context

What should I see?

The output should say docker-desktop. This confirms kubectl is talking to your local Docker Desktop Kubernetes cluster.

Seeing a different context name?

If you see a different cluster name, open Docker Desktop, go to Settings then Kubernetes, and make sure Enable Kubernetes is checked. Then restart Docker Desktop.

help me switch my kubectl context to docker-desktop

  • Create the argocd namespace and install the Argo CD manifests by running these commands:
kubectl create namespace argocd
kubectl apply -n argocd --server-side --force-conflicts -f https://raw.githubusercontent.com/argoproj/argo-cd/v3.4.4/manifests/install.yaml

What do these commands do?

The first command creates a new namespace called argocd to isolate all Argo CD components from the rest of your cluster.

The second command downloads and applies the official Argo CD v3.4.4 manifests. This creates Deployments, Services, ConfigMaps, and other resources that make up the Argo CD control plane.

  • Delete the NetworkPolicies that ship with Argo CD by running this command:
kubectl delete networkpolicies --all -n argocd

Why delete NetworkPolicies?

Docker Desktop's built-in CNI does not properly enforce NetworkPolicies. This causes connectivity issues between Argo CD components. Deleting them allows the pods to communicate freely on your local cluster.

  • Wait for all Argo CD pods to become Ready by running this command:
kubectl wait --for=condition=Ready pod --all -n argocd --timeout=300s

What does this command do?

This tells kubectl to pause until every pod in the argocd namespace reports a Ready condition. The --timeout=300s flag gives the pods up to 5 minutes to start. On the first install, images need to be pulled which can take a minute or two.

  • Confirm all pods are running by running:
kubectl get pods -n argocd

You should see several pods (including argocd-server, argocd-repo-server, and argocd-application-controller) all showing Running status with all containers ready.

Pods stuck in Pending or CrashLoopBackOff?

Make sure Docker Desktop has enough memory allocated (at least 4 GB). Open Docker Desktop, go to Settings then Resources, and increase the memory if needed. Restart Docker Desktop after changing resources.

help me debug Argo CD pods that are not starting on Docker Desktop Kubernetes

Install the Argo CD CLI on Windows

The Argo CD CLI lets you interact with Argo CD from your terminal. You will use it to log in, sync applications, and check status without needing the Web UI.

  • Download the Argo CD CLI binary by running these commands in PowerShell:
$version = (Invoke-RestMethod https://api.github.com/repos/argoproj/argo-cd/releases/latest).tag_name
$url = "https://github.com/argoproj/argo-cd/releases/download/" + $version + "/argocd-windows-amd64.exe"
$output = "C:\Tools\argocd.exe"
New-Item -ItemType Directory -Force -Path "C:\Tools"
Invoke-WebRequest -Uri $url -OutFile $output

What do these commands do?

The first line fetches the latest release tag from GitHub. The second line builds the download URL for the Windows binary. The remaining lines create a C:\Tools directory and download the executable there.

  • Add the C:\Tools directory to your PATH by running this command:
[Environment]::SetEnvironmentVariable("Path", "$env:Path;C:\Tools", "User")

Why add to PATH?

Adding the directory to your PATH means you can type argocd from any terminal window without specifying the full file path every time.

  • Close and reopen your PowerShell window so the new PATH takes effect.
  • Verify the CLI is installed by running this command:
argocd version --client

✔️ I see a version number

The output shows the Argo CD client version. You are ready to continue.

ⓧ I see an older version

If the version shown is older than v3.4.4, re-run the download commands above. They always fetch the latest release.

ⓧ Command not found

If PowerShell cannot find the argocd command, the PATH update has not taken effect.

  • Make sure you closed and reopened PowerShell after setting the PATH.
  • Verify the file exists at C:\Tools\argocd.exe by running dir C:\Tools.
  • If the file is missing, re-run the download commands from the previous substep.

help me fix the argocd CLI not being found on Windows PATH

Access the Argo CD Web UI

Argo CD includes a Web UI for visualizing your applications, their sync status, and the resource topology. You need to port-forward the server and retrieve the initial admin password to log in.

  • Start a port-forward to the Argo CD server by running this command:
kubectl port-forward svc/argocd-server -n argocd 8080:443

What does this command do?

This maps port 8080 on your local machine to port 443 on the argocd-server service inside your cluster. This gives you access to the Argo CD Web UI without needing a LoadBalancer or NodePort.

Keep this terminal running

The port-forward command occupies the terminal. Open a second terminal window for the next commands. The port-forward must stay running for the entire time you use Argo CD.

  • Open a new terminal window.
  • Retrieve the initial admin password by running this command:
argocd admin initial-password -n argocd

What is this password?

Argo CD generates a random admin password during installation and stores it in a Kubernetes secret called argocd-initial-admin-secret. This command retrieves that password so you can log in.

  • Copy the password from the terminal output.
  • Open your browser and navigate to https://localhost:8080.

Seeing a security warning? Do not worry

Argo CD uses a self-signed certificate by default. Your browser will show a security warning. Click Advanced and then Proceed to localhost (or the equivalent in your browser) to continue.

  • Enter admin as the username.
  • Paste the password you copied earlier into the password field.
  • Click SIGN IN.

You should see the empty Argo CD dashboard. There are no applications listed yet because you have not created any.

Cannot connect to localhost:8080?

Make sure the port-forward command is still running in your other terminal. If it stopped, re-run it. Also check that nothing else is using port 8080 on your machine.

help me troubleshoot why I cannot access the Argo CD UI at localhost:8080

Argo CD is running and you have full access to the dashboard. Next up, you will create a Git repository with Kubernetes manifests that Argo CD will use as the single source of truth for your application.

Create a Git Repository with Kubernetes Manifests

Your Argo CD instance is installed and running, but it has nothing to deploy yet. It needs a Git repository to watch.

In GitOps, your Git repository is the single source of truth for your application's desired state. Instead of running commands against the cluster directly, you define what you want in YAML files and let Argo CD make it happen.

In this step, get ready to:
  • Create a public GitHub repository for your Kubernetes manifests.
  • Write a Deployment and Service manifest for an nginx application.
  • Push your manifests to GitHub so Argo CD can access them.
Create a new GitHub repository

Argo CD will pull manifests from a GitHub repository. Using a public repository means Argo CD can access it without needing credentials configured.

  • Open your browser and go to github.com.
  • Click the + icon in the top-right corner.
  • Click New repository.
  • Enter gitops-demo as the repository name.
  • Select Public for the visibility.
  • Leave all checkboxes unchecked (no README, no .gitignore, no license).
  • Click Create repository.

Why leave the repository empty?

An empty repository gives you a clean starting point. You will add your Kubernetes manifests locally and push them up, which is the standard GitOps workflow for initializing a new project.

GitHub will show a Quick setup page with the HTTPS URL for your new repository. Keep this page open.

  • Open a new terminal window (your existing terminal is running the port-forward).
  • Move to your Desktop by running this command:
cd ~/Desktop
  • Clone your new empty repository by running this command:
git clone https://github.com/[[YOUR_GITHUB_USERNAME="your-github-username"]]/gitops-demo.git
  • Move into the cloned repository by running:
cd gitops-demo
  • Confirm you are inside the gitops-demo folder by running:
pwd

You should see a path ending in gitops-demo.

Clone failed or repository not found?

  • Double-check you replaced your GitHub username in the URL. The URL should look like https://github.com/your-actual-username/gitops-demo.git.
  • Make sure you selected Public when creating the repository. Private repositories require authentication to clone.
  • If you see a warning about cloning an empty repository, that is expected and safe to ignore.

Help me troubleshoot my git clone command.

Add Kubernetes manifests to the repository

Now you will create the Kubernetes manifests that define your application's desired state. These YAML files tell Kubernetes exactly what to run and how to expose it.

  • Create a k8s directory inside your gitops-demo folder by running:
mkdir k8s
  • Confirm the directory exists by running:
ls

You should see k8s in the output.

  • Create a file called k8s/deployment.yaml in your code editor and paste the following content:
# Defines the nginx Deployment with 2 replicas
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  # Start with 2 pods running nginx
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.27
        ports:
        - containerPort: 80

What does this manifest do?

  • The Deployment resource tells Kubernetes to run and maintain a set of identical pods.
  • The replicas: 2 field means Kubernetes will keep exactly 2 nginx pods running at all times.
  • The selector and labels fields connect the Deployment to its pods using the app: nginx label.
  • The image: nginx:1.27 field pulls the official nginx container image from Docker Hub.
  • Save k8s/deployment.yaml.
  • Confirm the file exists by running:
ls k8s/

You should see deployment.yaml listed.

Don't see deployment.yaml?

  • Make sure you saved the file inside the k8s folder, not in the root of gitops-demo.
  • Check the file name is exactly deployment.yaml with no extra spaces or extensions.

Help me find my deployment.yaml file.

  • Create a file called k8s/service.yaml in your code editor and paste the following content:
# Exposes the nginx pods internally via ClusterIP
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP

What does this Service do?

  • A Service provides a stable network endpoint for accessing your pods.
  • The ClusterIP type makes the Service reachable only within the cluster. This is the default and most common type for internal communication.
  • The selector: app: nginx field routes traffic to any pod with the matching label from your Deployment.
  • Save k8s/service.yaml.
  • Confirm both files exist by running:
ls k8s/

You should see both deployment.yaml and service.yaml listed.

Missing one of the files?

  • Verify both files are inside the k8s/ directory, not in the repository root.
  • Check for typos in the file names. They must be exactly deployment.yaml and service.yaml.

Help me check my k8s directory structure.

✔️ Awesome, I've got everything!

Great. Make sure both files are saved before moving on.

ⓧ I'd like to double check the full code

Here is the complete k8s/deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.27
        ports:
        - containerPort: 80

Here is the complete k8s/service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP
Push the manifests to GitHub

Your manifests exist locally but Argo CD watches the remote repository on GitHub. You need to commit and push your files so they appear in the remote.

  • Stage all your new files by running:
git add .
  • Commit the files with a descriptive message by running:
git commit -m "Add nginx deployment and service manifests"
  • Push the commit to GitHub by running:
git push origin main

What if my default branch is called master?

Some Git configurations use master instead of main as the default branch name. If git push origin main fails, try git push origin master instead.

  • Go back to your gitops-demo repository page on GitHub in your browser.
  • Refresh the page.

You should see the k8s folder listed with deployment.yaml and service.yaml inside it.

Push rejected or authentication failed?

  • GitHub requires a personal access token (not your password) for HTTPS authentication. Generate one at Settings > Developer settings > Personal access tokens if prompted.
  • If you see "error: src refspec main does not match any", your branch might be called master. Run git branch to check your branch name.
  • Make sure you committed your files before pushing. Run git status to check.

Help me push my code to GitHub.

Your Git repository is now the single source of truth for your application. Next up, you will connect this repository to Argo CD and watch it deploy your application automatically.

Deploy Your Application with Argo CD

Your Kubernetes manifests are sitting in GitHub, but your cluster has no idea they exist. To bridge this gap, you need to tell Argo CD exactly where to look.

In Argo CD, you do this by creating an Application resource. This is a custom Kubernetes object that tells Argo CD which Git repository to watch and where to deploy the resources it finds.

In this step, get ready to:
  • Create an Argo CD Application manifest pointing to your GitHub repository.
  • Trigger the first sync to deploy nginx to your cluster.
  • Explore the application topology in the Argo CD dashboard.
Create an Argo CD Application

An Application resource is the core building block of Argo CD. It defines the connection between a Git repository (your source of truth) and a destination cluster (where resources get deployed).

  • In your terminal, make sure you are inside your gitops-demo folder.
  • Create a new file called application.yaml in the root of your gitops-demo folder (not inside k8s/) by running:
touch application.yaml
  • Confirm the file exists by running:
ls

You should see application.yaml and the k8s folder listed in the output.

  • Open application.yaml in your text editor and paste the following manifest:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx-gitops-demo
  namespace: argocd  # Application resources must live in the Argo CD namespace
spec:
  project: default
  source:
    repoURL: [[YOUR_REPO_URL="https://github.com/your-username/gitops-demo.git"]]
    targetRevision: HEAD  # Track the latest commit on the default branch
    path: k8s  # Folder containing your Kubernetes manifests
  destination:
    server: https://kubernetes.default.svc  # Deploy to the same cluster Argo CD runs in
    namespace: default

What does this manifest do?

This Application resource tells Argo CD three things:

  • source points to your GitHub repo and the k8s folder inside it. Argo CD will watch this path for any Kubernetes manifests.
  • destination tells Argo CD to deploy those manifests into the default namespace on the same cluster it runs in.
  • targetRevision: HEAD means Argo CD always tracks the latest commit on your default branch.
  • Save application.yaml.
  • Apply the Application to your cluster by running:
kubectl apply -f application.yaml

You should see output confirming the resource was created:

application.argoproj.io/nginx-gitops-demo created
  • Switch back to the Argo CD Web UI at https://localhost:8080.
  • You should see a new application tile called nginx-gitops-demo with a status of OutOfSync.

Why is it OutOfSync?

OutOfSync means Argo CD can see the manifests in Git, but those resources don't exist in your cluster yet. The desired state (Git) and the live state (cluster) don't match. You need to trigger a sync to make them match.

Don't see the application tile?

Make sure you applied the manifest to the argocd namespace. The namespace: argocd line in the metadata is required.

Also confirm your port-forward is still running. If the UI is unreachable, restart it with kubectl port-forward svc/argocd-server -n argocd 8080:443.

Why isn't my Argo CD Application appearing in the Web UI?

✔️ Awesome, I've got everything!

Great. Double check you saved application.yaml and can see the nginx-gitops-demo tile in the Argo CD UI.

ⓧ I'd like to double check the full code

Here is the complete application.yaml for this step:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx-gitops-demo
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-username/gitops-demo.git
    targetRevision: HEAD
    path: k8s
  destination:
    server: https://kubernetes.default.svc
    namespace: default
Sync the application

Your Application is registered but nothing is deployed yet. Syncing tells Argo CD to apply the manifests from Git to your cluster.

  • Log in to the Argo CD CLI by running:
argocd login localhost:8080 --insecure

What will I be prompted for?

The CLI will ask for a username and password. Enter admin as the username and paste the admin password you retrieved in Step 1. The --insecure flag is needed because Argo CD uses a self-signed certificate.

  • Trigger the first sync by running:
argocd app sync nginx-gitops-demo

You should see a table showing each resource being synced, followed by a status summary confirming the sync succeeded.

  • Verify your nginx pods are running by checking the default namespace:
kubectl get pods -n default

You should see two pods with names starting with nginx-deployment in a Running state.

  • Verify the Service was also created by running:
kubectl get svc -n default

You should see nginx-service listed with type ClusterIP.

Pods not showing up?

Make sure your repoURL in application.yaml matches your actual GitHub repository URL exactly. A typo here means Argo CD cannot find your manifests.

Also confirm the repository is public. If it is private, Argo CD needs credentials configured separately.

Help me troubleshoot why my pods aren't appearing after sync

Explore the Argo CD dashboard

Now that your application is synced, the Argo CD dashboard gives you a visual map of every resource it manages.

  • In the Argo CD Web UI, click on the nginx-gitops-demo application tile.
  • You should see the application topology view. This is a visual graph showing your Application at the top, connected to the Deployment, the ReplicaSet, and the individual Pods.
  • Look at the top banner. You should see two indicators: Sync Status showing Synced and Health Status showing Healthy.
  • Click on the nginx-deployment box in the graph to open its detail panel on the right.
  • From the detail panel, you can inspect the resource's live manifest, events, and any diffs between Git and the cluster.

What is the application topology?

The topology view is a directed graph showing the parent-child relationship between Kubernetes resources. Your Application owns a Deployment, the Deployment owns a ReplicaSet, and the ReplicaSet owns individual Pods.

This visual map makes it easy to trace issues. If a Pod is unhealthy, you can follow the graph up to see which Deployment created it.

Your application is live and fully managed by Argo CD. Next up, you will enable automated sync so that pushing a change to Git automatically updates your running cluster.

GitOps in Action - Update via Git

In the last step, you deployed an application through Argo CD by manually triggering a sync. That already removed the need for kubectl apply on your manifests directly.

Now you'll take it further by enabling automated sync. Once enabled, Argo CD will watch your Git repository and automatically apply any changes you push.

In this step, get ready to:
  • Enable automated sync on your Argo CD Application.
  • Push a replica change to GitHub and watch Argo CD apply it automatically.
  • Verify the rolling update without running a single kubectl command to deploy.
Enable automated sync on your Application

Right now, your Argo CD Application only syncs when you manually trigger it. Automated sync tells Argo CD to poll your Git repository and apply changes on its own whenever it detects a new commit.

  • Open application.yaml in your code editor.
  • Add a syncPolicy section at the bottom of the spec block, so the full file looks like this:
# Argo CD Application manifest - connects your Git repo to the cluster
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx-gitops-demo
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-username/gitops-demo.git
    targetRevision: HEAD
    path: k8s
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  # Enable automated sync - Argo CD will apply changes from Git automatically
  syncPolicy:
    automated: {}

What does this code do?

The syncPolicy.automated: {} section tells Argo CD to automatically sync whenever it detects your Git repository has changed.

By default, Argo CD polls your repo every 3 minutes. After you push a change, expect up to a 3-minute delay before Argo CD picks it up and applies it.

  • Save application.yaml.
  • Apply the updated manifest to your cluster by running this command:
kubectl apply -f application.yaml
  • Switch back to the Argo CD Web UI at https://localhost:8080.
  • Click on your nginx-gitops-demo application.
  • You should see Sync Policy now showing Automated in the application details panel.

Don't see Automated in the sync policy?

Make sure the syncPolicy block is indented under spec (two spaces in from spec:). YAML is whitespace-sensitive, so incorrect indentation will silently ignore the section.

Also confirm you ran kubectl apply -f application.yaml and saw the resource updated message in your terminal.

Help me troubleshoot automated sync not appearing

✔️ Awesome, I've got everything!

Great. Double check you saved application.yaml and applied it with kubectl.

ⓧ I'd like to double check the full code

Here is the full application.yaml at this point:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx-gitops-demo
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-username/gitops-demo.git
    targetRevision: HEAD
    path: k8s
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  syncPolicy:
    automated: {}
Push a change to Git and watch Argo CD react

This is the heart of GitOps. You will make a change in your Git repository, and Argo CD will detect and apply it without any manual intervention.

  • In your code editor, open k8s/deployment.yaml.
  • Find this line:
  replicas: 2
  • Change 2 to 4, so the line now reads:
  replicas: 4
  • Save k8s/deployment.yaml.
  • Commit and push the change to GitHub by running these commands:
git add .
git commit -m "Scale nginx to 4 replicas"
git push

What happens next?

Argo CD polls your GitHub repository every 3 minutes. Once it detects the new commit, it will automatically compare the live cluster state against the updated manifest and trigger a sync.

You do not need to run any kubectl command or click anything in the UI. Argo CD handles the entire deployment for you.

  • Return to the Argo CD Web UI.
  • Watch your nginx-gitops-demo application. Within about 3 minutes, the status will briefly show OutOfSync and then flip to Synced as Argo CD applies your change.

Speed up the wait

If you do not want to wait for the polling interval, you can manually trigger a sync in the UI by clicking Sync and then Synchronize. For this project, waiting confirms that automated sync truly works on its own.

Still showing OutOfSync after 5 minutes?

Confirm your git push succeeded by checking your repository on GitHub. The k8s/deployment.yaml file should show replicas: 4.

If the push worked but Argo CD still has not synced, verify that automated sync is enabled (check the previous substep). You can also click Refresh in the Argo CD UI to force a repository poll.

Help me troubleshoot automated sync not triggering

Verify the rolling update

Once Argo CD finishes syncing, your cluster should now be running 4 nginx pods instead of 2. Let's confirm the update landed.

  • Verify the pods are running by running this command:
kubectl get pods
  • You should see 4 pods with names starting with nginx-deployment, all showing Running status.
  • Confirm the deployment replica count by running:
kubectl get deployment nginx-deployment
  • The READY column should show 4/4.

What should I see in the Argo CD UI?

In the Argo CD dashboard, click on your nginx-gitops-demo application to open the details view.

Under Sync History, you will see a new entry showing the automated sync that just ran. The application topology will now display 4 pods connected to the nginx-deployment node.

  • In the Argo CD UI, click on your application and review the Sync History tab.
  • Notice how the most recent sync was triggered automatically, not manually. The entire update happened purely because you pushed a commit to Git.

Only seeing 2 pods?

If the pod count has not increased, Argo CD may not have synced yet. Check the Last Sync timestamp in the UI to confirm whether the sync occurred after your push.

If the sync ran but pods are still at 2, open the application events in the UI to check for errors. A common cause is a YAML syntax error in the deployment file (e.g., replicas:4 without a space after the colon).

Help me figure out why my replica change did not take effect

You just experienced the core promise of GitOps. Your Git repository is the single source of truth, and Argo CD keeps your cluster in sync automatically. Next up, you will put this to the ultimate test by intentionally breaking your cluster and watching Argo CD fix it.

Secret mission

Self-Healing and Drift Detection

Your GitOps pipeline deploys from Git automatically. But what happens when someone bypasses Git and makes a change directly on the cluster? In production, this is called drift. Enable self-healing and intentionally break your cluster to watch Argo CD fix it automatically.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely on your local Docker Desktop Kubernetes cluster, so there are no ongoing cloud costs. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

  • Argo CD running in the argocd namespace on Docker Desktop Kubernetes.
  • Application resources (nginx-deployment and nginx-service) in the default namespace.
  • Argo CD CLI binary installed on your system.
  • Local project files (gitops-demo folder on your Desktop).
  • GitHub repository (gitops-demo).

Keep everything running

No action needed. Choose this if you are still actively building or experimenting with GitOps workflows.

  • Argo CD will continue syncing from your GitHub repo every 3 minutes.
  • No cloud cost is incurred since everything runs locally on Docker Desktop.
  • The port-forward process stays active in your terminal. If you close that terminal, the Web UI at https://localhost:8080 will stop. Re-run the port-forward command to restore access.

Pause - I'll come back to this later

Stop Docker Desktop to free up system resources. Everything will resume when you restart it.

  • Press Ctrl+C in the terminal running the port-forward to stop it.
  • Right-click the Docker Desktop icon in your system tray and select Quit Docker Desktop.
  • When you restart Docker Desktop and enable Kubernetes, all your pods and services will come back automatically.
  • Re-run the port-forward command to access the Argo CD UI again.

Delete - I don't want to use this again

Remove all project resources completely and start fresh.

  • Press Ctrl+C in the terminal running the port-forward to stop it.
  • Delete the Argo CD Application (this also removes managed resources in the default namespace) by running:
kubectl delete -f application.yaml
  • Delete the entire Argo CD installation by running:
kubectl delete namespace argocd
  • Delete the local project files by running:
cd ~/Desktop
rm -rf gitops-demo

Windows users

If you are on Windows, use this command instead to remove the project folder:

cd $env:USERPROFILE\Desktop
Remove-Item -Recurse -Force gitops-demo
  • Remove the Argo CD CLI binary. Delete the argocd-windows-amd64.exe file from the directory where you placed it. Then remove that directory from your PATH by opening Environment Variables in Windows Settings and editing the Path variable.
  • Delete the GitHub repository. On GitHub, navigate to your gitops-demo repository.
  • Click Settings.
  • Scroll down to the Danger Zone section and click Delete this repository.
  • Follow the confirmation prompts to complete the deletion.

That's a Wrap!

That's a Wrap!

Nice work! You have built a complete GitOps delivery pipeline using Argo CD on a local Kubernetes cluster.

You've learned how to:

  • Installed and configured Argo CD on a local Kubernetes cluster with full Web UI access.
  • Deployed an application entirely through Git without running a single manual kubectl apply.
  • Enabled automated sync and observed Argo CD perform a rolling update triggered purely by a Git push.
  • Secret Mission: Enabled self-healing, intentionally created drift, and watched Argo CD automatically restore the desired state.

Ready to quiz yourself?