Skip to main content

​
The big picture

Niro is organized around a simple model:
An organization is the top-level container for your fleet. Members of an organization can see and manage all clusters in that org. For MSP use cases, organizations form a tree — a parent org’s members can see all child orgs’ clusters.

​
Concepts at a glance

​
Data flow

Understanding how data moves through Niro helps reason about latency and consistency:

​
Heartbeat (cluster → Niro)

Every ~15 seconds the agent posts a heartbeat containing:
  • Node inventory (name, status, roles, Kubernetes version, CPU/memory capacity and usage)
  • Pod inventory (phase, restarts, owner, resource requests/limits/usage, images, probe config)
  • Kubernetes Warning events (recent window)
  • Capabilities the agent has been granted (logs, apply, self-update)
Niro processes the incoming data, updates the cluster snapshot, runs policy checks, and evaluates incident conditions.

​
Commands (Niro → cluster)

Commands travel in the opposite direction via a persistent connection the agent maintains to Niro. When a command is ready, Niro delivers it over that connection. This means all traffic is outbound from the cluster — no inbound ports are needed. Commands include applying or removing manifests, streaming pod logs, and liveness checks.

​
Dashboard polling

The dashboard refreshes every 5 seconds for live fleet state. The fleet overview page loads a static shell instantly and streams the live cluster data on first load, after which the client takes over for live updates.

​
Next steps

Clusters

How clusters are registered, enrolled, and monitored.

Agents

How the in-cluster agent works, what it can do, and how to configure capabilities.

Deployments

How workloads are managed, applied, and rolled back.

Environments

How environment tagging affects policy severity and standards checks.
Last modified on June 11, 2026