Skip to main content
Nyx comes in three tiers — Scout, Sentinel, and Aegis. What they share matters more than what separates them: the same kernel-native enforcement, the same policy model, and the same three enforcement modes run on every tier. Tiers differ in scale and a handful of platform features, and they’re measured by one thing — the number of namespaces you monitor.

​
How usage is measured

The Nyx agent runs as a DaemonSet on every node in your cluster, so enforcement and visibility stay consistent across the whole cluster. But Nyx only collects flow data for the namespaces you choose to monitor. That means your tier is about what you watch, not how large your cluster is:
  • Adding nodes never changes your tier.
  • Adding monitored namespaces does.
A monitored namespace is simply a Kubernetes namespace you’ve enabled in Nyx. You scope monitoring to the namespaces that matter — typically your application workloads — and leave the rest alone.

​
The three tiers

  • Scout — free, for individuals and first clusters. Identity binds to your kubectl user, with no SSO required.
  • Sentinel — for teams standardising on Kubernetes. Adds SSO and RBAC.
  • Aegis — for regulated, multi-cluster estates. Adds Private AI (all AI processing stays inside Tracenyx infrastructure), guided rollout to full policy coverage, a dedicated SLA, and a preferred data region.
For current namespace and cluster limits, the full feature comparison, and pricing, see the pricing page.

​
What’s the same on every tier

No matter which tier you’re on, you get the core of Nyx:
  • Kernel-native enforcement on both Linux (eBPF) and Windows (WFP) nodes.
  • The full policy model — NyxNetworkPolicy, NyxClusterNetworkPolicy, and the priority system.
  • All three enforcement modes: dry-run, audit, and enforce.
On every tier, Nyx sends only anonymised traffic patterns to its AI provider — never raw flow records, pod names, or IP addresses.