Prerequisites

Before installing NetBox Enterprise with the netbox-enterprise Helm chart, verify your environment meets these requirements.

Kubernetes Version

The nbe-operator chart requires Kubernetes 1.33 or later. Every chart declares kubeVersion: ">=1.33.0-0", so Helm refuses to install on anything older and sets no upper bound.

kubectl version

OpenShift

Required Tools

Resource Requirements

Cluster Sizing

These recommendations account for the full stack: operator, NetBox application, workers, PostgreSQL, Redis, and Diode components. SSD or NVMe storage is recommended for database performance.

Per-Component Defaults

The chart ships with the following resource defaults. These are starting points; production deployments should allocate resources based on the cluster sizing above.

For Diode components (if enabled):

Registry Access

NetBox Enterprise is distributed through NetBox Labs' Replicated registries: the Helm charts are pulled from registry.enterprise.netboxlabs.com and the container images from proxy.enterprise.netboxlabs.com. Authenticate to the chart registry with your license credentials (your email as the username and your license ID as the password) before installing - the Quickstart and Standard Installation both begin with a helm registry login step.

You do not need to create an image-pull secret by hand. The bundled Replicated SDK provisions the netbox-enterprise-helm-registry pull secret at install time, so every component - including Redis - can pull its image from the proxy registry.

To pull images from your own private registry instead, see Private Registry.

Chart Dependencies

The netbox-enterprise chart automatically installs these dependencies (can be disabled individually):

The Redis Operator chart and image versions differ on purpose. 0.25.0 is the newest chart upstream publishes, and the operator image is pinned ahead of it to v0.26.0, which carries the fix for one unpullable Redis pod stalling master election.

Gateway API CRDs (Gateway Routing Only)

The operator routes external traffic through the Kubernetes Gateway API when gateway routing is enabled in the CR (spec.gateway) and the Gateway API CRDs are present, and falls back to Ingress resources otherwise (see Routing Mode). If you enable the bundled Traefik controller (gateway.enabled: true), install the netbox-enterprise-crds-gateway chart before the main chart:

helm install netbox-enterprise-crds-gateway \
  oci://registry.enterprise.netboxlabs.com/netbox-enterprise/stable-v2/netbox-enterprise-crds-gateway \
  --version 2.4.0 \
  --namespace netbox --create-namespace

The chart vendors the Gateway API v1.5.1 standard CRDs. Skip it if you bring your own Gateway API controller (your cluster already has the CRDs) or stay on the Ingress path. Embedded Cluster installs it automatically.

The upload-size cap (spec.gateway.maxRequestBodyBytes) is enforced through a Traefik Middleware, which needs the traefik.io CRDs. Embedded Cluster ships them automatically via the netbox-enterprise-crds-traefik chart. On Helm with the bundled Traefik controller, install that chart too if you want the cap enforced -- without it the operator skips the Middleware (no cap) and logs a warning. Bring-your-own gateways manage their own traefik.io CRDs.

RBAC Requirements

The operator requires cluster-level or namespace-level RBAC permissions depending on the rbac.scope setting:

• cluster (default): Creates ClusterRole and ClusterRoleBinding. The operator watches for NetBoxEnterprise resources across all namespaces.
• namespace: Creates Role and RoleBinding in the release namespace only. The operator watches only the namespace where it is installed.

Rules the operator needs

The table lists every rule in the ClusterRole that the 2.3.0 and 2.4.0 netbox-enterprise charts create. The chart creates it only when operator.enabled and rbac.create are true and rbac.scope is cluster. A rule marked Always is in every ClusterRole install (rbac.scope: cluster). With rbac.scope: namespace, the chart creates a Role that leaves some of those rules out, as the paragraph after the table explains. A conditional rule is in the role only when the named Helm value is true.

In the Verbs column, all means create, delete, get, list, patch, update and watch. An empty API group cell ("") is the core API group.

The operator needs the garageclusters and garagenodes rules even when in-cluster object storage is off. It reads garageclusters on every reconcile to find a Garage store left over from an earlier configuration.

With rbac.scope: namespace, the chart creates a Role instead, from templates/role.yaml. It holds the namespaced rules from the table and leaves out the cluster-scoped ones, such as customresourcedefinitions, namespaces and nodes.

Managing RBAC yourself

If you set rbac.create: false, the chart creates no role, and you must give the operator's ServiceAccount the rules above yourself. Do not copy the rules from the chart defaults. The conditional rules depend on your values, so render the role from the values file you install with:

REGISTRY=oci://registry.enterprise.netboxlabs.com/netbox-enterprise/stable-v2
VERSION=2.4.0

# rbac.create=true here only makes the template render; it does not change your install.
helm template netbox-enterprise "$REGISTRY/netbox-enterprise" \
  --version "$VERSION" --namespace netbox \
  --values my-values.yaml \
  --set rbac.create=true \
  --show-only templates/clusterrole.yaml

Replace my-values.yaml with your own values file. For rbac.scope: namespace, render templates/role.yaml instead. Render the role again for each new chart version before you upgrade, because a release can add rules.

Persistent Storage

The cluster must have a default StorageClass or you must specify one explicitly. Storage is used for:

• PostgreSQL data (default: 4Gi)
• NetBox media files (default: 10Gi)
• NetBox scripts (default: 1Gi)
• Redis persistence (if enabled)

Next Steps

• Quickstart: Get running in 5 minutes with minimal configuration
• Standard Installation: Full installation with custom values