GitOps with ArgoCD and Crossplane Infrastructure Guide 2026

By /

GitOps ArgoCD Crossplane: Manage Everything Through Pull Requests

Imagine this: a developer opens a pull request that adds a new microservice. The PR includes the application code, Kubernetes manifests, and a database definition. When the PR is merged, the service is automatically deployed, the database is provisioned, and monitoring is configured — all without anyone running kubectl or clicking through a cloud console. That’s GitOps ArgoCD Crossplane in practice.

GitOps: Git as the Source of Truth

GitOps is simple in principle: everything that defines your system — application configurations, infrastructure definitions, networking rules, access policies — lives in Git. A tool continuously compares what Git says the system should look like with what the system actually looks like, and corrects any drift.

This gives you capabilities that manual management can’t match:

  • Audit trail: Every change is a Git commit with an author, timestamp, and description. You can answer “who changed what, when, and why?” for any point in history.
  • Rollback: Reverting a bad deployment is git revert. The GitOps tool sees the reverted state and automatically rolls back the live system.
  • Code review for infrastructure: Infrastructure changes go through the same PR review process as application code. A junior engineer’s Kubernetes manifest change gets reviewed by a senior before applying.
  • Disaster recovery: If your entire cluster dies, point ArgoCD at your Git repository and it recreates everything. The repository IS your system definition.

ArgoCD: Application Delivery

ArgoCD watches your Git repository and synchronizes the Kubernetes cluster to match. When you push a new container image tag to your manifests repository, ArgoCD detects the change and applies it. If someone manually modifies a deployment (kubectl edit), ArgoCD detects the drift and can auto-correct it.

# argocd/applications/order-service.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: order-service
  namespace: argocd
  # Finalizer ensures ArgoCD cleans up resources when the app is deleted
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: production

  source:
    repoURL: https://github.com/company/k8s-manifests
    path: services/order-service/overlays/production
    targetRevision: main

  destination:
    server: https://kubernetes.default.svc
    namespace: commerce

  syncPolicy:
    automated:
      prune: true      # Delete resources removed from Git
      selfHeal: true   # Correct manual changes automatically
    syncOptions:
      - CreateNamespace=true
      - PrunePropagationPolicy=foreground
      - ApplyOutOfSyncOnly=true  # Only apply changed resources
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

  # Health checks — ArgoCD waits for resources to be healthy
  ignoreDifferences:
    - group: apps
      kind: Deployment
      jsonPointers:
        - /spec/replicas  # Let HPA control replicas, not Git

The ignoreDifferences section is critical. Without it, ArgoCD would fight with your Horizontal Pod Autoscaler — ArgoCD wants 3 replicas (from Git), HPA wants 7 replicas (based on load). The ignoreDifferences tells ArgoCD to let HPA control the replica count while managing everything else.

GitOps ArgoCD Crossplane deployment pipeline
ArgoCD continuously reconciles cluster state with Git declarations

Crossplane: Infrastructure as Kubernetes Resources

Crossplane extends Kubernetes with custom resources that represent cloud infrastructure. Instead of writing Terraform and running it separately, you define your database, cache, and queue as Kubernetes resources right alongside your application manifests. ArgoCD deploys them all together.

# infrastructure/databases/order-service-db.yaml
# This creates a REAL RDS instance on AWS — managed through Kubernetes
apiVersion: database.company.io/v1
kind: PostgreSQLInstance
metadata:
  name: order-service-db
  namespace: commerce
spec:
  parameters:
    size: medium        # Maps to: db.r6g.large, 100GB, Multi-AZ
    version: "17"
    backup:
      retentionDays: 30
      window: "03:00-04:00"
  # Connection details automatically written to a Kubernetes Secret
  writeConnectionSecretToRef:
    name: order-service-db-credentials
    namespace: commerce

---
# The application automatically picks up the database credentials
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  template:
    spec:
      containers:
      - name: api
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: order-service-db-credentials
              key: endpoint

Why this is powerful: The database definition lives in the same repository as the application that uses it. When a developer creates a new service from a template, the database is included. When the service is deleted, the database definition is removed and Crossplane deprovisions it. Moreover, the database credentials flow automatically through Kubernetes Secrets — no manual credential management.

GitOps ArgoCD Crossplane: The Unified Workflow

Here’s how it all works together in a real deployment:

  1. Developer opens a PR adding a new service: application code, Kubernetes manifests, and a Crossplane database definition
  2. CI pipeline runs tests, builds the container image, and pushes it to the registry
  3. PR is reviewed and merged to main
  4. ArgoCD detects the change in the manifests repository
  5. ArgoCD creates the Kubernetes Deployment, Service, and Ingress
  6. ArgoCD creates the Crossplane PostgreSQLInstance resource
  7. Crossplane provisions the RDS instance on AWS (takes 5-10 minutes)
  8. Crossplane writes connection credentials to a Kubernetes Secret
  9. The application pod starts and connects to the database using the Secret
  10. ArgoCD reports the application as Healthy and Synced

All of this happens automatically from a single PR merge. No kubectl commands, no AWS console, no manual credential management.

Multi-cluster deployment architecture
A single PR merge triggers application deployment AND infrastructure provisioning

Multi-Cluster Management

ArgoCD ApplicationSets generate applications dynamically across multiple clusters. Define a template once, and it deploys to dev, staging, and production with environment-specific overrides. Furthermore, Crossplane Compositions abstract cloud-specific details — the same PostgreSQLInstance resource works on AWS (RDS), GCP (Cloud SQL), or Azure (Azure Database) by swapping the underlying provider.

Getting Started: Step by Step

  1. Week 1: Install ArgoCD on your cluster. Move one existing service’s manifests to a Git repository. Create an ArgoCD Application pointing to it.
  2. Week 2: Enable automated sync and self-heal. Test: manually change a deployment and watch ArgoCD correct it.
  3. Week 3: Install Crossplane with your cloud provider. Create a Composition for your most common database type. Test provisioning through Git.
  4. Week 4: Create an ApplicationSet for your multi-environment setup. Migrate a second service to GitOps.
GitOps monitoring dashboard
Start small — one service, one cluster — and expand as you gain confidence

Related Reading:

Resources:

In conclusion, GitOps ArgoCD Crossplane unifies application and infrastructure management through Git. Every change is reviewed, auditable, and reversible. Start with ArgoCD for application delivery, add Crossplane for infrastructure, and build toward a fully self-service developer platform.

Scroll to Top