System requirements & sizing

The host

NetEnds runs as a single-host appliance: one Linux x86_64 server, bare metal or virtual machine, runs the whole stack — the database, the event store, the cache and message broker, the API backend, the polling workers and scheduler, the synthetic prober, the ingest receivers for syslog, flows and traps, and the web server. The host needs Docker Engine 24 or newer with the Compose v2 plugin. Size it before you install; the numbers below decide whether the project fits the box you have.

Reference profiles

Profile	Nodes	vCPU	RAM	Disk (NVMe)
Small / lab	Up to 50	4	16 GiB	200 GB
Reference	About 500	16	64 GiB	1 TB
Large	500–1500	24–32	96–128 GiB	2–4 TB

The reference profile runs the full platform comfortably at about 500 managed nodes with default poll intervals. These profiles do not include Gia or the Lab; both are covered below.

Disk is the dimension that grows without asking. Syslog and flow volume follow your event rate, not your node count: one chatty firewall exporting flows can use more disk than a hundred quiet access switches. Watch the disk trend over the first few weeks. Retention is configurable — see What grows with your fleet.

Gia

Gia’s model server ships inside the release and runs on the same host. Plan for:

Resource	Gia adds
Memory	About 26 GiB
Disk	About 30 GB

A host running the platform plus Gia therefore wants about 88 GiB of RAM rather than 64 GiB.

Without a GPU, Gia runs on CPU: on 16 cores a real multi-step answer takes one to five minutes, and the first answer after a restart also waits for the model to load. With a GPU the answer takes seconds; a GPU with 48 GB of memory holds the whole model. To use one, the host needs an NVIDIA driver and the NVIDIA container toolkit wired into Docker. The installer checks whether Docker can hand the GPU to a container, records the answer, and runs Gia on the GPU when it can. Installing NetEnds shows how to confirm it.

The model stays in memory for 60 minutes after the last question, then releases it. Gia is optional: you can install the platform without it and add it later.

The Lab

The Lab, which runs emulated network topologies, is opt-in. Budget about 4 GB of RAM per running container node and 4–12 GB of disk per network OS image you load. A modest lab on top of the platform and Gia points at about 128 GiB of RAM.

Network OS images for the Lab are licensed by their vendors, so you supply them yourself and upload them in Lab → Image Library.

Nested virtualization — only for VM-based lab images

The Lab runs container-based network OS images (such as Arista cEOS, Nokia SR Linux and Juniper cRPD) on any host, with no special support.

Some lab images are full virtual machines rather than containers — Cisco NX-OS and IOS-XE, Palo Alto PAN-OS, Juniper vSRX and similar. Those need nested virtualization (/dev/kvm) on the host. It is a property of the host, and no software package can supply it:

On-premises bare metal — available. The CPU’s virtualization extensions (Intel VT-x or AMD-V) must be enabled in BIOS or UEFI, which they usually are.
On-premises virtual machine (VMware ESXi, Proxmox, Hyper-V, Nutanix) — available, but off by default, and switched on at the hypervisor, not in the guest. On ESXi it is the VM CPU setting that exposes hardware-assisted virtualization to the guest OS; on Proxmox it is nested virtualization on the host (nested=1 for kvm_intel or kvm_amd); on Hyper-V it is Set-VMProcessor -ExposeVirtualizationExtensions $true. Confirm it during sizing — running inside a hypervisor does not by itself mean it is on.
Public cloud — available on bare-metal instance types (AWS *.metal), and on Azure or GCP sizes that advertise nested virtualization. On an ordinary cloud VM, NetEnds detects the missing support and refuses those image types by name before a deployment starts.

What grows with your fleet

Polling throughput is the number of node conversations in flight. Polling waits on SSH and SNMP rather than on the CPU, so it scales further than raw core count suggests. The Task Health page shows when poll cycles stop finishing inside their interval; when they do, contact support, because the worker settings that raise throughput live in the compose file each upgrade replaces.
Metric-history disk grows with node × interface count. Continuous aggregates and retention policies are built in.
Event disk grows with syslog, trap and flow volume. Raw flows are the largest contributor: they are kept 7 days by default, with 1-minute rollups kept 90 days. Syslog and traps are kept 30 days by default. All of these windows are configurable.
Streaming telemetry (gNMI) holds one persistent session per streaming node; hundreds of one-second streams add steady backend CPU.

One tuning note that saves a support call

Do not raise the database’s max_connections to scale nodes. Connection count follows service pools × worker concurrency, never node count, and the database degrades past a few hundred real connections. The scaling lever is the connection pooler (PgBouncer, in transaction mode) the workers already route through.

Memory on the 64 GiB reference host

Component	Expect
Database	About 1 GiB of shared buffers, plus the OS page cache
Event store	Several GiB under ingest and query load
What-if analysis engine	Hard-capped at 3 GiB
Backend, workers, prober	About 0.5–1 GiB each, growing with concurrency
Headroom	The OS page cache is your query performance — do not run the host at 90% memory

When one host is not enough

The stack is deliberately single-host. Past roughly 1500 nodes, or under sustained high flow rates, the pressure points are event-store ingest and polling-queue throughput. Talk to NetEnds before sharding anything by hand; a satellite flow collector already exists for aggregating flows at remote sites.