The latest articles on DEV Community by DeviceShelf (@deviceshelf). https://dev.to/deviceshelf https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4022828%2F92dc3100-4e93-49c8-b92e-e8436b77eb76.png https://dev.to/deviceshelf en DeviceShelf Thu, 09 Jul 2026 13:34:48 +0000 https://dev.to/deviceshelf/building-a-local-first-network-scanner-in-go-wails-and-flutter-4f87 https://dev.to/deviceshelf/building-a-local-first-network-scanner-in-go-wails-and-flutter-4f87 <p>Most network scanners I tried wanted a cloud account and a subscription just to tell me what was sitting on my own LAN. That bugged me enough to build the opposite: a scanner that runs on your machine, keeps the data there, and still tells you what every device is. It's called DeviceShelf, and this is a short tour of how it's put together.</p> <h2> One core, three front-ends </h2> <p>The scanning and analysis live in a Go core: ARP/ping sweep, port checks, service probes, DHCP fingerprinting, SNMP, and the device-identification logic. On the desktop that core is wrapped with <a href="https://wails.io" rel="noopener noreferrer">Wails</a> — Go on the backend, a normal web UI on the front — so the same engine ships on macOS, Windows and Linux without three native rewrites. The mobile apps are Flutter, talking to the same concepts (a chunk of the identification logic is mirrored and unit-tested on both sides so behaviour matches). And there's a headless build of the core for a 24/7 server edition with no GUI at all.</p> <p>Keeping one engine and swapping the shell is the only reason a solo project can cover desktop, mobile and server without drowning.</p> <h2> Local-first, and meaning it </h2> <p>"Local-first" is easy to put on a landing page and easy to quietly break. The rule here is simple: nothing about your network leaves the machine unless you switch something on. Device identification runs locally; the online fingerprint lookup is opt-in and off by default. If you want AI to help name a weird device, that's there too — but you bring your own key, so the calls are yours, not routed through a server I run.</p> <h2> The parts that were actually hard </h2> <ul> <li> <strong>Identification.</strong> Turning a MAC prefix, open ports, a DHCP fingerprint and an SNMP sysName into "this is a printer" is a pile of heuristics with sharp edges — a Nintendo Switch that looks like a network switch, say. It's ordered rules, not one magic classifier.</li> <li> <strong>Live bandwidth.</strong> Per-device throughput means packet capture (Npcap on Windows, BPF on macOS), which is platform- and permission-dependent and needs care to stay light.</li> <li> <strong>The server edition.</strong> Running unattended on a LAN changes everything: alert routing over ntfy/Gotify/webhook, threshold and dependency checks, and taming alert floods so it doesn't page you at 3am because Wi-Fi hiccuped.</li> </ul> <h2> Where it is now </h2> <p>Desktop and mobile are shipping; the server edition is an honest public beta. If you want to see what's on your own network without signing up for anything, that's the whole point.</p> <p>Full write-ups and release notes: <a href="https://deviceshelf.app/blog" rel="noopener noreferrer">https://deviceshelf.app/blog</a></p> go flutter privacy showdev