Skip to main content
This page covers a full Nyx installation: prerequisites, installing on Linux and Windows nodes, the configuration values the chart accepts, and how to verify, upgrade, and uninstall. If you just want to get running quickly, the Quickstart is the faster path.

Prerequisites

Cluster

  • Linux nodes on the AMD64 architecture, running a kernel of 5.15 or newer (required for eBPF/TC enforcement). Ubuntu-based AKS, EKS, GKE, and self-managed node images are validated. ARM64 isn’t supported yet — the agent schedules only on AMD64 Linux nodes.
  • Windows nodes (optional) — Windows Server 2022. See Add Windows nodes below.
  • Kubernetes 1.27 or newer recommended.

Tooling

  • kubectl, configured for your cluster. Version 1.27+ is needed for the kubectl identity step.
  • Helm 3.8 or newer. OCI registry support is required, which is stable from Helm 3.8.0 onward.

Network

Nyx’s agent connects outbound to your Tracenyx Service Bus endpoint over a single, persistent AMQP-over-TLS connection — it sends data and receives commands on that one connection. Nothing inbound to your cluster is ever required. If your cluster has outbound firewall restrictions, allow: Allowlist your specific endpoint rather than a wildcard, so the rule permits traffic only to your Tracenyx namespace.

Access

You’ll need a Scout key and image pull credentials, both available from your dashboard once you have access. See Quickstart → Create your Scout account for how to request access. If your environment restricts which container registries it can reach, Sentinel and Aegis customers can have Nyx images mirrored to a private registry — contact us to arrange it.

Install on Linux nodes

Copy the install command from your dashboard and run it. It has this shape:
Your dashboard generates this command fully populated with your Scout key and image pull credentials. Copy it from there rather than assembling it by hand — the credentials are unique to your account.
This installs two components into the nyx-system namespace:
  • nyx-agent — a DaemonSet, the kernel-native enforcement engine. One pod runs on every Linux node.
  • nyx-gatekeeper — the admission webhook that validates and authorises policies.

Add Windows nodes

Nyx enforces on Windows nodes through a dedicated chart, nyx-windows, which deploys the nyx-agent-windows DaemonSet. It installs alongside the Linux release in the same nyx-system namespace and shares your Scout key and image registry — the two charts are installed separately so each targets the correct node OS. If you selected Windows nodes during signup, your dashboard shows the Windows install command alongside the Linux one. It follows the same shape:
Windows nodes must be Windows Server 2022. Nyx enforces on Windows through a signed Windows Filtering Platform (WFP) callout driver, deployed by the nyx-agent-windows DaemonSet.

Configuration

The most common values are below. To see everything the chart accepts, run:

Verify the installation

Check that every component came up:
You should see one nyx-agent pod per Linux node, one nyx-agent-windows pod per Windows node (if installed), and one nyx-gatekeeper pod:
Confirm the CRDs registered:
Then open your dashboard — the cluster should appear as connected, with live traffic in the Traffic Map.

Connect your kubectl identity

Nyx’s admission webhook needs to recognise your kubectl user so it can authorise policies you apply from the command line. The dashboard prompts you for this on first login — you can also find it under Settings → My Account. Find your Kubernetes username:
Paste the result into the dashboard and confirm. From this point, applying policies works the same whether you use kubectl or the dashboard, and both appear under the same identity in the audit log.

Upgrading

To upgrade to a newer chart version, reusing your existing configuration:
--reuse-values preserves your Scout key and image credentials. Check the release notes before upgrading across minor versions. If you run Windows nodes, upgrade nyx-windows to the matching version as well.

Uninstalling

Remove the Nyx components:
Uninstalling stops enforcement on every node — traffic returns to your cluster’s default behaviour. Helm leaves the CRDs in place, so your policies are preserved if you reinstall. To remove Nyx completely, including all policies:
Deleting the CRDs permanently removes every NyxNetworkPolicy and NyxClusterNetworkPolicy in your cluster. This cannot be undone. Only do this if you intend to fully remove Nyx.