How It Works

The Control Plane Model

Infragnite is a control plane — it sits above your existing tools and provides a unified management layer. It does not replace any of them. See What is Infragnite for the high-level architecture.

Each provider connection uses that provider’s own API — the same API you’d use from their dashboard or CLI. Infragnite doesn’t install agents on your servers, inject sidecars into your containers, or proxy your traffic.

Connecting a Provider

1. Add an instance — provide your API credentials for the provider (token, API key, kubeconfig, etc.)
2. Infragnite discovers resources — it reads the provider’s API to find what exists
3. Resources appear in your dashboard — you can now browse, monitor, and manage them alongside everything else

That’s it. No migration, no import ceremony, no configuration language to learn. If a resource already exists at the provider, Infragnite adopts it implicitly.

State Philosophy

Most infrastructure tools maintain a state file that is the source of truth. If the state file and reality diverge, you have a problem. You need to manage state locking, state backends, and state migrations.

Infragnite takes a different approach:

The provider API is the source of truth. Infragnite’s state is a cache.

This means:

• No state files to manage, lock, or migrate
• No risk of state corruption
• Resources that exist at the provider are automatically visible
• If Infragnite’s cache is lost, it rebuilds from the provider API

Drift detection works by comparing Infragnite’s understanding of desired state against what the provider API actually reports. When they diverge, you see a drift and decide what to do about it.

What Happens When You Make a Change

Every modification follows the same flow:

1. You request a change — deploy an app, update a config, remediate a drift
2. Infragnite creates a change request — showing exactly what will change, field by field, with cost impact
3. An authorized user approves — or rejects, with the reason captured
4. Infragnite applies the change — calling the provider’s native API
5. The result is recorded — in the audit log, with who, what, and when

No infrastructure changes happen silently. Everything goes through the approval pipeline and is traceable.

What Happens If You Stop Using Infragnite

Nothing breaks.

• Your Kubernetes deployments keep running
• Your Grafana dashboards stay up
• Your DNS records don’t change
• Your Docker Compose stacks continue
• Your servers keep serving traffic

Infragnite is not in the runtime path. It’s a management and visibility layer. Removing it is like closing a dashboard — the things it was showing you are still there.

Compare this to:

• PaaS (Heroku, Railway, Render) — your app stops running if you leave
• Portainer / Rancher — containers keep running, but management is gone
• Terraform — infrastructure keeps running, but state file becomes orphaned

Infragnite is closest to the Terraform model, except there’s no state file to orphan. The provider API was always the source of truth.