GitOps vs DevOps: Which Approach Does Your Team Actually Need?

TL;DR

• GitOps and DevOps aren't competing approaches, since GitOps is a dedicated practice that implements DevOps goals for infrastructure
• DevOps is a broad culture spanning planning through operations; GitOps is narrower: Git as the single source of truth with automated reconciliation.
• The practical difference shows up in scope, source of truth, and versioning, not in whether a team uses one or the other exclusively.
• Most teams running IaC at any real scale already practice a form of GitOps whether they've named it that or not.
• StackGuardian implements the GitOps reconciliation loop directly in its Workflow engine, so adopting GitOps doesn't mean stitching together a separate CI/CD pipeline, Git watcher, and drift tool.

Two terms, GitOps and DevOps, get used almost interchangeably in job postings and conference talks, but they describe genuinely different things at genuinely different scopes. Consider a platform team at a mid-size fintech running its core banking APIs on Kubernetes and Terraform. They call themselves a DevOps team, and rightly so, since they plan, ship, and operate software as one coordinated group instead of two teams throwing work over a wall. But whether they're practicing GitOps depends on something more specific: does a pull request into their infrastructure repo actually change what's running, automatically, or does someone still SSH into a box or click through a console after the PR merges?

This post follows that same team through the rest of the piece to keep the distinction concrete: what each term actually means, how a real GitOps workflow runs step by step, where the two genuinely diverge, where they overlap, and how StackGuardian implements the GitOps reconciliation loop directly rather than requiring a separate stack of tools bolted together.

What Is GitOps?

GitOps is the practice of using a Git repository as the single source of truth for infrastructure, configuration, and policy. Everything that defines the desired state of a system, including resource definitions, security rules, and deployment settings, lives as declarative code in that repository, and a tool continuously compares the repository's content against what's actually running, reconciling any difference automatically.

Back to the fintech platform team. Their payments service needs a new security group rule to accept traffic from a partner's IP range. Under GitOps, that change is a diff to a .tf file, aws_security_group_rule with the new CIDR block, opened as a PR. Nobody logs into the AWS console and clicks "add rule." The rule doesn't exist until the PR merges, and once it does, a tool picks up the change and applies it without anyone running a command by hand.

Terraform and OpenTofu are the most common tools that implement this pattern for infrastructure. Argo CD and Flux implement the same idea for Kubernetes workloads, continuously watching a repository and applying manifest changes as they land. What this buys the team in practice: the security group change went through the same review a code change would, including a diff, a reviewer, and a merge. If that CIDR range turns out to be wrong, reverting it means restoring the previous commit, not remembering exactly what the rule looked like before.

What Is DevOps?

DevOps is the cultural and technical practice of bringing development and operations closer together to improve how software gets delivered, enable faster releases, reduce incidents, and tighten feedback loops between the people writing code and the people running it in production.

For the same fintech team, DevOps shows up less as a specific tool and more as how the security group change actually got proposed in the first place. The engineer who needed the new rule didn't file a ticket and wait a week for someone else to make the change. They opened the PR themselves; a security reviewer commented that afternoon, and it merged the same day. That's the DevOps culture piece: shared ownership and fast feedback, sitting underneath the GitOps mechanics that actually applied the change.

The lifecycle DevOps aims to improve breaks into six stages: Plan, defining requirements for a change; Code, writing it; Test, checking it for quality issues; Build, packaging it; Release, deploying it; and Operate, monitoring it once live. DevOps doesn't prescribe a specific tool for any of these stages; it's a set of goals and a culture of shared responsibility, not a technical specification. A team could run every one of these stages manually and still be practicing DevOps, however poorly, because unlike GitOps, DevOps requires no dedicated tooling.

How a GitOps Workflow Actually Runs

Following that security group rule through the full sequence:

1. The engineer writes the change, adding the new CIDR block to the existing aws_security_group_rule resource
2. They push it to a branch and open a PR against the main infrastructure repository
3. A CI pipeline runs terraform plan, and a policy check flags anything that looks wrong; in this case, the plan is clean
4. The security reviewer approves the PR after confirming the IP range matches what the partner actually provided
5. The PR merges into main
6. Automated tooling detects the new commit and applies the change to the real security group

Where step six happens splits into two models. Push-based reconciliation triggers immediately on the merge event; a CI/CD pipeline runs terraform apply as part of the same automation that ran the plan. Pull-based reconciliation works differently: a tool like Argo CD or Flux polls the repository independently of any merge event, notices the new commit on its own schedule, and applies it without the CI pipeline itself needing to trigger anything.

The distinction matters for a scenario the fintech team hit six months earlier, before they'd set up drift detection properly. An on-call engineer manually widened a different security group during an incident, meant to narrow it back down afterward, and forgot. Push-based reconciliation alone never would have caught that; nothing merged, so nothing triggered. It sat open for three weeks until a routine security review found it. A pull-based or scheduled reconciliation model checks the live state against the repo on its own cadence, independent of whether anyone pushed anything, and would have flagged that same rule within hours instead of weeks.

Where GitOps and DevOps Actually Diverge

Six categories separate the two cleanly, and the fintech team's security group change touches all six, in ways that build on each other rather than sitting as isolated facts.

Start with scope. The security group change itself stayed narrow, one resource, defined in exactly one file. But the events around it reached much further: the Slack thread where the engineer first flagged the need for the rule, the on-call rotation that eventually caught the earlier drift incident, the retro where the team decided to add scheduled reconciliation. That scope difference shapes everything else.

Because GitOps stays narrow, its processes and tools stay narrow too; in this example, Terraform and a reconciliation tool cover the entire GitOps toolchain. DevOps needed more scaffolding around that same change: a ticketing system, a Slack alert integration, an on-call scheduler, none of which have anything to do with Git-based reconciliation directly, but all of which were load-bearing for how the change actually got proposed and caught when something went wrong.

That broader toolset let the team's automation strategy extend beyond GitOps' own mechanics. The GitOps automation here was specifically push-based reconciliation on merge, plus the pull-based drift check added after the incident. The DevOps automation layered on top of that automated PagerDuty alerts when the on-call engineer's manual fix created an anomaly, and automated Slack notifications when a plan showed unexpected changes, doing work no reconciliation tool by itself would have done.

Underneath all of that sits a difference in source of truth. The security group's desired state lived in exactly one place: the Terraform file in the repo, no ambiguity. The surrounding DevOps practice didn't work that way at all: the team's on-call runbooks lived in a wiki, their incident postmortems in a separate tool entirely. Both were legitimate artifacts of a healthy DevOps practice, and no reconciliation loop watched either one.

That single source of truth is also why versioning worked differently for each. Every version of the security group rule is a commit, inherent to the GitOps model, no extra step required. The postmortem documenting the drift incident wasn't versioned with anywhere near the same rigor. It's a doc that gets edited in place, which fits DevOps in spirit but lacks GitOps' built-in history.

All of this ties back to a difference in goal. GitOps aimed narrowly: get this one resource change applied consistently and safely. DevOps aimed at something the retro made explicit: shorten the time between "we need this rule" and "it's live and correct," which is exactly what justified adding scheduled drift detection afterward, a DevOps goal, implemented through GitOps tooling.

Where GitOps and DevOps Overlap

The fintech team's postmortem is a clean example of where these overlap in practice. The incident review was a DevOps artifact made up of a wiki page, a Slack thread, and a retro, and it concluded the fix should be a GitOps change: add scheduled drift detection so the next manually widened security group gets caught in hours instead of weeks. The retro itself wasn't GitOps. The fix it produced was.

CI/CD pipelines are how most GitOps changes actually get deployed, and CI/CD is itself a core DevOps practice; the same pipeline that ran terraform plan on the security group PR is a DevOps artifact implementing a GitOps mechanism.

IaC and configuration management is the layer GitOps was built for. Terraform reconciling the security group against the repo is GitOps in action, serving the broader DevOps objective of consistent, low-incident infrastructure operations.

Security and governance policy management followed the same pattern once the team matured past just fixing the immediate drift issue. Instead of relying on a human reviewer to catch every risky security group change by eye, they wrote a policy that automatically blocks any rule allowing unrestricted ingress and version-controlled it the same way they version-controlled the security group definition.

Should You Use GitOps, or Is DevOps Enough?

Before the drift incident, the fintech team's setup of push-based reconciliation with no scheduled checks was arguably enough. They were small, changes were infrequent, and a security review caught the problem before it became a breach. That's not a strategy; it's luck, but for a genuinely small team early on, the cost of building full reconciliation rigor can outweigh what it protects against.

That calculus flips once infrastructure changes often enough, or the team grows past the point where everyone informally knows what's currently deployed. The same team, six months after the incident, running twelve engineers and pushing infrastructure changes most days, would take on real risk by running push-only reconciliation again. Regulated environments needing an audit trail, teams past a certain size, and any environment where changes happen often enough that manual tracking becomes its own incident source, all clear the bar where GitOps rigor earns its cost quickly. This isn't a replacement decision. Adopting stronger GitOps practices doesn't mean abandoning DevOps culture; it means applying DevOps goals more rigorously to the infrastructure layer.

How to Improve Your GitOps and DevOps Workflows With StackGuardian

Most teams end up assembling GitOps from separate pieces, as the fintech team originally did: a CI/CD tool for the push half, nothing for the pull half until an incident forces the gap into view, and a policy engine bolted on afterward as a separate project. StackGuardian runs the whole loop inside one Workflow engine instead of requiring that piecemeal buildout.

Workflow Triggers handle the push-based half. Configuring a Workflow's triggers under Source and Parameters → Configurations → VCS Triggers supports a push to the tracked branch, a tag creation, a plan run on updates to all pull requests or only ones targeting the tracked branch, and an option to require plan approval before apply, covering exactly the merge-triggered reconciliation the fintech team's security group example relied on. Triggers are available for GitHub, GitLab, and Bitbucket, not just one VCS provider.

Automated Drift Check is what that team was missing before the incident, and it directly fixes the gap that let a manually widened security group sit undetected for three weeks. It runs on a schedule per Workflow rather than only reacting to a push, and it queues drift runs at a lower priority than user-initiated runs so scheduled checks don't compete with active deployments for execution capacity.

Policy Sets cover the governance improvement the same team added after their retro: the rule blocking unrestricted ingress. Written in Tirith, that policy looks like this:

{
  "meta": {
    "required_provider": "stackguardian/terraform_plan",
    "version": "v1"
  },
  "evaluators": [
    {
      "id": "no-open-ingress-cidr",
      "description": "Block security group rules allowing 0.0.0.0/0 ingress",
      "provider_args": {
        "operation_type": "attribute",
        "aws_security_group_rule": "aws_security_group",
        "cidr_blocks": "ingress.cidr_blocks"
      },
      "condition": {
        "type": "NotEquals",
        "value": "0.0.0.0/0",
        "error_tolerance": 1
      }
    }
  ],
  "eval_expression": "no-open-ingress-cidr"
}

Scoped to the payments team's Workflow Group, this policy automatically evaluates every security group change that runs through a Workflow in that group, regardless of whether the person opening the PR remembers to check for an open CIDR range. Each rule carries one of five statuses: Pass, Fail, Warn, Approval Required, or Unevaluated, so a genuinely risky rule can block outright while a lower-stakes tagging violation just logs a warning.

SGCode addresses a gap the security group story doesn't even touch: infrastructure that predates the GitOps repo entirely. The fintech team's payments service sits on a VPC that was originally clicked together in the console two years before Terraform adoption. A GitOps reconciliation model only reconciles resources that already have a corresponding definition in the repository; it says nothing about resources that were never declared. SGCode's Cloud Inventory discovers that VPC and its dependent resources, generates the Terraform configuration, and publishes it as a pull request, bringing that two-year-old infrastructure into the same GitOps loop the security group rule already runs through.

None of this is scoped to a single engine. Terraform, OpenTofu, CloudFormation, Ansible, Helm, and Kubectl all run as native Workflow types, so the same triggers, drift reconciliation, and policy enforcement apply whether a given Workflow is provisioning the payments VPC or deploying a Kubernetes manifest for the API layer sitting inside it.

What a Full GitOps Loop Looks Like Inside StackGuardian

Putting it all together as one sequence, using the fintech team's setup after they'd fixed their gaps: an engineer opens a PR adding a new security group rule. The Workflow's VCS trigger, configured against the team's GitHub repository, fires on the PR, running Configuration Rules against the plan; the no-open-ingress-cidr policy evaluates the change and passes, since the new rule is properly scoped rather than open to the world. The PR gets reviewed and merged, and the merge triggers the actual apply.

That's the push half, and it's where most teams' GitOps setups stop. For this team, it doesn't. Automated Drift Check keeps running against that same Workflow on its schedule regardless of whether anything merges, so if someone widens that rule manually next quarter during another incident, it surfaces in hours rather than three weeks. Meanwhile, on a separate Workflow entirely, SGCode's Cloud Inventory is still working through the payments VPC's pre-Terraform history, one resource at a time, opening PRs as it goes, each one passing through the same Configuration Rules and policy evaluation as the security group change did.

Three mechanisms inside one Workflow engine cover the same three problems that took the fintech team an incident, a retro, and a separate discovery project to solve piecemeal the first time around.

Conclusion

GitOps isn't replacing DevOps, and it was never meant to. It's DevOps applied with more rigor to one specific layer, infrastructure and its configuration, using Git as the enforcement mechanism rather than trusting the practice to happen informally. The two work together far more often than they compete, and most teams running real infrastructure at scale end up practicing some version of GitOps whether or not they've ever used the term.

The practical question worth asking isn't GitOps versus DevOps. It's whether the tooling in place actually closes the reconciliation loop, catching drift and enforcing policy continuously, or whether it only handles the push half and leaves everything else to manual vigilance until an incident forces the gap into view. That gap is where most GitOps implementations quietly fall short, and it's the specific problem StackGuardian's Workflow engine was built to close.

FAQs

1. Is GitOps part of DevOps?

Yes, GitOps is a subset of DevOps. It's a specific operational model that implements DevOps principles such as automation, version control, and continuous delivery, using Git as the single source of truth for infrastructure and configuration. GitOps is narrower in scope than DevOps, which spans the entire software delivery lifecycle, so the two complement each other rather than compete.

2. Do you still need CI/CD if you're using GitOps?

Yes. GitOps handles the reconciliation half, automatically applying changes once they're merged, but something still needs to build, test, and package changes before they reach that point. CI/CD covers that earlier stage; GitOps picks up from there rather than replacing it.

3. What's the difference between push-based and pull-based GitOps?

Push-based reconciliation triggers a deployment as soon as a change merges, typically through a CI/CD pipeline reacting to the commit event. Pull-based reconciliation works independently of any trigger; a tool like Argo CD or Flux polls the repository on its own schedule and applies changes it finds, catching drift introduced outside any merge event.

4. How does StackGuardian's drift detection fit into a GitOps workflow?

Automated Drift Check runs on a schedule per Workflow, functioning as the pull-based half of the reconciliation loop. It catches infrastructure that's changed outside the pipeline entirely, a manual console edit, for example, which push-based CI/CD triggered only by commits has no way to detect on its own.

5. Can StackGuardian enforce GitOps across multiple IaC engines, not just Terraform?

Yes. Terraform, OpenTofu, CloudFormation, Ansible, Helm, and Kubectl all run as native Workflow types, with the same triggers, drift detection, and policy enforcement applying regardless of which engine a given Workflow uses.