Platform

I run GitLab self-hosted. Not because it’s trendy, but because I want to own my CI/CD pipeline. No vendor can change pricing, deprecate features, or access my code without my knowledge. This is sovereignty applied to CI/CD. And GitLab makes it practical. Let me show you how to build a complete pipeline: from code commit to running in Kubernetes. Why Self-Hosted GitLab? Before we dive into pipelines, the “why” matters: Data sovereignty: Your code, your builds, your artifacts stay on your infrastructure No usage limits: Unlimited CI minutes, unlimited storage, unlimited users Network locality: Builds run close to your clusters, faster artifact transfers Customization: Configure runners exactly how you need them Air-gap capable: Works in offline environments The trade-off is operational overhead. You maintain GitLab. For me, that’s worth it. ...

GitOps promises that Git is the source of truth. But what if someone kubectl edits a deployment? What if a mutating webhook changes a resource? What if the cluster silently diverges from what Git says it should be? This is configuration drift, and it’s one of the most insidious problems in Kubernetes operations. ArgoCD can help you detect it — if you configure it correctly. What Is Configuration Drift? Drift happens when the actual state of your cluster differs from the desired state in Git. ...

You start with one ArgoCD Application. Then five. Then twenty. Before you know it, you’re managing hundreds of Applications, and the manual overhead is killing your productivity. The App-of-Apps pattern solves this: one root application that manages all other applications. This is how I structure every GitOps repository, and it scales from homelab to enterprise. The Problem: Application Sprawl When you first adopt ArgoCD, you create Applications manually: kubectl apply -f apps/frontend.yaml kubectl apply -f apps/backend.yaml kubectl apply -f apps/database.yaml # ... repeat for every service This works for small deployments. But it creates problems: ...

Your cluster is gone. Complete failure. The cloud region is down, the hardware died, or someone ran the wrong terraform destroy. Everything is gone. Now what? If you’ve been doing GitOps right, the answer is: spin up a new cluster, point ArgoCD at Git, wait. Your entire infrastructure recreates itself. This is the ultimate promise of GitOps: Git is your backup. Why GitOps Changes Disaster Recovery Traditional DR involves: Regular backups of cluster state Backup storage (etcd snapshots, Velero backups) Tested restore procedures Recovery time measured in hours GitOps DR is different: ...

“Should I use ArgoCD or Flux?” I’ve been asked this question dozens of times. The honest answer: both are excellent. The real question is which fits your context better. I use ArgoCD. But that’s a choice based on my specific needs, not a universal truth. Let me explain both tools, their philosophies, and help you decide. The Core Philosophy Difference Before comparing features, understand the fundamental difference in approach: ArgoCD is application-centric. You define Applications that point to Git sources. ArgoCD manages them through a central control plane with a UI. ...