Network Optimizer for UniFi: a self-hosted audit and monitoring stack for UniFi networks
Self-hosted optimization, monitoring (NMS), and security audit tool for UniFi Networks. Includes Wi-Fi Optimizer for wireless health scoring and channel optimization, advanced DNS/VLAN/firewall security checks, config optimization suggestions, centralized WAN and LAN speed test server w/ L2 tracing, CM, ONT, SFP, 5G modem stats +more.
At a glance
- What is it?
- Network Optimizer is a C# application that audits, scores and monitors UniFi networks, with a Docker deployment on Linux and a Windows build. Its free tier covers three sites for personal use; commercial use and larger deployments need a licence key.
- Who is it for?
- Adopt it if you run UniFi hardware at home or across a handful of sites and want Wi-Fi health scoring, security audits and speed testing in one self-hosted panel. Do not adopt it if you are outside the UniFi ecosystem, if you cannot accept a licence key check against licensing.ozarkconnect.net, or if you need a permissively licensed codebase.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Network Optimizer fills between UniFi Network and a real NMS
UniFi Network is a controller. It configures hardware and reports what the controller itself observes, on the controller's own schedule. Network Optimizer is aimed at the questions that sit outside that boundary. The README describes the constraint directly: the Console only reports client stats on its own schedule, roams after the fact, and nothing about traffic that never left the LAN. That last clause matters. A laptop copying files to a NAS never crosses the gateway, so the controller can report it as idle while the link is saturated. Network Optimizer exists to measure the network rather than read the controller's summary of it.
The audience is narrow and identifiable. You need UniFi access points, gateways or switches. You need somewhere to run a container, or a Windows machine. The project targets homelab operators, people running a few business locations, and MSPs with a book of client networks, a phrase the README uses directly. If your network is not UniFi, nothing here applies. If it is UniFi and small enough that the controller's own dashboards answer your questions, this is extra infrastructure for information you already have.
What AP Telemetry actually changes about the measurements
The most consequential design decision in the material is AP Telemetry. Instead of reading Wi-Fi state through the UniFi Console, Network Optimizer pushes a small agent to each access point over SSH. That agent runs in memory, returns after a reboot or firmware update, and is removed from every AP when the feature is turned off. It is opt-in and supports U6 and U7 access points only.
The data flow change is specific. Signal and rates update twice a second, and the Client Performance page follows a device through a roam instead of waiting for the Console to catch up. A Roam button moves a client to another access point or band, which is what makes a walk test meaningful: you can place the phone on the AP you are actually testing rather than the one the controller assigned.
The scoring layer consumes those measurements rather than inferring them. A raised noise floor is judged against the radio's own history. High utilization is attributed to your airtime or someone else's. A sticky client is defined as one parked on a weak AP for hours with a better one in range, which is a definition the Console cannot produce because it lacks the per-AP view. Good signal with bad latency is read as a congested channel rather than a bad link. Issues can be acknowledged the way Security Audit handles them: hidden from the list but still counted in the score. Channel Recommendation uses the same data, and width is part of the recommendation: narrower when no client has used more than half the width in the past week, wider when they could and the channel is quiet. After a channel move the card shows interference before and after.
The trade-off is that this requires SSH access to your access points and a vendor-specific agent running on them. The README states it is memory-resident and removed when the feature is disabled, which limits the footprint, but you are still running pushed code on network hardware. If that is unacceptable in your environment, you lose the entire measurement layer and fall back to Console-derived inference.
Multi-site onboarding: agent tunnel versus site-to-site VPN
Network Optimizer supports several sites from one server, and the README lays out two onboarding paths with different capability floors rather than treating them as equivalent.
The recommended path is a lightweight on-site agent that dials home over a single outbound HTTPS tunnel. No inbound access to the site, no port forwarding, and it works behind CGNAT. The agent proxies that site's probing, SNMP, UniFi Console access and device SSH over the tunnel, and each site's data is kept separate. The README puts the agent at roughly 50 MB in practice, small enough to run on the site's UniFi gateway, so a site does not need a separate box. Per-site access control is part of the model: a client can get Viewer access to only their site, or a field tech can get Operator on three specific sites. Full feature coverage comes with the agent: ISP Health scoring and path analysis, security audits, Wi-Fi and channel optimization, Adaptive SQM, performance tweaks, and LAN, WAN and client speed tests.
The second path is for sites you already reach over a site-to-site VPN. You can onboard with no agent and still get security audits, Wi-Fi and channel optimization, performance tweaks, Adaptive SQM, WAN steering, and SNMP device health. What you do not get without the agent is the monitoring and performance layer: ISP Health, path discovery, latency and loss, and speed tests. The README is explicit that you deploy the agent when you want those, or for any site the VPN does not reach.
That is a cleaner distinction than most multi-site tools draw. The VPN path is a real fallback, not a degraded demo, but it is a strictly smaller feature set. If ISP Health and speed testing are the reason you are looking at this project, the VPN-only route will not deliver them.
Running it: Docker on Linux, a Windows build, and the licence key
The README points to a Quick Start for Linux Docker and a separate deployment guide at docker/DEPLOYMENT.md. It does not inline the compose file or the container image name in the material available here, so the exact image reference and volume layout have to come from that guide rather than from this article. The repository also publishes a Windows build, evidenced by the Windows downloads badge and the releases page, so Docker is not the only route.
Configuration is done in the application UI rather than in a config file, based on the keys the README names. Licensing lives under Settings > Application > Licensing. Activating a key makes an outbound HTTPS request to licensing.ozarkconnect.net, so strict egress rules need to allow HTTPS on port 443 to that hostname. The README states that a licence server outage never disables your sites, because entitlements are cached and verified locally. That is a sensible failure mode for a self-hosted tool: the licensing check is not in the request path of your network monitoring.
The free tier is personal, non-commercial use on up to three sites, with no key and nothing phoning home. Commercial use, or more than three sites, requires a key obtained by contacting tj@ozarkconnect.net. A hosted offering is described as coming soon at $15 per month for up to three sites with a 14 day trial, and a commercial hosted plan at $25 per month per site that adds management and consulting. The on-site agent runs on your gateway in the hosted model, so the README says the only thing you give up is LAN speed testing; WAN speed testing is included with data limits.
The licence is listed as NOASSERTION in the repository metadata, while the README badge and the LICENSE link both point to BSL 1.1. That mismatch is worth resolving before you build anything on top of the code. BSL 1.1 is source-available rather than a conventional open source licence, and the terms are set by the licensor. This is not legal advice; read the LICENSE file and the licensing page if the distinction affects your plans.
Where the feature list outruns the documentation
The description covers a lot of ground: Wi-Fi optimization and channel planning, DNS, VLAN and firewall security checks, config optimization suggestions, a centralized WAN and LAN speed test server with L2 tracing, cable modem, ONT, SFP and 5G modem stats. The README goes deep on AP Telemetry, multi-site agents, licensing and Firmware Rollout, and thin on almost everything else. There is no explanation in the supplied material of how the DNS, VLAN and firewall checks decide what counts as a finding, what the L2 tracing actually measures, or how the speed test server is provisioned.
That is not proof the features are shallow. It is proof you cannot evaluate them from the README. The security audit section is referenced in the context of issue acknowledgement, which tells you findings can be hidden from the list while still affecting the score, but not what generates them. If a security audit is a primary reason you are considering this, budget time to read the source or run it against a lab network before trusting its output on production.
Firmware Rollout gets a paragraph describing the problem it solves: clicking Upgrade one device at a time and hoping nobody is on a call when an AP reboots. The README text is truncated mid-sentence at that point, so the mechanism for sequencing and health-checking a rollout is not visible here. Treat that feature as unverified.
How it compares to running Uptime Kuma plus a speed test container
The obvious alternative for a homelab is assembling the pieces: Uptime Kuma or a similar probe for availability, a standalone speed test tracker container for throughput history, and the UniFi controller's own Wi-Fi dashboards for radio health. That stack is permissively licensed, has no site limits, and does not ask for SSH access to your access points.
The difference in approach is where the measurement happens. A generic uptime monitor probes from wherever it runs, which is usually a server on the LAN or a VPS outside it. It can tell you a service is unreachable and it can run a speed test, but it has no view of the radio. It cannot tell you a client is sticky on a weak AP, cannot attribute airtime to your traffic versus a neighbour's, and cannot recommend a channel width based on the past week of client usage. Network Optimizer's AP Telemetry is the whole argument for choosing it over that stack, and it is also the reason it only works on UniFi hardware with U6 or U7 access points.
The honest framing is that these solve overlapping but different problems. If you want to know whether your ISP is delivering and whether your services are up, the assembled stack is lighter and has no licence ceiling. If you want to know why a specific client roams badly or why a channel is congested, the assembled stack cannot answer, because it is not measuring the radio.
Maintenance cost and the release cadence
The release history shows v2.8.3 on 2026-09-10, v2.8.2 the day before, and a preview build of v2.8.2 two days before that. The last push to the default branch is the same day as the latest release. That cadence cuts both ways. Fixes arrive quickly, and so do changes. A self-hosted tool that ships patch releases on consecutive days is one you should expect to update deliberately rather than set and forget, particularly if you enable AP Telemetry, since the agent is pushed to access points and the README notes it supports U6 and U7 specifically. A firmware or agent protocol change is the kind of thing that shows up in a patch release.
The multi-site agent adds a second component to keep current. If you run agents on gateways at several sites, the server and the agents need to stay compatible, and the README does not describe a version compatibility policy in the material available. That is a question to ask before rolling agents out broadly.
On licensing, the practical ceiling is three sites for personal, non-commercial use. Beyond that, or for commercial use at any size, you need a key, and the key check reaches licensing.ozarkconnect.net over HTTPS. The cached-entitlement design means a licensing outage does not take your monitoring down, which is the right call for this class of tool.
Editorial conclusion
Adopt it if you run UniFi hardware at home or across a handful of sites and want Wi-Fi health scoring, security audits and speed testing in one self-hosted panel. Do not adopt it if you are outside the UniFi ecosystem, if you cannot accept a licence key check against licensing.ozarkconnect.net, or if you need a permissively licensed codebase. Verify first: whether your access points are U6 or U7 if you intend to use AP Telemetry, and what the BSL 1.1 terms mean for your use.
Community notes