NETworkManager: a Windows toolbox for admins who are tired of ten separate utilities

The problem NETworkManager solves is window management, not missing protocols

Nothing in this project is a new protocol implementation. Ping, traceroute, DNS lookup, SSH, RDP and VNC all exist as separate command-line tools or small utilities, and most of them ship with Windows or are one package away. The README's own framing is about consolidation: it lists Remote Desktop, PuTTY, PowerShell and TigerVNC alongside WiFi Analyzer, IP Scanner, Port Scanner, Ping Monitor, Traceroute, DNS Lookup and LLDP/CDP Capture, then describes the result as "a clean, unified interface".

The audience follows from that. The README names sysadmins maintaining a company network with multiple servers, network engineers in a large enterprise, and IT enthusiasts running a home lab. What those three groups share is not a protocol need but a context-switching cost: the same host gets pinged, port-scanned, SSH'd into and remote-desktop'd, and in a plain toolkit each of those steps means retyping an address into a different program. NETworkManager's answer is the profile, which the README describes as organizing hosts and networks with access across all features. If you only ever run one tool against one host, the consolidation argument does not apply to you.

How profiles and the tool set fit together

The repository layout is a WPF application: Source/, Tests/, Website/, plus packaging directories for Chocolatey and WinGet and an appveyor.yml build definition. That tells you the architecture is a single desktop process hosting multiple tool views, not a set of independent services.

Profiles are the connective tissue. The README states that hosts and networks are organized in profiles with access across all features, and that profile files can be encrypted to protect sensitive data and used to separate different customers or environments. Two consequences follow. First, a profile is the unit you back up, share or hand over, which is why encryption matters: a profile that carries connection details for a customer environment is a credential store in practice, whatever the file format is called. Second, the separation by customer or environment is a manual discipline. The README describes the capability, not an access-control model; there is no statement that a user is prevented from opening a profile belonging to another environment.

Beyond that, the README points to the project documentation at borntoberoot.net for the full feature list rather than enumerating everything in the repository. Treat the README's list as representative, not exhaustive.

Installing NETworkManager on Windows and opening a first session

The README does not put install commands in the repository root. It directs readers to the download page at borntoberoot.net/NETworkManager/download for signed binaries in setup, portable and archive form, with detailed install instructions including silent install, and it states that files are hosted on GitHub Releases. It also lists package manager support for Chocolatey, Evergreen and WinGet, and the repository carries Chocolatey/ and WinGet/ directories, which is consistent with those channels being maintained in-tree.

The commands below use the package names as the README writes them. They are the fastest path if you already have a package manager installed; otherwise use the setup binary from the download page.

choco install networkmanager

winget install NETworkManager

After installation, the workflow the README implies is: create a profile for a host or network, then open any tool against it. The README does not document the exact dialog sequence for creating a profile, so follow the documentation site for that step rather than guessing at menu names. What you should see once a profile exists is the same host reachable from the remote-desktop, SSH and diagnostic views without retyping the address.

For enterprise deployment, the README points to system-wide policies at borntoberoot.net/NETworkManager/docs/system-wide-policies for centralized configuration. That page, not the README, is where the actual policy keys live.

Where NETworkManager is the wrong tool

The clearest boundary is the platform. The repository's topics list windows and wpf; the README describes an MSI installer, signed Windows binaries and WinGet and Chocolatey packaging. There is no statement anywhere in the README about a Linux or macOS build. If your team runs Linux workstations, this is not a candidate, and the related search traffic that mixes this project up with the Linux NetworkManager daemon is a separate piece of software entirely.

The second boundary is automation. NETworkManager is a GUI application. Its built-in tools are things you click, and while the PowerShell integration means you can run scripts inside it, the project itself is not a scripting surface you drive from CI. If you need repeatable network checks in a pipeline, the underlying tools it wraps are what you want, not the wrapper.

A third limitation is documented rather than implied: the README does not describe rollback or downgrade behaviour for profiles, and it does not state what happens to an encrypted profile file when the application version changes. Before you rely on profile encryption for anything you cannot recreate, test the round trip yourself on a throwaway profile. That is a gap in the documentation, not a claim that the feature is broken.

NETworkManager compared with a plain PuTTY plus command-line workflow

The honest alternative for most Windows admins is the status quo: PuTTY or Windows Terminal for SSH, the built-in Remote Desktop client, and ipconfig, ping, tracert, nslookup and netstat from a shell. That stack is free, already installed, and each piece is scriptable.

The difference is not capability, it is state. PuTTY stores sessions, but those sessions are SSH-only; the same host in a port scanner or a remote desktop client is a separate entry you maintain by hand. NETworkManager's profile is meant to be the single record that all features read from, which is the whole reason the encryption and per-customer separation features exist. If you maintain a spreadsheet of customer environments and copy addresses out of it, that spreadsheet is the thing this project replaces.

The trade-off runs the other way too. PuTTY and the command line are stable, individually replaceable and easy to reason about in a security review. NETworkManager is one GPL-3.0 application that you install, update and trust as a unit, and its release cadence is frequent: 2026.9.7.0, 2026.7.24.0 and 2026.7.16.0 all landed within roughly two months. Frequent releases mean frequent upgrade decisions.

Maintenance, licensing and what an upgrade actually costs

The repository is not archived, and the last push to main was on 2026-09-17, with the most recent release 2026.9.7.0 published on 2026-09-07. The project is moving.

That cadence has a cost that the README does not discuss. There is no stated long-term support branch, no documented profile schema version, and no migration note in the README for profiles created by an older release. If you deploy through Chocolatey or WinGet, upgrades arrive on your package manager's schedule; if you deploy the MSI, they arrive when you push them. Either way, test an upgrade against a copy of a real encrypted profile before it reaches production workstations, because the README does not tell you what guarantees exist across versions.

The licence is GPL-3.0, per the repository. That matters for how you distribute it, not for whether you can use it internally. Running GPL software inside an organisation is ordinary use. Redistributing a modified build, or bundling it into a product you ship, brings the GPL's source and licensing obligations into play, and that is a question for your own legal review rather than something the README answers. The README's own claim is narrower and easier to check: no ads, no subscriptions, no selling your data.

Editorial conclusion

Adopt NETworkManager if your working day is spent on Windows jumping between PuTTY, a port scanner, a WiFi analyzer and a remote desktop client, and you want those sessions tied to named profiles. Do not adopt it if your machines are Linux or macOS: the README describes a WPF application and the repository lists windows as a topic, so there is no cross-platform build to fall back on. Before rolling it out, verify three things: that your environment's system-wide policy keys match the ones documented at borntoberoot.net, that your organisation's rules permit GPL-3.0 software on admin workstations, and that the profile encryption covers the credentials you actually store. The last push to main was on 2026-09-17, so check the release notes for 2026.9.7.0 rather than assuming the changelog you read six months ago still applies.

Frequently asked questions

Official sources

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