Key Concepts
Organizations
Section titled “Organizations”An organization is the top-level container for your team. It holds your users, roles, and workspaces. Each organization has its own isolated data — nothing is shared between organizations.
If you manage infrastructure for multiple clients (like an agency or consultancy), each client gets their own organization. A single user can belong to multiple organizations and switch between them.
Workspaces
Section titled “Workspaces”A workspace is an environment within an organization — for example, Production, Staging, or Development. Each workspace has its own set of connected providers and resources.
Workspaces let you separate concerns without creating separate organizations. Your team sees the same providers and infrastructure within a workspace, with access controlled by roles.
Boosters (Providers)
Section titled “Boosters (Providers)”A booster is Infragnite’s term for a provider plugin. Each booster connects to one external platform via its native API:
- Cloud providers — DigitalOcean, Hetzner
- DNS & networking — Cloudflare
- Source control & CI — GitHub
- Container orchestration — Kubernetes, Docker
- Monitoring — Grafana, Uptime Kuma
- Reverse proxy — Traefik
- Analytics — Plausible
- Automation — n8n, Windmill
- Identity — Auth0
- Email — Tutanota
To connect a provider, you add an instance — your credentials for that provider within a workspace. Infragnite uses these credentials to communicate with the provider’s API directly. No agents or sidecars are installed on your infrastructure.
Resources
Section titled “Resources”A resource is anything managed by a provider — a server, a DNS record, a Kubernetes deployment, a Grafana dashboard. Infragnite discovers resources from connected providers and shows them in the unified infrastructure browser.
Resources have a type (e.g., droplet, dns_record, deployment), a provider, a status, and properties specific to that resource type.
Drifts
Section titled “Drifts”A drift is a discrepancy between what Infragnite expects and what actually exists at the provider. Drifts are detected automatically and classified by severity:
| Severity | Meaning | Example |
|---|---|---|
| Critical | Unexpected resource found or critical resource missing | An unknown server appeared in your account |
| High | Important configuration changed | A firewall rule was modified outside Infragnite |
| Medium | Non-critical configuration mismatch | A tag or label was changed |
| Low | Minor discrepancy | A description field differs |
Each drift offers remediation actions:
- Import to State — accept the change and adopt the resource
- Remove — delete the unexpected resource
- Ignore — acknowledge and dismiss the drift
Changes
Section titled “Changes”A change is a proposed modification to your infrastructure. When you deploy an application, update a configuration, or remediate a drift, Infragnite creates a change request.
Changes show a visual diff of exactly what will change — field by field, with a cost impact estimate (+$X/mo) — before anything happens.
Approval Workflow
Section titled “Approval Workflow”Changes go through an approval workflow before execution:
- Pending — change is proposed, waiting for review
- Approved — an authorized user approved the change
- In Progress — the change is being applied
- Completed — the change was applied successfully
- Rejected — the change was denied
This ensures no infrastructure modification happens without visibility and explicit consent. The full history is captured in the audit log.
Infragnite uses role-based access control (RBAC) to manage what users can do:
| Role | Can Do |
|---|---|
| Admin | Everything — manage users, approve changes, configure providers |
| Deployer | Deploy applications, manage instances, remediate drifts |
| Planner | Create and review changes and drifts (read-only for everything else) |
| Viewer | Read-only access across the entire workspace |
Custom roles can be defined with fine-grained permissions per resource type and action.
Guardrails
Section titled “Guardrails”Guardrails are safety rules that prevent destructive operations on critical infrastructure. For example, services labeled as critical (like your monitoring stack or reverse proxy) cannot be deleted without explicitly removing the label first.
Guardrails are evaluated automatically before any operation executes — you don’t need to remember to check; the system enforces it.