Stop manually patching your WordPress deployments and banish configuration drift by combining ArgoCD’s declarative syncing with Renovate’s automated dependency management.

Stop Babying Your Blog: The Full GitOps Experience with ArgoCD & Renovate

I still wake up in a cold sweat thinking about “The Incident” of 2018. I was working with a junior engineer—let’s call him Tim—who decided to manually patch a WordPress plugin directly on the production pod in prod-cluster-01 to fix a critical styling bug on Black Friday. He logged in, ran the update, and high-fived the marketing team. Ten minutes later, the automated reconciling loop (which we had just implemented but Tim didn’t fully grasp) saw a mismatch between the running state and the Git repo. It ruthlessly reverted the pod to the previous state. The site broke, the styling bug returned, and the database was left in a half-migrated zombie state. That was the day I vowed: If it isn’t in Git, it doesn’t exist.

The “Why”: Why WordPress on K8s is Usually a Dumpster Fire

Hosting stateless microservices on Kubernetes is a dream. Hosting a stateful monolith like WordPress? That’s where the “DevOps” title earns its paycheck. The root cause of the misery isn’t usually Kubernetes itself; it’s the disconnect between application state and infrastructure definition.

When you rely on manual kubectl apply or, heaven forbid, manual updates inside the WP-Admin dashboard, you introduce Configuration Drift. Your cluster thinks one thing, your repository thinks another, and your database is caught in the middle screaming for help. To fix this, we need a Single Source of Truth (GitOps) and a robot butler to handle the tedious updates (Renovate).

The Fixes: From “Hacky” to “Hero”

Here are three ways to tackle this. We start with the manual approach to get you stable, move to the automated workflow, and finally, the heavy artillery for when you’re managing twenty blogs at once.

Solution 1: The Quick Fix (The “Declarative” Start)

First, stop using `kubectl`. We need to define the WordPress application as an ArgoCD object. This forces the cluster to match the Git repository. If someone tries to pull a “Tim” and change things manually, ArgoCD will flag it as OutOfSync or auto-heal it instantly.

We use the Bitnami Helm chart because writing your own WordPress manifests is a waste of billable hours.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: corporate-blog
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://charts.bitnami.com/bitnami'
    targetRevision: 15.2.5
    chart: wordpress
    helm:
      values: |
        mariadb:
          enabled: true
          auth:
            rootPassword: "CHANGE_ME_PLEASE"
        service:
          type: ClusterIP
        ingress:
          enabled: true
          hostname: blog.techresolve.io
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: prod-blog

Pro Tip: Never hardcode passwords in the `values` block like I did above for the demo. Use ArgoCD’s integration with SealedSecrets or ExternalSecrets. If I catch you committing plain-text passwords to GitHub, I’m revoking your merge rights.

Solution 2: The Permanent Fix (Enter Renovate)

The problem with Solution 1 is that `targetRevision: 15.2.5` will eventually become ancient. You don’t want to manually check Artifact Hub every morning. This is where Renovate shines. It watches your repository, detects that the Bitnami chart has an update, and opens a Pull Request automatically.

This turns your infrastructure updates into a code review process. You get a PR saying “Update WordPress from 15.2.5 to 16.0.0”. You read the changelog, click merge, and ArgoCD sees the change in Git and deploys it.

Here is a `renovate.json` configuration that targets your ArgoCD application manifests specifically:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:base"
  ],
  "argocd": {
    "fileMatch": ["applications/.*\\.yaml"]
  },
  "packageRules": [
    {
      "matchPackageNames": ["wordpress"],
      "matchDatasources": ["helm"],
      "automerge": false,
      "labels": ["dependencies", "blog"]
    }
  ]
}

Now, the robot does the grunt work. You just approve the PRs.

Solution 3: The ‘Nuclear’ Option (The App of Apps Pattern)

So you’re successful, and now marketing wants 15 different microsites. Managing 15 separate `Application` YAML files is painful. We use the “App of Apps” pattern. You create one ArgoCD application that points to a folder containing other ArgoCD applications.

This sounds meta, and it is. But it allows you to spin up an entire environment (Ingress Controller, Cert-Manager, External-DNS, and 10 WordPress instances) with a single sync.

Honestly, getting this setup takes an afternoon, but it saves you weeks of panic later. Once you see Renovate open a PR, the tests pass, and ArgoCD syncs it to prod without you lifting a finger, you’ll never go back to manual deployments.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions