↓Skip to main content

GitOps: Workload Sync with Docker vs In-Place Sync

·1 min

When implementing GitOps for dynamic content like static sites, you have two main approaches: Docker-based deployments and in-place git-sync. Here’s what I learned deploying a Hugo site to Kubernetes.

Docker Approach #

How it works:

  1. Content change triggers CI/CD pipeline
  2. Build Docker image with content baked in
  3. Push to registry
  4. Kubernetes pulls new image and does rolling update
  5. Old pod stays running until new pod is ready

Pros: Zero-downtime deployments, immutable artifacts, battle-tested pattern

Cons: Slower (2-3 minutes: build + push + pull), requires image registry

In-Place Git-Sync Approach #

How it works:

  1. Git-sync sidecar polls repository (e.g., every 5 seconds)
  2. Detects changes and pulls latest commit
  3. Rebuild process runs in same pod
  4. Updated content served immediately

Pros: Fast updates (10-15 seconds total), no image registry needed, simpler infrastructure

Cons: 5-10 seconds of downtime during rebuild, more complex setup (permissions, worktrees, dependencies)

The Key Tradeoff #

The fundamental difference is availability during updates:

Docker: 2-3 minutes to deploy, zero downtime (old version serves traffic while new version starts)

Git-sync: 10-15 seconds to deploy, 5-10 seconds downtime (single container rebuilds in-place)

For production services requiring high availability, Docker’s zero-downtime rolling updates are essential. For personal blogs where brief unavailability during deploys is acceptable, git-sync’s faster iteration cycle is worth it.