> ## Documentation Index
> Fetch the complete documentation index at: https://docs.niro.cx/llms.txt
> Use this file to discover all available pages before exploring further.

# Agent Capabilities

> Reference for opt-in agent capabilities — logs, apply, and self-update.

## Overview

The Niro agent starts with a **read-only** RBAC role. Additional capabilities are opt-in — you enable them by re-running the installer with the appropriate environment flag. Each capability grants a specific set of RBAC permissions and unlocks corresponding features in the dashboard.

Capabilities are **additive and reversible**: setting a flag to `1` adds the RBAC grant; setting it to `0` removes it. No enrollment token is needed for capability changes — the agent reuses its existing key.

## Enabling capabilities

Re-run the installer with the flags you want:

```bash theme={"theme":{"light":"github-light","dark":"vesper"}}
# Enable log streaming
curl -fsSL https://get.niro.cx/install.sh | NIRO_ENABLE_LOGS=1 sh

# Enable manifest apply
curl -fsSL https://get.niro.cx/install.sh | NIRO_ENABLE_APPLY=1 sh

# Enable agent self-update
curl -fsSL https://get.niro.cx/install.sh | NIRO_ENABLE_SELF_UPDATE=1 sh

# Enable multiple capabilities at once
curl -fsSL https://get.niro.cx/install.sh | NIRO_ENABLE_LOGS=1 NIRO_ENABLE_APPLY=1 sh
```

The updated RBAC takes effect immediately. The new capability appears in the dashboard within \~15 seconds (on the next heartbeat).

## Revoking capabilities

Set any flag to `0` to revoke the corresponding RBAC grant:

```bash theme={"theme":{"light":"github-light","dark":"vesper"}}
# Revoke log streaming
curl -fsSL https://get.niro.cx/install.sh | NIRO_ENABLE_LOGS=0 sh

# Revoke apply capability
curl -fsSL https://get.niro.cx/install.sh | NIRO_ENABLE_APPLY=0 sh
```

## Capabilities reference

### `NIRO_ENABLE_PODS` (default: on)

Controls whether the agent includes pod details in its heartbeat.

| Default               | `1` (enabled)                                      |
| --------------------- | -------------------------------------------------- |
| **RBAC**              | `get`, `list`, `watch` on `pods` in all namespaces |
| **Dashboard feature** | Pod inventory page, pod details in cluster view    |
| **Set to `0`**        | Pod inventory page is blank for this cluster       |

Pod listing is enabled by default because it's read-only and low-risk. You'd only disable it if you have a compliance reason to prevent Niro from seeing pod names or images.

***

### `NIRO_ENABLE_LOGS`

Enables live pod log streaming to the browser.

| Default               | `0` (disabled)                            |
| --------------------- | ----------------------------------------- |
| **RBAC added**        | `get` on `pods/log` in all namespaces     |
| **Dashboard feature** | **View logs** button on pod detail panels |
| **Required for**      | [Stream Pod Logs](/guides/pod-logs)       |

When enabled, the agent can receive log stream commands from Niro and stream the output of `kubectl logs --follow` back to the browser.

<Note>
  Log streaming establishes a `pods/log` SubResource access on your cluster. This means Niro will have access to your pod logs. Only enable this if your security model permits Niro to access application logs.
</Note>

***

### `NIRO_ENABLE_APPLY`

Enables applying Kubernetes manifests from the Niro dashboard and GitOps flow.

| Default               | `0` (disabled)                                                                                                                                                                              |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **RBAC added**        | `create`, `update`, `patch`, `delete` on managed namespaced resources (Deployments, StatefulSets, Services, Ingresses, ConfigMaps, Secrets, PVCs, HPAs); `create` and `patch` on Namespaces |
| **Dashboard feature** | **Apply to cluster** in Visual Builder, auto-apply on PR merge, Secret and ConfigMap management                                                                                             |
| **Required for**      | [Deploy an App](/guides/deploy-app), [GitOps](/guides/gitops), [Manage Secrets and ConfigMaps](/guides/secrets-configmaps)                                                                  |

<Warning>
  The apply role includes `delete` for managed namespaced resources so Niro can remove resources you delete in the dashboard and clean up managed objects during sync. Namespaces are never deleted by Niro.
</Warning>

***

### `NIRO_ENABLE_SELF_UPDATE`

Allows the agent to update itself to the version specified by Niro.

| Default               | `0` (disabled)                                                     |
| --------------------- | ------------------------------------------------------------------ |
| **RBAC added**        | `patch` on the `niro-agent` Deployment in `niro-system`            |
| **Dashboard feature** | Automatic agent version rollout; version shown in cluster settings |
| **Required for**      | Fleet-wide agent version management                                |

When this is enabled:

1. Niro signals the desired agent version in the response to each status update
2. If the agent's current image tag doesn't match, the agent patches its own Deployment's image tag
3. Kubernetes rolls out the new pod; the old pod terminates
4. The new pod reports the updated version on its first heartbeat

<Note>
  Self-update replaces the running pod. There's no in-place upgrade — the pod is replaced as part of a normal Kubernetes rollout. If you have a single replica (the default), there's a brief gap between the old pod terminating and the new pod becoming ready.
</Note>

***

## Default RBAC (always granted)

Even without any opt-in capability flags, the agent always has:

```yaml theme={"theme":{"light":"github-light","dark":"vesper"}}
rules:
  - apiGroups: [""]
    resources: ["nodes", "namespaces", "events", "pods"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments", "statefulsets", "daemonsets", "replicasets"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["metrics.k8s.io"]
    resources: ["nodes", "pods"]
    verbs: ["get", "list"]
```

This is sufficient to:

* Report node inventory in heartbeats
* Report pod inventory in heartbeats
* Report resource usage (if metrics-server is installed)
* Report Kubernetes Warning events in heartbeats

## Checking enabled capabilities

The dashboard shows a capabilities badge on the cluster card in the Fleet view and in the cluster settings. You can also check directly:

```bash theme={"theme":{"light":"github-light","dark":"vesper"}}
kubectl get clusterrolebinding -n niro-system | grep niro
```

Or inspect the agent's heartbeat in the logs:

```bash theme={"theme":{"light":"github-light","dark":"vesper"}}
kubectl logs -n niro-system -l app=niro-agent | grep capabilities
```

## Related

* [Connect a Cluster](/guides/connect-cluster) — install the agent and set capability flags
* [Stream Pod Logs](/guides/pod-logs) — using `NIRO_ENABLE_LOGS`
* [Deploy an App](/guides/deploy-app) — using `NIRO_ENABLE_APPLY`
* [Manage Secrets and ConfigMaps](/guides/secrets-configmaps) — app configuration resources
* [Agents](/concepts/agents) — how the agent works