<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>ArgoCD in production on Tom Meurs</title>
    <link>https://tommeurs.nl/en/series/argocd-in-production/</link>
    <description>Recent content in ArgoCD in production on Tom Meurs</description>
    <generator>Hugo</generator>
    <language>en</language>
    <copyright>© Tom Meurs</copyright>
    <lastBuildDate>Fri, 20 Jun 2025 10:00:00 +0200</lastBuildDate>
    <atom:link href="https://tommeurs.nl/en/series/argocd-in-production/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>ArgoCD for Beginners: Your First GitOps Deployment</title>
      <link>https://tommeurs.nl/en/posts/argocd-beginners/</link>
      <pubDate>Sun, 16 Mar 2025 19:15:00 +0100</pubDate>
      <guid>https://tommeurs.nl/en/posts/argocd-beginners/</guid>
      <description>&lt;p&gt;Here is the thing I never want to do again: ask a cluster what it is running and not trust the answer. For years that was normal. Someone ran &lt;code&gt;kubectl apply&lt;/code&gt;, maybe from a laptop, maybe from a CI job nobody could find anymore, and the live state slowly drifted away from anything written down. When I switched to GitOps, that whole category of uncertainty disappeared. I push to Git, and the cluster converges to match. If I want to know what is deployed, I read a file.&lt;/p&gt;</description>
    </item>
    <item>
      <title>ArgoCD vs Flux: When to Choose What</title>
      <link>https://tommeurs.nl/en/posts/argocd-vs-flux/</link>
      <pubDate>Fri, 28 Mar 2025 21:33:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/argocd-vs-flux/</guid>
      <description>&lt;p&gt;&amp;ldquo;Should I use ArgoCD or &lt;span class=&#34;def&#34; tabindex=&#34;0&#34; data-def=&#34;The other GitOps engine next to ArgoCD. Controllers in the cluster reconcile from Git with no UI of its own, where ArgoCD leads with one.&#34;&gt;Flux&lt;/span&gt;&#xA;?&amp;rdquo;&lt;/p&gt;&#xA;&lt;p&gt;I get this question over coffee, in Slack, in PR comments, probably once a week. People want me to declare a winner so they can stop thinking about it and go build something.&lt;/p&gt;&#xA;&lt;p&gt;Here is my bias, up front, so you can weigh everything that follows: I run ArgoCD on my own clusters. I have a few years of it under my belt and I like it. That preference is going to leak through no matter how careful I am, so I am telling you now instead of pretending I am neutral.&lt;/p&gt;</description>
    </item>
    <item>
      <title>App-of-Apps Pattern in ArgoCD: Scalable GitOps Architecture</title>
      <link>https://tommeurs.nl/en/posts/argocd-app-of-apps/</link>
      <pubDate>Mon, 21 Apr 2025 20:18:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/argocd-app-of-apps/</guid>
      <description>&lt;p&gt;My homelab started with one ArgoCD Application. Then a handful. The day I caught myself running &lt;code&gt;kubectl apply -f&lt;/code&gt; for the fifteenth time to register yet another Application, I knew I&amp;rsquo;d built the exact thing I was trying to avoid: manual steps I had to remember, in an order I had to remember, with no record of what should exist.&lt;/p&gt;&#xA;&lt;p&gt;The App-of-Apps pattern fixes that with one idea. You create a single root Application by hand, and it creates everything else. After a cluster wipe I can rebuild the whole thing with one &lt;code&gt;kubectl apply&lt;/code&gt;. That property is the entire reason I run it, and it&amp;rsquo;s the same reason I self-host in the first place: I want the repository to be the truth, not my memory.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Drift Detection with ArgoCD: How to Know If Your Cluster Is Still in Sync</title>
      <link>https://tommeurs.nl/en/posts/argocd-drift-detection/</link>
      <pubDate>Sat, 03 May 2025 19:27:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/argocd-drift-detection/</guid>
      <description>&lt;p&gt;The whole pitch of GitOps is that Git is the source of truth. That promise holds right up until someone runs &lt;code&gt;kubectl edit&lt;/code&gt; on a deployment at 2am to stop an incident, a mutating webhook quietly rewrites a resource, or a half-finished sync leaves your cluster somewhere between what Git wanted and what it got. Now Git says one thing and the cluster does another, and nobody told you.&lt;/p&gt;&#xA;&lt;p&gt;That gap is configuration drift, and it is the part of GitOps people forget to defend. The good news: &lt;a href=&#34;https://argo-cd.readthedocs.io/&#34;&gt;ArgoCD&lt;/a&gt; already watches for it. The catch is that the defaults don&amp;rsquo;t do what you probably assume, and a few of them will bite you. This post walks from the simplest possible drift check up to the setup I actually run, one layer at a time. Stop wherever you have enough.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Progressive Delivery with Argo Rollouts: Canary and Blue-Green Deployments</title>
      <link>https://tommeurs.nl/en/posts/argo-rollouts-progressive-delivery/</link>
      <pubDate>Fri, 20 Jun 2025 10:00:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/argo-rollouts-progressive-delivery/</guid>
      <description>&lt;p&gt;A standard Kubernetes Deployment had served me well for a long time. Push a new image tag, watch the pods roll, done. It was simple, it was declarative, and most of the time nothing went wrong. The rolling update even gave me a warm feeling of safety: old pods only get torn down once new ones are ready.&lt;/p&gt;&#xA;&lt;p&gt;That feeling is a lie. A rolling update protects you from pods that fail to start. It does nothing to protect you from pods that start perfectly and then serve broken responses. The container is healthy, the readiness probe is green, and your new code is quietly returning 500s to every single user. Within seconds, 100% of your traffic is hitting code that nobody validated under real load.&lt;/p&gt;</description>
    </item>
    <item>
      <title>GitOps Disaster Recovery: Rebuilding Your Cluster from Git</title>
      <link>https://tommeurs.nl/en/posts/gitops-disaster-recovery/</link>
      <pubDate>Wed, 09 Apr 2025 19:52:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/gitops-disaster-recovery/</guid>
      <description>&lt;p&gt;For a couple of years my homelab cluster ran without much drama. Nodes came and went, workloads shifted around, and the worst I ever had to deal with was the occasional pod stuck in &lt;code&gt;CrashLoopBackOff&lt;/code&gt;. The kind of stable where you stop thinking about what happens if it all goes away.&lt;/p&gt;&#xA;&lt;p&gt;Then one evening I ran a &lt;code&gt;terraform destroy&lt;/code&gt; against the wrong workspace. By the time I noticed, the control plane was gone. Not degraded. Gone.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
