LibreQoS v2: shaping and troubleshooting an ISP network from one box

The bufferbloat complaint an ISP operator has to answer

The README states the reason operators deploy LibreQoS in a single line of intent: reduce latency and bufferbloat during congestion using modern flow queueing and active queue management. That problem is specific to access networks. A subscriber on a congested link does not complain about throughput, they complain that the page does not load while a download is running, and the operator has to distinguish that from a Wi-Fi problem, a faulty OLT, or an upstream capacity issue. LibreQoS is aimed at that diagnostic job as much as at the shaping job. The stated audience is Internet Service Providers and enterprise networks, and the stated outcome is a local, topology-aware view of network health, subscriber behaviour, queue conditions and traffic patterns instead of relying on a single black-box score. This is an operator console with a traffic shaper attached, not a consumer tool.

A bridge between the edge router and the core

The deployment model is what makes this project practical. LibreQoS runs on a server deployed as a managed bridge between the edge router and the rest of the network, and it applies shaping locally while collecting the operator-visible data that powers the Web UI and, when enabled, Insight. The README is explicit that existing routers, switches, access points and OLTs do not need to be replaced, so the change to an access network is additive rather than a rip and replace. It also claims that a single LibreQoS server can shape traffic for tens of thousands of subscribers while powering the local Web UI and operational APIs. The repository layout backs up the platform claim: src/ holds the implementation, sim/ a simulation area, radius-harness/ a RADIUS related component, and docs/, conf.py, index.rst and a Sphinx Makefile carry the documentation that operators are pointed to.

Views built around the way an ISP actually runs a network

The v2.0 console is organised around the operator's mental model rather than around packets. The README describes a topology-aware design that follows the way ISPs run networks, with sites, APs, sectors, OLTs, branches and subscriber hierarchies, and lists the views as Dashboard, Site Map, Flow Globe, Network Tree, Queue Dynamics, Queue Stats and ASN Analysis. The diagnostic claim is explainability: Queue Dynamics, Queue Tree, RTT, retransmits, utilization and live flow views are meant to let an operator decide whether a problem is shaping related, upstream, local RF or elsewhere. The layers are broken out in the README as network-wide visibility, topology-aware diagnosis using tree and sankey views that follow parent and child relationships, subscriber-level troubleshooting with per-circuit RTT, retransmits, queue stats, queue path, flow evidence and throughput history, and traffic intelligence covering ASN analysis, geographic flow views and protocol and application context. The topics list on the repository, which names cake, cake-sqm, fq-codel, sqm and active-queue-management, matches the shaping side of that story.

Reading the docs and the Python dependency set

The README does not carry an install command, so the path is documented rather than scripted. It points to a documentation site, a quickstart page, a system requirements page, a Web UI and Node Manager page, and an Insight page, all under the v2.0 documentation set. The repository requirements.txt shows the Python side of the platform, and it is worth reading before you plan a deployment.

binpacking
flask
flask_httpauth
flask_restful
ipaddress
psutil
requests
schedule
waitress
setuptools >= 65.5.1
apscheduler
deepdiff
routeros_api
chardet

The list explains a lot about the shape of the system. Flask and flask_restful with waitress cover the Web UI and the operational APIs, flask_httpauth covers authentication on those endpoints, routeros_api points at RouterOS device integration, schedule and apscheduler cover periodic collection jobs, and psutil and deepdiff point at host and state inspection. The documentation set is built with Sphinx, since the repository Makefile is a minimal wrapper around sphinx-build with a help target that routes unknown arguments to it, and conf.py plus index.rst sit at the root beside the docs/ tree. There is no free lunch in the commercial layers either, and the README is direct about it. The core is open source under GPL2, while LibreQoS Insight adds long-term analytics, multi-shaper visibility, richer operational history and support tooling, and LibreQoS API is a paid package for operators integrating LibreQoS into broader OSS/BSS or automation workflows. Insight is the successor to the older Long Term Stats service and comes with a free 30-day trial.

A bridged appliance has failure modes a box in the closet does not

Two constraints deserve to be in your risk register before deployment. The first is structural: a device sitting inline between the edge router and the core is a single point of failure, and it must be bridged, addressable and upgraded with the network in mind rather than treated as an application server. The second is the shape of the data itself. Much of the value the README describes depends on per-circuit history, queue paths and flow evidence, and the project splits that in two by design, with high-resolution history and multi-shaper visibility living in the commercial Insight tier rather than the GPL core. If your operating model needs months of history rather than live diagnosis, you are looking at a paid dependency or at a second system. The repository also carries a SECURITY_AUDIT_2026_05_15.md file and a SECURITY_AUDIT_1_TASKS.md file, which tells you the project takes its own audit findings seriously enough to keep them in the tree.

Maintenance, sponsorship and a deliberately small pull request

The repository is not archived and the last push was on 2026-10-16. The recent tags show a steady line of releases, with v2.0 on 2026-03-18, v2.1 on 2026-03-31 and v2.2 on 2026-08-18, and the v2.0 documentation set covers quickstart, upgrade, troubleshooting, architecture and an Ubuntu 24.04 hotfix page, which is the sort of operational documentation a network team actually needs. Development is funded through the NLnet Foundation and Equinix, and through the NGI0 Entrust Fund established by NLnet with support from the European Commission under grant agreement No 101069594. The project also records Dave Taht as its former Chief Science Officer, the researcher most closely associated with the bufferbloat campaign. The contribution rules are unusually tight: the external pull request policy accepts only pull requests that address one specific change or topic each, and asks for small focused changes to ease review and testing.

Editorial conclusion

Adopt LibreQoS when you run an access network where bufferbloat is visible to subscribers and where per-circuit evidence matters more than a single black-box score, and when you can place a server inline between the edge router and the core. Do not adopt it for a single home connection, and do not adopt it expecting the paid tiers to be in the open source core, since long-term analytics and the OSS/BSS API package are commercial add-ons. Before deploying, read the quickstart and system requirements pages, confirm the CAKE and fq_codel support of your kernel, and decide early whether LibreQoS Insight belongs in your plan given its 30-day trial.

Frequently asked questions

Official sources

1. LibreQoE/LibreQoS on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases