ntopng

Last reviewed Aug 26, 2026 · 942 words

Five minutes after pointing ntopng at the right interface you will know which device on your LAN talks to a cloud in another continent at 3 a.m., which laptop is eating the uplink, and what share of your traffic is TLS you cannot read anyway. The catch is the phrase "the right interface". ntopng only analyses traffic that reaches the network card it listens on, and on a switched home network that is, by default, almost nothing except broadcasts and the host's own traffic.

Placement decides whether you see anything at all

A switch sends each frame only to the port that owns the destination MAC, so a box plugged into a spare port sees its own conversations and ARP noise. There are three ways to fix that, and you need one of them before installing anything. First, run ntopng on the gateway itself: pfSense and OPNsense both carry it as a package, which is the cheapest route if your firewall has the CPU to spare. Second, buy a managed switch (a used 8-port with port mirroring is about 30 to 60 dollars) and mirror the uplink port to the port ntopng sits on. Third, put a small two-NIC box inline between modem and router as a transparent bridge, which works but adds a failure point in the one place you least want it. I use the mirror port; it costs nothing in latency and nothing breaks when the monitoring box is off.

Docker only works with the host's network

This is the flag everyone misses. Bridge networking hands ntopng a virtual interface carrying only the container's own traffic, and the dashboard fills with a very detailed picture of nothing. The container must share the host's network namespace:

services:
  redis:
    image: redis:alpine
    restart: unless-stopped
  ntopng:
    image: ntop/ntopng:stable
    network_mode: host
    command: -i eth0 -w 3000 -r 127.0.0.1:6379
    volumes:
      - ntopng-data:/var/lib/ntopng
    restart: unless-stopped
volumes:
  ntopng-data:

Redis is a hard dependency; ntopng keeps its live state there. -i names the interface to capture on (the mirror-port NIC, not your management one), and -w 3000 is the web UI port. First login is admin / admin with a forced password change. If you want the mirror NIC to carry nothing but captured traffic, leave it without an IP address; ntopng captures fine on an unaddressed interface.

The free edition covers a home; the licence covers a NOC

The community edition gives you the live host list, per-flow detail, protocol classification via nDPI (a few hundred application signatures, so "Netflix" and "Steam" rather than "port 443"), top talkers, a per-host history in RRD time series, and basic alerts. That is the entire product for a home network, and there is no time limit on it. The Pro and Enterprise tiers add the things a network team needs: longer flow retention in a proper database, richer alerting and reporting, SNMP polling of switches, and active-monitoring extras. The licence is per installation, and at last check ntop offered it free to education and non-profit users. If you find yourself wanting "show me every flow from that host on the 14th", that is the paid tier, and it is also the moment to ask whether you would be better served by SNMP interface counters in LibreNMS plus the community ntopng for live drill-down.

NetFlow arrives through nProbe, not ntopng

ntopng does not listen for NetFlow or sFlow on its own. Routers that export flows talk to nProbe, ntop's separate collector, which normalises them and forwards to ntopng over ZeroMQ. nProbe is its own product with its own licensing. If your router does not export flows, and most consumer gear does not, skip this path entirely and use the mirror port. Capturing from a mirror port gives you more detail than flow records anyway; flows are for links too fast or too remote to mirror.

CPU follows new connections, not bandwidth

The 512 MB memory floor is honest for a home LAN with a few dozen hosts. What grows is CPU, and it grows with the rate of new connections rather than megabits, because nDPI inspects the opening exchange of every flow. A Raspberry Pi 4 keeps up with a 100 Mbps household. A gigabit link at full tilt with thousands of concurrent flows wants a real x86 core or two, and if you push past that ntop's PF_RING drivers exist precisely because the stock Linux stack starts dropping. The RRD time series also generate steady small writes, so put /var/lib/ntopng on something other than an SD card. On the visibility axis, this is a different tool from Pi-hole, which shows you DNS names queried but not a single byte transferred, and from Netdata, which shows the host it runs on rather than the network around it. ntopng is the only one of the three that tells you where the bytes actually went.

What I'd do

A managed switch with the WAN-facing port mirrored to a small N100 mini PC with two NICs: one addressed for management, one unaddressed on the mirror. Community edition in Docker with network_mode: host, Redis alongside, data on SSD. Run it for a week and just look. Most people find the two or three misbehaving devices in the first evening, and the live view answers the question that made them install it. Pay for a licence only when you catch yourself needing last month's flows, and if that day never comes, you have lost nothing.