ntopng: Web-Based Network Traffic Monitoring for Engineers Who Need Flows, Not Just Packets

What ntopng Solves That a Packet Capture Does Not

A packet capture answers a question about bytes. ntopng answers a question about relationships. The README describes it as a web-based network traffic monitoring application released under GPLv3, and the topic list on the repository names the inputs it accepts: NetFlow, sFlow, IPFIX, SNMP, eBPF and raw packet processing. Those are different collection models feeding one interface. That is the product's actual claim: not deeper inspection than a protocol dissector, but a persistent, queryable view of traffic organised by host, flow and interface.

The audience follows from that. Someone running a router, a firewall appliance or a lab segment wants to know which internal address is saturating an uplink, which protocol mix appeared after a change, or which SNMP interface is dropping. Those questions are answered by aggregation, not by following a stream. ntopng is the wrong tool for reconstructing a single malformed TCP handshake; it is the right tool for noticing that the handshake failure rate on one host rose.

ntopng is also the successor to the original ntop written in 1998. The README is explicit that this is a revamp in performance, usability and features rather than a rename, which matters if you find old ntop documentation and expect the same commands and layout.

How ntopng Ingests Flows, SNMP and Packets Into One View

The architecture is a collector plus a web front end. Traffic sources arrive by more than one path. Exported flow records (NetFlow, sFlow, IPFIX) are received from routers and switches that already summarise traffic. SNMP is polled for interface counters and device state. Packet-level data can be processed directly, and the topic list names eBPF as one of the mechanisms. All of it lands in the same internal model, which is why a single dashboard can show a host seen only through flow exports next to an interface seen only through SNMP.

The repository layout supports this reading. There is a src/ tree for the engine, an httpdocs/ tree for the web assets, a docker/ directory, a clickhouse/ directory, a kibana/ directory, a python/ directory and a packages/ directory. The presence of clickhouse/ and kibana/ alongside the core tells you the project expects deployments where long-term storage and external dashboards are part of the picture, not just the built-in web UI.

The web layer is not a separate application. The root package.json is private and its scripts all delegate into a pro directory: install, watch, build, build:dev, build:js, plus css:lint, js:lint and detect_circular_link. So the browser UI is built from a Node toolchain that lives outside the C engine, and anyone modifying the front end works in that directory rather than in src/.

Installing ntopng From Packages and Opening the Web UI

The README does not walk through a source build in the repository root. It points at doc/README.md for compiling and using ntopng, and it says that if you prefer a pre-built package you should go to packages.ntop.org. That is the shortest path, and it is the one the project itself recommends first.

The README lists the platforms for which binary packages are built: Debian/Ubuntu LTS x64, CentOS/RedHat/RockyLinux/AlmaLinux x64, Windows x64, RaspberryPI/Debian ARM, and FreeBSD/OPNsense/pfSense. Choose the line that matches your host and install from that repository. The README does not spell out the per-platform repository setup commands in the root file, so follow the instructions on packages.ntop.org for your distribution rather than guessing at a package manager invocation.

If you would rather run it in a container, the repository ships a docker/ directory. The README does not include a compose file or a run command in the root document, so read what is in that directory before assuming interface names or published ports.

Once the service is running, the interface is reached through a browser. The README and the search data both refer to accessing ntopng, and the project publishes a User's Guide at ntop.org/guides/ntopng/ plus API documentation at ntop.org/guides/ntopng/api/. The README does not state the default listening port in the text available here, so confirm it in the User's Guide or in your own configuration before you point a browser at a host.

For a first real use, the useful sequence is: start the service, open the web UI, then pick the interface or flow source you configured and watch host-level traffic. The README does not document a first-run wizard, so treat the User's Guide as the authority on initial configuration.

Where ntopng Stops Being the Right Tool

The most common mismatch is expecting a packet analyser. ntopng is not a replacement for Wireshark, and the comparison is not about quality but about granularity. A dissector shows you the bytes of one conversation with per-field decoding. ntopng shows you aggregates across many conversations. If your task is to prove that a specific TLS ClientHello carried a particular extension, flow-level monitoring will not produce that answer no matter how the dashboard is configured.

A second limit is the collection model itself. Flow exports are summaries produced by someone else's device, with that device's sampling and timeout settings baked in. If the router samples one packet in a thousand, ntopng cannot recover the missing nine hundred and ninety-nine. Packet-level ingestion avoids that, but it moves the constraint to the capture point: you need the traffic to reach the machine running ntopng, which is a span port, a tap or an inline position, and each of those has its own operational cost.

The third limit is deployment shape. ntopng is a long-running service with a web front end, a database layer and optional external integrations. That is heavier than a command-line capture you start and stop. Teams that want a one-off capture and a file to hand to a colleague are better served by tcpdump or dumpcap, and nothing in the README suggests ntopng is trying to compete there.

Finally, the README does not document rollback or downgrade steps between releases. If you need a documented downgrade path, that gap is worth resolving before you upgrade a production instance.

ntopng and Wireshark Solve Different Halves of the Same Problem

The honest alternative for packet-level work is Wireshark, and the difference is architectural rather than a feature checklist. Wireshark captures and dissects on demand, usually on the machine where you are investigating, and its output is a file you can annotate, filter and share. Its strength is protocol depth and the ability to move backward and forward through a single stream.

ntopng inverts that. It runs continuously, aggregates from multiple sources including flow exports it never captured itself, and presents the result through a browser to anyone with access, not only to the person holding the capture file. You give up per-packet decoding and gain a persistent, shared, multi-source view.

The practical consequence is that the two are complements in most networks. A flow-level dashboard tells you which host and which protocol to look at; a capture tool tells you what was inside. Choosing between them is really choosing whether your question is about population or about specimen. The README's own framing, a web-based monitoring application with a User's Guide and API documentation, makes clear which side ntopng is on.

Licence, Release Cadence and the Cost of Staying Current

ntopng is released under GPL-3.0, and the repository carries both COPYING and LICENSE at the top level. The README also notes that ntopng is a registered trademark in the US and EU. Those two facts interact in a way worth understanding before you embed the software in something you ship: the licence governs the code, the trademark governs the name, and they are separate concerns. If you plan to redistribute ntopng or a modified version, read COPYING and get your own legal advice rather than treating a summary as sufficient.

The release history shows a stable line roughly every six to nine months: 6.2 in August 2024, 6.4 in May 2025, 6.6 in November 2025. The default branch is dev, and the last push to the repository was on 2026-09-21. That combination means the development branch moves continuously while tagged stable releases arrive on a slower cadence. For production, the tagged releases are the natural anchor.

Upgrade cost is not zero. The web front end is built through the pro directory using the scripts in the root package.json, so a source deployment has a Node build step in addition to the C build described in doc/README.md. Package installs avoid that, which is another argument for the packages.ntop.org route on supported platforms. The README does not describe an in-place upgrade procedure or a migration path between major versions, so plan to read the CHANGELOG.md at the repository root before moving a running instance.

Editorial conclusion

Adopt ntopng if you need a browser-accessible view of who is talking to whom across flows, SNMP devices and packet interfaces, and you are willing to run a long-lived service rather than a one-shot capture tool. Skip it if your question is a single packet's bytes, or if you cannot accept GPL-3.0 obligations in a product you redistribute. Before deploying, verify the current stable release on packages.ntop.org, confirm which of the Debian/Ubuntu, RedHat-family, Windows, ARM or FreeBSD packages matches your platform, and check the User's Guide for the interface list your build actually exposes.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. ntop/ntopng on GitHub
3. Project website
4. README
5. Releases