We had ArgoCD running perfectly. Every deployment was reconciled from Git. Drift detection worked. Rollbacks were one-click. Our GitOps setup was clean.

Developers still couldn't provision a staging environment without pinging the platform team.

That gap — between "GitOps in place" and "developers can actually self-serve" — is where most platform engineering teams get stuck. GitOps solves a real problem. It just doesn't solve all the problems people think it solves.

What GitOps Actually Solves

Let's be precise, because GitOps deserves credit where it's due.

ArgoCD (17k+ GitHub stars) and Flux are excellent tools for one specific job: keeping your cluster state in sync with what's declared in Git. They watch a repository, detect drift between desired and actual state, and reconcile continuously.

This is genuinely valuable:

• Deployment consistency — no more "works on my machine, breaks in prod" config drift
• Rollback — revert a deployment by reverting a commit
• Audit trail for deployments — Git history shows who changed what
• Multi-cluster sync — apply the same manifests across clusters reliably

If you're not using GitOps, you should be. It's the right tool for deployment reconciliation.

The problem is what it doesn't do.

What GitOps Doesn't Solve

Environment Provisioning

GitOps syncs what exists. It doesn't create environments on demand.

When a developer needs a staging environment for a new feature, someone still has to:

• Create the namespace
• Apply RBAC bindings for the right team
• Provision the database (Postgres StatefulSet, PVC)
• Set up Redis
• Configure the ingress
• Wire the secrets

ArgoCD will happily sync your app manifests into that environment once it exists. But the environment itself? That's a manual job. On most teams, it falls to a senior engineer — the same one handling incidents and architecture decisions.

According to IDC research, engineers spend 20-40% of their time on infrastructure tasks rather than product work. Environment provisioning is a significant chunk of that.

Developer Self-Service

ArgoCD's UI is ops-facing. It shows application sync status, resource trees, and deployment history. It's built for platform engineers who understand Kubernetes internals.

A junior developer who needs a staging environment to test their PR doesn't know what an ApplicationSet is. They shouldn't have to. GitOps doesn't abstract the complexity — it just moves it to a Git repository.

Self-service means a developer can request and get an environment without understanding the underlying infrastructure. GitOps is a prerequisite for self-service, not a substitute for it.

Cost Visibility

GitOps has no concept of cost. ArgoCD doesn't know or care that a namespace has been running idle for three weeks with a Postgres StatefulSet consuming $180/mo in compute and storage.

It syncs state. Idle state is still valid state.

Without an active cost layer, idle environments accumulate invisibly. Flexera's 2025 State of the Cloud report found that organizations waste up to 32% of their cloud budget on idle and overprovisioned resources. GitOps doesn't address this — it can't.

Idle Environment Cleanup

Related: ArgoCD syncs to desired state, but desired state doesn't expire. A staging environment created for a PR that merged six weeks ago is still "desired" as far as ArgoCD is concerned, because nobody updated the Git repository to remove it.

A single idle environment — Postgres, two API replicas, a load balancer — costs $180-250/month. Multiply by the number of forgotten staging branches in a typical team and you have a significant bill with no corresponding value.

Incident Diagnosis

When something breaks, GitOps tells you what changed in terms of deployments. It doesn't aggregate logs, analyze resource metrics, or suggest root causes.

kubectl describe pod and log diving are still your primary tools. GitOps doesn't change that.

The IDP Layer

An Internal Developer Platform sits above your GitOps tooling and fills these gaps:

• Environment provisioning — declarative environment specs that create namespaces, RBAC, databases, and services automatically
• Developer self-service — a UI (or CLI) that developers can use without Kubernetes knowledge
• Cost visibility — per-namespace, per-team cost attribution with real numbers
• Idle detection — AIOps that identifies abandoned environments and either flags or auto-removes them
• Incident diagnosis — log aggregation and LLM-based root cause analysis

Crucially: an IDP doesn't replace GitOps. It uses GitOps. The environments an IDP provisions are managed by ArgoCD. The two tools operate at different layers.

How Fortem Works With ArgoCD

Fortem is a Kubernetes Operator that manages environment lifecycle. When a developer creates a FortemEnvironment resource, the Operator provisions the namespace, RBAC, and constituent services. ArgoCD then syncs the application manifests into that environment.

apiVersion: fortem.dev/v1alpha1
kind: FortemEnvironment
metadata:
  name: feature-payments-v2
  namespace: team-backend
spec:
  template: microservice-stack
  services:
    - name: payments-api
      image: registry.internal/payments:pr-442
    - name: postgres
      preset: postgres-15-small
    - name: redis
      preset: redis-7-ephemeral
  ttl: 72h

ArgoCD watches the namespace Fortem creates and syncs the application config. When the TTL expires, Fortem tears down the environment — including notifying ArgoCD to remove the associated Application.

The separation is clean: Fortem owns the environment lifecycle, ArgoCD owns the deployment sync. Neither duplicates the other's job.

Key Takeaways

• GitOps solves deployment consistency and drift detection. It doesn't solve environment provisioning, developer self-service, cost visibility, or idle cleanup.
• The gap between "GitOps in place" and "developers can self-serve" is real and significant — it's where 20-40% of engineering time gets consumed.
• An IDP operates at a different layer than GitOps. They're complementary, not competing.
• If your platform team is still manually provisioning environments for developers, you have a self-service gap that GitOps alone won't close.

If this gap sounds familiar, Fortem is a self-hosted Kubernetes IDP that installs as a single Helm chart — no dedicated platform team required. Free tier available.