Set Up GitOps with ArgoCD

By Khimananda Oli | Last reviewed: August 2026

Manual kubectl apply workflows and imperative CI scripts create configuration drift that breaks production environments during audits and incidents. To eliminate this fragility, you must set up GitOps with ArgoCD, establishing your Git repository as the single source of truth for cluster state. This approach replaces error-prone push-based deployments with a pull-based reconciliation loop that continuously enforces desired state.

How Do You Set Up GitOps with ArgoCD on Kubernetes?

The most reliable way to set up GitOps with ArgoCD in 2026 is using the official Helm chart. While raw manifests exist, Helm allows you to version-control the ArgoCD installation itself, applying the same GitOps principles to the tool managing your GitOps. Before starting, ensure you have a running Kubernetes cluster (v1.27+) and helm v3.14+ installed. For teams new to this paradigm, understanding the broader context of declarative Kubernetes deployments helps avoid common architectural mistakes during initial setup.

Install ArgoCD via Helm

Add the official Argo project repository and install the controller into a dedicated namespace. Using the ha (high availability) values file is recommended even for staging clusters to validate production-like behavior early.

helm repo add argo https://argoproj.github.io/argo-helm
helm repo update

kubectl create namespace argocd

helm install argocd argo/argo-cd \
  --namespace argocd \
  --version 7.8.0 \
  --set server.extraArgs[0]="--insecure" \
  --wait

The --insecure flag disables TLS termination at the ArgoCD server level, which is standard practice when terminating TLS at an ingress controller like Nginx or AWS ALB instead. Never expose the ArgoCD API server without TLS in production; always place it behind a managed ingress with valid certificates.

Access the Dashboard and Retrieve Credentials

After installation, retrieve the initial admin password from the auto-generated secret and port-forward the service for local access:

argocd admin initial-password -n argocd

kubectl port-forward svc/argocd-server -n argocd 8080:443

Navigate to https://localhost:8080 and log in with username admin. Immediately change this password and configure SSO via OIDC or SAML. In regulated environments, I disable the local admin account entirely after SSO is verified to enforce centralized identity management and simplify SOC 2 evidence collection.

How Do You Configure Applications and Repositories in ArgoCD?

Once ArgoCD is running, you define what to deploy by registering Git repositories and creating Application resources. A common mistake when users first set up GitOps with ArgoCD is mixing application definitions with infrastructure code in the same directory. Separate them: keep platform tooling (monitoring, ingress, cert-manager) in one repo path and business applications in another. This separation enables independent sync policies and RBAC boundaries.

Register a Git Repository

You can add repositories via CLI or declaratively. The declarative approach is preferred because it makes the repository configuration itself part of your GitOps workflow:

apiVersion: v1
kind: Secret
metadata:
  name: my-app-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  url: https://github.com/myorg/k8s-manifests.git
  type: git
  # For private repos, use SSH key or token
  # sshPrivateKey: |
  #   -----BEGIN OPENSSH PRIVATE KEY-----
  #   ...

Apply this manifest to your cluster. ArgoCD detects the label and registers the repository automatically. For organizations managing multiple teams, consider using the AppProject resource to restrict which repositories and namespaces each team can access, enforcing least-privilege access patterns consistent with IAM best practices.

Define an Application Resource

The Application CRD tells ArgoCD where to find manifests and where to deploy them. Here is a production-ready example using Kustomize for environment-specific overlays:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payment-service-prod
  namespace: argocd
spec:
  project: payments
  source:
    repoURL: https://github.com/myorg/k8s-manifests.git
    targetRevision: HEAD
    path: apps/payment-service/overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: payments-prod
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - PrunePropagationPolicy=foreground

Key fields explained:

• automated.prune: Deletes cluster resources no longer present in Git. Without this, orphaned resources accumulate silently.
• automated.selfHeal: Reverts manual kubectl edit changes within minutes. Essential for maintaining Git as the authoritative source.
• syncOptions.CreateNamespace: Creates the target namespace if missing, reducing bootstrap friction.

How Do You Manage Secrets Securely in ArgoCD GitOps?

Never commit plaintext secrets to Git. When you set up GitOps with ArgoCD, integrate a secrets management solution that decrypts values at sync time. The three most viable options in 2026 are External Secrets Operator (ESO), Sealed Secrets, and SOPS with age/GPG keys. Your choice depends on existing infrastructure and compliance requirements.

For Nepal-based fintech companies handling sensitive financial data under local regulatory frameworks, SOPS with age keys stored in a hardware security module or ESO backed by AWS Secrets Manager provides the strongest audit trail. Both approaches ensure decrypted secrets never touch disk unencrypted and remain invisible in Git history. Refer to the detailed guide on secrets management with HashiCorp Vault if your organization already operates Vault infrastructure.

Configure SOPS Integration

To use SOPS with ArgoCD, mount your age private key as a Kubernetes secret and configure the repo server to decrypt during manifest generation:

apiVersion: v1
kind: Secret
metadata:
  name: sops-age-key
  namespace: argocd
stringData:
  keys.txt: |
    AGE-SECRET-KEY-1...

Then update your ArgoCD Helm values to enable the SOPS plugin and mount the key into the repo server pod. Encrypted files in your repo should follow the naming convention *.enc.yaml so ArgoCD knows to decrypt them before applying.

How Does the ArgoCD Reconciliation Loop Handle Drift and Sync?

Understanding the reconciliation mechanism is critical when you set up GitOps with ArgoCD. Unlike CI pipelines that push changes once, ArgoCD runs a continuous control loop that compares live cluster state against Git-desired state every three minutes (configurable). When drift is detected, the behavior depends on your sync policy.

Sync Waves and Hooks for Ordered Deployments

Complex applications require ordered deployment: databases before APIs, APIs before frontends. ArgoCD supports this through sync waves and resource hooks. Annotate resources with argocd.argoproj.io/sync-wave: "1" to control execution order. Lower numbers sync first.

apiVersion: batch/v1
kind: Job
metadata:
  name: db-migration
  annotations:
    argocd.argoproj.io/hook: PreSync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  template:
    spec:
      containers:
        - name: migrate
          image: myorg/payment-db-migrate:v2.4.1
          command: ["./migrate", "--target", "latest"]
      restartPolicy: Never
  backoffLimit: 1

This PreSync hook runs database migrations before any application pods are updated. The HookSucceeded delete policy ensures completed jobs don't clutter the namespace. Always test hooks in staging first; a failed PreSync hook blocks the entire sync, which is intentional but requires proper error handling and timeout configuration.

What Are the Production Best Practices When You Set Up GitOps with ArgoCD?

Running ArgoCD in production demands discipline beyond basic installation. These practices come from operating GitOps across multi-account AWS environments and hybrid on-premises clusters serving both global and Nepal-based clients.

1. Use AppProjects for multi-tenancy: Never run all applications under the default project. Create projects per team or environment with explicit restrictions on allowed repositories, destinations, and RBAC roles. This prevents accidental cross-environment deployments and simplifies compliance scoping.
2. Enable auto-sync cautiously: Start with manual sync for production workloads until your team trusts the reconciliation loop. Enable automated sync only after validating that self-heal correctly reverts unintended changes and prune safely removes deprecated resources without cascading failures.
3. Monitor ArgoCD itself: Expose Prometheus metrics from the application controller and set alerts on sync failures, health degradation, and reconciliation duration. A broken ArgoCD instance means no deployments; treat it as tier-0 infrastructure with its own SLOs and runbooks.
4. Version-lock everything: Pin Helm chart versions, container image tags, and Kustomize base references. Floating tags like latest or branch names like HEAD defeat reproducibility. Use semantic versioning and tag commits explicitly.
5. Implement progressive delivery: Pair ArgoCD with Argo Rollouts for canary or blue-green deployments. Automated sync alone doesn't guarantee safe releases; combine GitOps with traffic-shifting strategies validated by automated analysis. Teams adopting AI-assisted operations can explore AIOps integration to enhance rollout analysis with anomaly detection.

Multi-Environment Directory Structure

Adopt a consistent repository layout that scales from staging to production across regions:

k8s-manifests/
├── apps/
│   └── payment-service/
│       ├── base/
│       │   ├── deployment.yaml
│       │   ├── service.yaml
│       │   └── kustomization.yaml
│       └── overlays/
│           ├── staging/
│           │   ├── kustomization.yaml
│           │   └── replicas-patch.yaml
│           └── prod/
│               ├── kustomization.yaml
│               ├── resources-patch.yaml
│               └── hpa.yaml
├── platform/
│   ├── monitoring/
│   ├── ingress/
│   └── cert-manager/
└── argocd/
    ├── appprojects/
    └── applications/

This structure keeps base configurations DRY while allowing environment-specific overrides. Store ArgoCD Application and AppProject manifests in the argocd/ directory and let ArgoCD manage itself — yes, GitOps for GitOps. This meta-pattern ensures your ArgoCD configuration survives cluster rebuilds and remains auditable.

Conclusion

When you set up GitOps with ArgoCD correctly, you gain deterministic deployments, complete audit trails, and automatic drift correction that transforms how your team operates Kubernetes. Start with a single non-production application, validate the reconciliation behavior, then expand systematically using AppProjects and layered Kustomize overlays. Remember that GitOps is a discipline, not just a tool: enforce code review on all manifest changes, monitor the controller as critical infrastructure, and integrate secrets management from day one. If your team needs guidance architecting a compliant, production-grade GitOps platform tailored to your infrastructure, reach out to discuss your specific requirements.