Most network hardware sold today does not work on its own. A router, a switch, or a network firewall appliance arrives in a box, gets plugged in, and then demands an account. Before any configuration is possible, the device phones home, registers with a vendor cloud, and binds itself to a service that lives on someone else's server. The hardware is local. The control plane is not.
That arrangement has become so common it reads as normal. It is worth examining what is actually being exchanged, because the trade is rarely stated in plain terms.
The problem with cloud-first network hardware
Cloud-first network hardware bundles four assumptions into one device. An account is required to set it up. A subscription is required to keep features active. Data about the network — traffic patterns, device lists, usage statistics — is collected and sent to the vendor. And the device depends on that vendor's servers continuing to exist, continuing to be funded, and continuing to honour the original terms.
The account is the entry point. Creating one means handing over an email address, accepting a terms-of-service document, and usually verifying through a phone number or a third-party identity provider. From that point forward, the device is associated with a remote identity. Configuration changes may route through the cloud even when the user and the device are on the same network. Telemetry, framed as crash reports or analytics, often runs whether the account is active or not.
The subscription model follows. Features that used to ship as firmware — VLAN configuration, traffic shaping, monitoring dashboards — are gated behind a recurring payment. Stop paying and the device keeps running, but it loses the parts that made it worth buying. The hardware has not changed. The software licence has.
Data collection is the quieter cost. A cloud-managed network firewall appliance sees every connection on the network it guards. When management is cloud-based, the vendor is positioned to see aggregated versions of those connections: which devices are active, which domains are queried, how much traffic flows where. The privacy policy describes what is collected. It rarely describes what is not.
Vendor lock-in is the structural result. Configuration lives in the cloud. Dashboards live in the cloud. Alerts live in the cloud. Migrating to another device means rebuilding that configuration by hand, because the export format is proprietary or unavailable. The longer the device is used, the more expensive it becomes to leave.
What local management means in practice
Local management means the device is administered entirely from the network it sits on. No cloud account. No remote authentication server. No requirement that the internet be reachable before a setting can be changed. The management interface is served by the device itself, addressed directly, and reached over the local network.
In practice this looks like a web browser pointed at a local address — an IP, or a name like known.local resolved through mDNS. The interface is served from the device's own memory. Configuration is stored on the device. The same network that carries the traffic being monitored also carries the management session. Nothing leaves the building.
A self-hosted network monitor built this way is self-contained by construction. There is no cloud component to decommission, no API key to revoke, no third-party dashboard that could change its layout or its pricing overnight. The device and its interface are the same object.
What you gain
Privacy is the first gain. A privacy network monitor with no cloud dependency has nowhere to send data even if it wanted to. No telemetry channel exists. No accounts means no identity to associate with the traffic being observed. The device watches DNS on the local network, and the only place that information goes is the screen in front of the person who owns it.
Control is the second. Configuration changes apply immediately, because there is no cloud round-trip. Firmware updates come from a source the user chooses — often an open repository — and are applied locally. The device behaves the same way on day one and on day one thousand, regardless of what the vendor decides about its cloud service.
No vendor lock-in is the third. When management is local, the device is portable. Open source firmware means the configuration format is readable, the code is auditable, and the user is not dependent on a single company's continued goodwill. If the manufacturer disappears, the device keeps working.
Offline operation is the fourth. A network firewall appliance with local management keeps functioning when the internet connection drops. Configuration remains accessible. The monitor keeps watching. The dashboard keeps loading. None of it depends on a server in another country being reachable.
What you give up
Remote access from outside the local network is the main trade-off. A cloud-managed device can be configured from anywhere, because the cloud is reachable from anywhere. A locally managed device is, by design, reachable only from inside the network. Checking the dashboard from a phone on a different network means travelling to the network, or setting up a VPN, or accepting that the device is not available from afar.
Cloud dashboards are the other loss. A vendor-hosted dashboard is convenient: it aggregates multiple sites, sends push notifications, and presents long histories without local storage. Local management trades that convenience for a single location, a single history, and notifications that stay on the network.
Neither of these is a defect. They are the direct consequence of not depending on a cloud. For a privacy network monitor, the trade is the point.
How Known implements local management
Known is a privacy network monitor built on the Pico 2 W / RP2350. It watches DNS traffic on the local network. It stores nothing permanently — memory is volatile, so observations exist only while the device is powered on. And it has no cloud dependency.
Management happens in a web browser. The device advertises itself on the local network as known.local. Opening that address in any browser on the same network loads the interface, served from the device itself. No external servers are contacted. No accounts are created. No telemetry is sent. The interface is the device, and the device is the interface.
Because the firmware is open source, every claim above is verifiable. There is no closed binary quietly phoning home. The code that handles DNS observation, the code that serves the web interface, and the code that manages volatile memory are all readable. The absence of a cloud component is not a promise — it is a property of the architecture.
For a network firewall appliance or a self-hosted network monitor, the question is not whether local management is possible. It is whether the device was designed to need anything else. Known was not.