A client call last month went like this: “Our investor deck says GitOps. Can you do GitOps?” If you take freelance DevOps work, expect that sentence soon — the word has moved from conference talks into RFPs, and a freelancer who cannot explain it, price it and deliver it is leaving money on the table. The good news: GitOps is one of the easier sells to learn because it is a way of working, not a product. Nobody buys it; teams do it. This primer gives you the working knowledge — the core idea, the vocabulary, the honest judgement about when a small client needs it, and a first-week checklist for the gig where they do.

GitOps, Stripped to the Bones

Here is the whole idea without decoration. The client describes its infrastructure and applications in files. Those files live in a repository that keeps every revision and refuses to forget any of them. A lightweight agent inside the cluster reads the files on a loop and nudges the running system until the two agree. Engineers propose changes as pull requests. Reviewed pull requests get merged. The agent notices the merge and applies it. If someone edits production by hand, the agent notices that too and undoes it. Deployments stop being something people do and become something the repository causes.

That loop has a formal backbone worth knowing for client conversations. The OpenGitOps principles, published under CNCF in 2021, describe the pattern in four moves: state what you want as data; keep that data in a store that cannot be quietly rewritten; let software fetch it rather than letting pipelines push it in; and keep comparing and correcting forever rather than applying once. NIST’s microservices deployment guidance adds the security argument you can quote in a pre-sales call — pushing changes in requires handing cluster credentials to the thing doing the pushing, while a pulling agent keeps credentials inside the boundary it protects. When a client wants receipts, I open the Ops Atlas, xOps School’s reference on GitOps, which gathers the background, the citations and the current tool detail in one place.

The Mini-Glossary to Carry Into Every Meeting

Half of consulting is speaking the client’s dialect. These are the terms that come up in the first week of any GitOps engagement, with the shortest honest definitions I know:

• Desired state — the written description of how things should be. The single source of truth; if it is not in the repository, it does not exist.
• Reconciler (or agent) — the program that pulls the desired state and enforces it. Argo CD and Flux are the two you will meet.
• Sync — one round of the loop: compare, then apply the difference.
• Drift — any difference between the repository and the running system. Drift is not always wrong, which is why it gets a policy, not just an alarm.
• Prune — deleting a resource because it disappeared from the repository. Powerful, occasionally terrifying, and the reason weeks one and two of any engagement run with pruning disabled.
• Secret operator — tooling such as Sealed Secrets or SOPS-encrypted files that keeps credentials usable in deployments without ever committing them in the clear.
• OCI store — a container registry used as the versioned store instead of Git. Same model, different shelf; some teams call the result “Gitless GitOps”.

Notice what is missing from that list: any mention of a licence. Argo CD and Flux are both open source, both CNCF-graduated (Argo in December 2022, Flux the month before), and both fine to install at a client without a procurement cycle — which is exactly why the practice spreads through freelancers.

When a Small Client Should — and Should Not — Bother

Being the person who says “you do not need this yet” is worth money in repeat business. The published comparison work puts it in numbers: in a scoring exercise run for an organisation with ten clusters and several teams, pull-based automated reconciliation came out clearly ahead of alternatives (4.05 versus 3.70 for manual approvals and 2.80 for hardened push pipelines). Run the same exercise for a four-person team with one cluster and the three approaches land within a rounding error of each other — 3.55, 3.60 and 3.50. Translate that into freelance terms: a scale-up with several teams and a real audit posture gets obvious value; a founder, an intern and a staging server get ceremony.

The honest middle ground for small clients: adopt the habits, skip the machinery. Put configuration in a repository, review changes through pull requests, and let a simple sync job apply them on a schedule. Those habits cost nothing and make the eventual full adoption painless — and you look like the consultant who sequenced it properly.

A note on packaging, since the question comes up at every rate discussion. Scope an adoption as a fixed first block — audit, repository design, one reconciler installed, two services migrated, drift policy drafted — followed by a migration retainer billed per service family. Avoid open-ended “we’ll see how it goes” wording; clients hear risk, and you hear unpaid evenings. The fixed block also gives you a natural exit if the client’s readiness turns out to be talk: you leave behind the repository and the habits, the cheap half of the value, and nobody feels short-changed.

The First-Week Checklist on Your Next GitOps Gig

When the engagement is real, this is the order I work in. Steal it:

1. Read the existing repository layout and ask who reviews what. The review map matters more than the tooling map.
2. Check for mutable references — floating image tags like latest, unpinned charts, references that resolve to whatever a remote published last night. Each one is a future outage wearing a disguise.
3. Confirm no secrets sit in plaintext commits, and propose the operator route if they do.
4. Ask to see the drift policy, or write one: which differences get reverted, which are tolerated (autoscalers own their replica counts), which simply alert.
5. Verify the webhook, if one exists, requires a shared secret — the endpoint itself is rate-limit-free and should not be publicly pokeable.
6. Time one change end to end, merge to healthy, and write the number down. You will be judged against improving it.

That last item matters more than it looks. GitOps makes deployment boring, and boring needs evidence: a tracked cycle time, a drift count tending to zero, a rollback rehearsed rather than imagined. Numbers turn your work into a renewal argument.

Adding It to Your Stack Without Panic

If you have never run either tool: install Flux or Argo CD on a throwaway cluster this weekend, point it at a test repository, then break things on purpose — edit the cluster directly, delete a resource, merge something wrong — and watch how each one responds. An afternoon of deliberate breakage teaches more than a course module, and it gives you war stories for client workshops. Then fold the vocabulary into your existing material: our FAQs for new DevOps freelancers cover how to position fresh skills in early client conversations, and once you can demo a reconciliation loop, our piece on building a support network and finding mentors is where the referrals tend to come from. The demand is already in the RFPs; the only question is whether your name is in the reply.