ntopng

What is ntopng?

ntopng watches the traffic on an interface and reports what is talking to what: top talkers, protocols, hosts and flows, with historical data you can browse. It is how you find out what is saturating your uplink.

Best for

Understanding real network traffic on a home or office LAN

Why choose ntopng

ntopng answers the question that metrics dashboards cannot: what is actually using the network. It watches an interface, identifies hosts, protocols and flows, and shows which conversations are consuming bandwidth, complete with historical browsing so a problem that started this morning can be traced back. Because it works from packet data rather than reports from endpoints, it sees traffic from devices that have no agent — a phone, a printer, a guest laptop, an IoT sensor. It also exposes flow data to other tools, so it can be both an investigation interface and a data source. For a home or office LAN where 'the internet is slow' is a recurring complaint, it is how you find the device responsible.

Replaces

• Darktrace
• PRTG
• SolarWinds NPM

Key features

• Live per-flow traffic analysis
• Historical flow storage in SQLite or ClickHouse
• Protocol and application identification
• Alerts on hosts, categories and behaviour

What to watch out for

The traffic volumes involved mean a mirror port or a tap is usually required, and getting that right on your switch is half the work. Packet-level analysis at line rate on a busy link will exceed what a modest machine can process, so scaling to a fast uplink requires real hardware. Stored flow history grows steadily, so retention limits are a configuration decision you should make deliberately. In some deployments the community features and the commercial editions differ, so check which capabilities apply to your build before planning around them. It is also not a security product despite the presentation; do not mistake flow visibility for intrusion detection.

How to deploy

• Docker with host network access
• Mirror or tap the interface you want to observe
• Store flows in a database for history

Getting started

Decide how traffic will reach it first — a SPAN port on the switch is the usual approach for a small network, and it must be configured before anything useful appears. Start on an interface with moderate traffic to get familiar with the interface, then move to the real uplink. Set retention limits for flow history so the database does not grow without bound. Name and group the hosts you care about so a wall of IP addresses becomes readable. Back up the configuration and database alongside your other services, and do not expose the web interface to the internet.

Typical setup

It runs on a machine connected to a mirror or SPAN port on the switch, which is the step that determines whether it has anything to analyse. Flow history is stored in a local database with explicit retention limits so it does not grow without bound. Hosts that matter are named and grouped so a wall of addresses becomes readable, and the web interface sits behind a reverse proxy with authentication. The configuration and database are backed up, and the host is sized for the throughput of the link it is watching rather than for a quiet test interface.

Who should look elsewhere

Do not install this if you cannot mirror traffic to it, because without packet data it has nothing to say. Skip it on very high-bandwidth links unless you are prepared to size hardware for the throughput. And if your actual goal is application performance rather than network accountability, a metrics and tracing stack will answer your questions with far less plumbing.

Project health

• GitHub stars: 8,220
• Last code push: 2026-10-01
• Open issues: 336
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.