Pull-Based GitOps: Why Flux Reduces Both Compute and Cognitive Load

Push vs Pull: A Trust Model Difference

Most CI/CD systems push changes to production. Jenkins runs a job, authenticates to your cluster, and applies changes. GitHub Actions does the same. CircleCI, GitLab CI—all push-based.

This creates a security boundary problem: your CI system needs production credentials. If CI is compromised, production is compromised.

Flux inverts this model. The cluster pulls its own configuration from git. CI never touches production. The trust boundary shifts.

How Flux Actually Works

Flux runs inside your Kubernetes cluster. It watches your git repository. Every few minutes (configurable), it checks: does the cluster state match what's in git?

If not, Flux reconciles the difference. Resources are created, updated, or deleted to match git. Manual changes get reverted. Git is the source of truth, enforced continuously.

What this means operationally:

CI pipelines never need production credentials
Manual changes don't persist (drift is automatically corrected)
Every change is auditable (it's a git commit)
Rollback is git revert followed by automatic reconciliation

The Credential Problem, Solved

Before Flux, our GitHub Actions needed:

Kubernetes API credentials for the test cluster
Kubernetes API credentials for the production cluster
Secrets for each environment, stored in GitHub

This is a lot of high-privilege credentials floating around. Every engineer with repo access could potentially see or use them. Every supply chain vulnerability in the CI pipeline was an exposure.

With Flux:

GitHub Actions build containers, push to registry—that's it
No production credentials in CI
Flux (running in production) pulls the image and applies configuration
Credentials stay inside the cluster

The attack surface reduction is substantial. Compromise CI, and you can poison the container registry—but you can't directly access production infrastructure. It's not perfect security (no such thing), but it's a meaningful improvement.

SOPS: Encrypted Secrets in Git

"You can't commit secrets to git" is conventional wisdom. SOPS (Secrets OPerationS) challenges that.

SOPS encrypts secret values while leaving structure readable:

apiVersion: v1
kind: Secret
metadata:
  name: database-credentials
stringData:
  password: ENC[AES256_GCM,data:Zq7X...,iv:abc...,tag:def...,type:str]

The file is committed to git. The encrypted value is useless without the decryption key. Flux has the key (stored as a Kubernetes secret, never committed). During reconciliation, Flux decrypts automatically.

What you gain:

Secret management follows the same workflow as everything else (git PR, review, merge)
Audit trail for secret changes (who changed what, when)
Disaster recovery includes secrets (reproduce the entire cluster from git + decryption key)

The tradeoff: Key management is now your responsibility. We use age keys, rotated annually, backed up securely. It's overhead, but less than managing secrets across multiple systems.

Self-Healing: The Cognitive Load Benefit

Before GitOps, if someone manually changed a production setting, that change persisted. You'd discover it later—maybe during an incident—and wonder: who changed this? Why? Is it intentional or accidental?

With Flux, manual changes get reverted within minutes. The cluster continuously reconciles toward git. This is self-healing infrastructure.

The psychological benefit is larger than you'd expect. You can trust the cluster. You know what's running (look at git). You know manual changes won't stick. This reduces anxiety.

When you're on call at 3 AM debugging an incident, you're not wondering if someone made an undocumented change. The running state matches git. That certainty reduces cognitive load meaningfully.

Resource Efficiency: Fewer CI Runners

Push-based CI means every deployment runs a CI job. That job needs compute: a VM or container, running for minutes, authenticating, applying changes, then terminating.

Flux runs continuously, consuming ~100-200MB RAM and minimal CPU. One Flux controller handles dozens of applications. The compute cost is fixed and small.

Rough math: Before Flux, our GitHub Actions deployment jobs consumed maybe 10-15 minutes of runner time per deployment. At ~20 deployments per day, that's 200-300 minutes of compute. Flux runs continuously but uses less total compute than 30 minutes of CI runners.

This isn't massive savings, but it's directionally positive. Less compute means lower cost and lower carbon footprint.

The Human Sustainability Angle

Better sleep is a legitimate operational metric.

With push-based deployments, you're responsible for every step. Build fails? You fix it. Deployment script breaks? You fix it. Credentials expire? You fix it at 2 AM when a deployment fails.

With Flux, the system is self-reconciling. Most failures are transient—Flux retries automatically. Configuration errors are caught in pull requests (dry-run validation). The system tolerates temporary failures gracefully.

This changes on-call quality. Issues still happen, but the system is more resilient by default. You're debugging application logic, not deployment mechanics. That's a better use of human attention.

Getting Started with Flux

If you want to try this model:

# Bootstrap Flux in your cluster
flux bootstrap github \
  --owner=your-org \
  --repository=your-repo \
  --path=clusters/production \
  --personal

# This sets up Flux to watch your repo's clusters/production directory
# Put Kubernetes manifests there, commit, push
# Flux applies them automatically

Start simple: one application, standard Kubernetes manifests. Once you understand the pattern, add SOPS for secrets, then expand to more applications.

The learning curve is real but manageable. The operational benefits—security, auditability, reduced cognitive load—compound over time.

Sources:

#gitops #flux #sops #security #operationalexcellence