A CNCF survey published in late 2025 found that 64% of organizations with Kubernetes workloads had adopted GitOps practices, up from 47% in 2023. More telling than the adoption number was the reliability metric: 81% of those adopters reported measurably higher infrastructure reliability compared to their pre-GitOps workflows. Those are not marketing numbers from a vendor — that is the Cloud Native Computing Foundation surveying its own community.
But here is the problem those numbers do not capture. Reliability went up. Costs also went up. Many teams that embraced GitOps found themselves deploying infrastructure faster and more reliably than ever — and then getting blindsided by cloud bills that grew 30-40% year over year. Speed without cost awareness is just expensive speed.
That is where FinOps enters the picture. And the convergence of GitOps and FinOps is, in our experience, the most impactful operational shift happening in infrastructure teams right now.
GitOps: A Quick Grounding
For teams that have not made the switch yet, the core idea behind GitOps is straightforward. Your Git repository is the single source of truth for your infrastructure's desired state. Every change — a new deployment, a scaling rule, a network policy, a secret rotation — goes through a pull request. An automated reconciliation loop compares the desired state in Git with the actual state of your infrastructure and corrects any drift.
The two dominant tools are ArgoCD and Flux, both CNCF projects. ArgoCD uses a pull-based model where the cluster watches the Git repository. Flux operates similarly but with a lighter footprint and a more composable architecture. Crossplane extends the GitOps model beyond Kubernetes to manage cloud resources — databases, queues, storage buckets — using the same declarative approach.
What makes GitOps powerful is not any single tool. It is the operational model: every infrastructure change is version-controlled, peer-reviewed, auditable, and automatically applied. No more SSH-ing into servers. No more ad hoc kubectl commands that nobody remembers. No more "who changed this?" investigations that end in finger-pointing.
FinOps: The Missing Half
FinOps is the practice of bringing financial accountability to variable cloud spending. The FinOps Foundation (now part of the Linux Foundation) defines it as a cultural practice — engineering, finance, and business teams working together to make informed tradeoffs between cost, speed, and quality.
In practical terms, FinOps means three things for engineering teams:
First, visibility. You know exactly what each service, team, and environment costs. Not at the end of the month, but continuously. Second, optimization. You act on that visibility — right-sizing instances, eliminating waste, choosing appropriate pricing models (reserved, spot, savings plans). Third, accountability. Teams own their infrastructure costs the way they own their uptime metrics.
The honest answer is that most organizations are still in the visibility phase. A 2025 FinOps Foundation survey found that only 28% of respondents had mature FinOps practices with real-time cost allocation. The majority were still reconciling bills manually or relying on monthly reports from finance.
The Integration: Cost Visibility in Every Pull Request
Here is where things get interesting. When you combine GitOps with FinOps, you get cost impact visibility at the exact moment infrastructure decisions are made — in the pull request.
Consider a typical workflow without this integration. A developer opens a PR to change a Kubernetes deployment. They increase the replica count from 3 to 10 because traffic is growing. The PR gets reviewed for correctness — does the YAML parse? Are the labels right? Does it follow the team's conventions? — and gets merged. ArgoCD applies the change. Three weeks later, the finance team flags a 230% increase in the staging cluster bill. Nobody remembers which change caused it.
Now consider the same workflow with FinOps integrated. The developer opens the same PR. An automated tool — Infracost, Kubecost, or a custom integration — runs against the diff and posts a comment directly on the PR:
## Cost Estimate
Monthly cost will increase from $847/mo to $2,823/mo (+$1,976/mo)
Resource changes:
+ deployment/api-server replicas: 3 -> 10 (+$1,976/mo)
7 additional pods x m5.large ($0.096/hr) = $1,976/mo
This change exceeds the team's $500/mo threshold.
Requires approval from @infra-leads.The cost impact is visible before the merge. The reviewer can ask: do we actually need 10 replicas, or would 6 with horizontal pod autoscaling achieve the same result at 40% of the cost? The decision is made with full information, not in retrospect.
Before and After: A Real-World Scenario
We worked with a client running a multi-tenant SaaS platform on AWS EKS. Their engineering team was excellent — fast deployments, solid test coverage, clean GitOps practices with ArgoCD. But their monthly AWS bill had grown from $34,000 to $89,000 over 14 months, and nobody could explain exactly why.
When we integrated Kubecost with their GitOps pipeline, the picture became clear within the first week. Three patterns accounted for 71% of the overspend:
Oversized resource requests were the biggest culprit. Developers had set CPU and memory requests conservatively high (the "I do not want my pod to get evicted" instinct), and nobody ever right-sized them. The average CPU utilization across all pods was 12%. They were paying for 8x the compute they actually used.
Non-production environments running 24/7 was the second issue. Staging and QA clusters ran at full capacity around the clock, even though they were only actively used during business hours (roughly 10 hours per day). That is 58% wasted spend on non-production infrastructure.
Storage volumes that were never deleted after deployments were torn down accounted for the rest. Persistent volume claims accumulated like digital debt — each one small, but collectively adding up to over $4,000/month.
After implementing automated cost gates in their GitOps workflow and establishing resource budgets per namespace, they reduced their monthly bill to $52,000 — a 42% reduction — without affecting performance or reliability.
Comparison: Traditional Ops vs. GitOps vs. GitOps + FinOps
| Dimension | Traditional Ops | GitOps | GitOps + FinOps |
|---|---|---|---|
| Deployment speed | Hours to days (manual or scripted) | Minutes (automated reconciliation) | Minutes (same speed, with cost gate) |
| Cost visibility | Monthly bill review after the fact | No built-in cost awareness | Real-time cost diffs in every PR |
| Reliability | Dependent on operator skill and documentation | 81% report higher reliability (CNCF 2025) | Same reliability, with cost-aware decisions |
| Audit trail | Scattered across tickets, emails, chat logs | Full Git history with PR reviews | Git history + cost impact records per change |
| Rollback capability | Manual, often incomplete | Automated via Git revert | Automated with cost impact of rollback shown |
| Drift detection | Manual checks or custom scripts | Continuous reconciliation | Continuous reconciliation + cost drift alerts |
| Resource optimization | Periodic reviews (if they happen at all) | Not addressed by default | Continuous right-sizing recommendations |
The Toolchain
Getting this working requires integrating tools from two ecosystems. Here is the stack we recommend based on production experience across multiple client projects.
GitOps Layer
ArgoCD remains our default recommendation for most teams. It has the largest community, the most mature UI, and solid multi-tenancy support. The application sets feature makes it practical for managing hundreds of services. If you are running a single cluster with fewer than 50 services, Flux is lighter and equally capable — it just requires more comfort with CLI-driven workflows.
Crossplane fills the gap that ArgoCD and Flux leave open: cloud resources that live outside Kubernetes. If your infrastructure includes RDS databases, SQS queues, CloudFront distributions, or any other managed service, Crossplane lets you manage them with the same GitOps model. The resource definitions live in Git, get reviewed in PRs, and get reconciled automatically.
FinOps Layer
Infracost is the tool that plugs cost visibility directly into the pull request workflow. It parses Terraform and OpenTofu configurations, calculates the cost impact of changes, and posts the results as PR comments. For teams using infrastructure-as-code alongside GitOps, Infracost is the most straightforward integration.
Kubecost provides runtime cost allocation for Kubernetes workloads. It tracks actual resource consumption per pod, namespace, label, and deployment, and maps it to cloud billing data. Where Infracost tells you what a change will cost before you apply it, Kubecost tells you what your running infrastructure actually costs right now.
CloudHealth (VMware) and Spot by NetApp handle the broader cloud cost optimization picture — reserved instance recommendations, savings plan coverage analysis, and anomaly detection. These are less about the GitOps integration and more about the strategic FinOps practice.
Putting It Together
The pipeline looks like this: a developer commits a change to the infrastructure repository. The CI pipeline runs validation (linting, policy checks, dry-run apply) and then runs Infracost to calculate the cost delta. The results are posted to the PR. If the cost increase exceeds a configurable threshold, additional approvals are required. Once merged, ArgoCD or Flux detects the change and applies it. Kubecost monitors the running cost and alerts if actual spend deviates from the estimate.
# Example: Infracost GitHub Actions workflow
name: Infracost
on:
pull_request:
paths:
- 'infrastructure/**'
jobs:
infracost:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Infracost
uses: infracost/actions/setup@v3
with:
api-key: ${{ secrets.INFRACOST_API_KEY }}
- name: Generate cost diff
run: |
infracost diff \
--path=infrastructure/ \
--format=json \
--out-file=/tmp/infracost.json
- name: Post PR comment
uses: infracost/actions/comment@v3
with:
path: /tmp/infracost.json
behavior: updateThis is roughly 30 lines of configuration. The return on investment — in prevented overspend, in faster cost conversations, in reduced surprise bills — is disproportionately large.
Why This Matters for Agencies
We build and maintain infrastructure for client projects. Every engagement has a budget. Every client cares about what their cloud bill looks like after launch. The traditional model — "we will optimize costs later" — does not work. Later never comes, or it comes after the client has already seen a bill that damages trust.
GitOps + FinOps changes the agency-client dynamic in a meaningful way. We can show clients the exact cost impact of every infrastructure decision, in real time, with a link to the pull request where the decision was made. There is no ambiguity about why the bill changed. There is no finger-pointing. There is a Git commit, a cost estimate, and an approval record.
For agencies managing multiple client environments, this approach also solves the attribution problem. When you run shared infrastructure — a common Kubernetes cluster hosting multiple client workloads, for example — Kubecost's namespace-level cost allocation lets you bill each client accurately for their actual resource consumption, not an estimated split.
Common Objections and Honest Answers
"This adds friction to deployments." To be fair, it does add a step. But the step takes 30-60 seconds to run and saves hours of cost investigation later. The friction is proportional to the risk — a $20/month change sails through; a $5,000/month change gets scrutinized. That is the point.
"Our developers do not care about costs." Then your incentive structure is broken, not the tooling. When developers can see that their PR will increase monthly spend by $3,000, and when the team has a budget they are measured against, they start caring. Visibility creates accountability.
"We are too small for FinOps." If your monthly cloud bill is under $1,000, you probably do not need formal FinOps practices. But if it is over $5,000/month and growing, the return on even basic cost visibility is immediate. We have seen teams recover the cost of implementation within 45 days through waste elimination alone.
"We will just use the cloud provider's cost tools." AWS Cost Explorer, GCP Billing, and Azure Cost Management are useful for retrospective analysis. They do not integrate into your deployment workflow. They tell you what you spent, not what you are about to spend. The proactive model — cost visibility at PR time — is fundamentally different from the reactive model of reviewing dashboards after the money is gone.
Getting Started: A Practical Path
If you are already doing GitOps, adding FinOps visibility is a weekend project, not a quarter-long initiative. Start with Infracost in your CI pipeline if you use Terraform. Add Kubecost to your Kubernetes cluster if you want runtime cost allocation. Set a threshold for cost-increase alerts — we typically start at $200/month per PR for smaller teams and adjust from there.
If you are not doing GitOps yet, start there. The cost visibility integration only works well when infrastructure changes flow through a reviewable, auditable pipeline. Ad hoc infrastructure changes made through cloud consoles or direct CLI commands bypass the entire model.
The teams that get this right in 2026 will have something their competitors do not: the ability to ship fast and explain exactly what it costs. That is not a marginal advantage. In a market where cloud costs are the second-largest line item after payroll for most software companies, it is a strategic one.
CODERCOPS helps teams implement GitOps pipelines with built-in cost visibility, from ArgoCD setup to Infracost integration. If your cloud bill keeps surprising you, talk to our infrastructure team about getting cost control into your deployment workflow.
Comments