Learn GitOps with ArgoCD - Creating Your First Application

#Introduction

This is the moment you've been waiting for since episode 0: creating your first Application. All the earlier material — GitOps, ArgoCD architecture, manifests, installation, UI and CLI — now comes together in a single hands-on flow. After this episode, you'll see GitOps "magic" for yourself: push to Git, and the cluster follows.

We'll do three things in sequence: prepare a Git repository containing the manifests, create the Application (via the UI, the CLI, then declaratively), and perform the first sync along with verification in Kubernetes.

#Preparing the Git Repository

The structure of the manifest repository for our lab — a single isolated api application:

gitops-lab/
├── manifests/
│   └── api/
│       ├── namespace.yaml
│       ├── deployment.yaml
│       └── service.yaml
└── README.md

Example contents of deployment.yaml (plain manifest, no templating):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: production
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: ghcr.io/arman/api:v1.0.0
          ports:
            - containerPort: 8080

Commit and push all files to the main branch:

git add manifests/
git commit -m "feat: add api application manifests"
git push origin main

#Creating an Application through the UI Wizard

Open the UI → click New Application. Fill in the wizard:

• General — Application Name: api; Project: default; Sync Policy: choose Manual for now so we can control the first sync.
• Source — Repository URL: your Git URL; Path: manifests/api; Branch: main.
• Destination — Cluster URL: https://kubernetes.default.svc (in-cluster); Namespace: production.
• Click Create, and the Application appears on the dashboard.

Notice: its status is immediately OutOfSync — because the definition in Git has never been applied to the cluster.

#Creating an Application through the CLI

The same thing can be done from the CLI with a single command:

argocd app create api \
  --repo https://github.com/arman/gitops-lab.git \
  --path manifests/api \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace production

If you already created it via the UI, the command above will fail with already exists — try another application name, e.g. api-via-cli.

#The Application Declaratively

This is the approach that best fits the GitOps spirit: the Application itself is written as YAML. Save it as application.yaml:

application.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/arman/gitops-lab.git
    path: manifests/api
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated: {}

Apply it to the cluster, and ArgoCD automatically creates the Application:

kubectl apply -f application.yaml
argocd app list

#First Sync

Run the first synchronization:

argocd app sync api
argocd app get api

Watch the output of argocd app get api: Sync Status changes from OutOfSync to Synced, and Health Status becomes Healthy.

#Verifying in Kubernetes

Don't just take the dashboard's word for it — prove it in the cluster:

kubectl get all -n production
kubectl get deployment api -n production -o wide

#Testing the GitOps Loop

This is the final and most important test. Change replicas in deployment.yaml to 4, commit, and push:

git commit -am "chore: scale api to 4 replicas"
git push origin main
argocd app sync api
kubectl get pods -n production

ArgoCD detects OutOfSync, you approve the sync, and the cluster follows Git. That's the loop you'll enjoy forever.

#Closing

Your first Application is now alive:

• A Git repository containing the manifests: one single source of truth.
• Create the Application via the UI wizard, the CLI, or declarative YAML.
• A manual first sync turns OutOfSync → Synced and Healthy.
• Verify independently with kubectl before trusting the dashboard.
• Push to Git → sync → the cluster changes: the GitOps loop works.

Everything is still manual — you press the sync button every time. In episode 7 we'll automate this: sync strategies and policies, auto-sync with prune, self-healing, sync windows, sync options, sync phases and waves, and health assessment. See you there!