LAN Orangutan: a Go network scanner with persistent device labels and Tailscale peers
LAN Orangutan is a lightweight network scanner with persistent device labeling, multi-network support, and Tailscale integration. Built by 291 Group.
At a glance
- What is it?
- LAN Orangutan scans a LAN with nmap, keeps a labelled device inventory across runs, and can read Tailscale peers from inside the same app. It is a single Go binary with a password-gated web dashboard and a CLI, and the interesting part is where it refuses to work.
- Who is it for?
- Adopt LAN Orangutan if you run a homelab on Linux or macOS, already have nmap installed, and want device labels that survive between scans without standing up a database. Skip it if your machines are Windows desktops with Docker Desktop, or if you need passive, agent-based monitoring rather than scheduled active probes.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 37 days ago.
- What is it written in?
- Mainly Go, 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 problem: device labels that survive the next scan
Most one-shot scanners answer the question "what is on this subnet right now" and then forget everything. The next run prints the same IP addresses with no memory that 192.168.1.42 is the printer in the basement and 192.168.1.77 is a guest laptop you do not care about. On a homelab that churns through DHCP leases, that means re-identifying the same hardware every time.
LAN Orangutan's stated feature set is aimed at exactly that gap: label, group, and add notes to devices, with multi-network support and a persistent data folder. The README describes it as self-hosted network discovery for homelabbers, and the topics list confirms the audience (homelab, self-hosted, internet-of-things). It is not a security scanner and not an intrusion detection system. It is an inventory tool for someone who owns the network and wants to know what is plugged into it.
The secondary audience is Tailscale users. The README lists Tailscale integration as a first-class feature: connect, disconnect, and discover tailnet peers from inside the app. For a homelab that spans a home LAN and a rented VPS, having tailnet peers in the same device list as local hardware is the reason to pick this over a plain nmap wrapper.
How scanning works: nmap underneath, Go on top
The mechanism is not hidden. LAN Orangutan shells out to nmap, which the README lists as a hard requirement with per-platform install commands. The Go binary is the orchestration layer: it drives nmap, parses results, persists them, and serves the dashboard and CLI on top. The README's "single binary, no dependencies" claim is about the Go program itself, not about the system as a whole. nmap is still a separate install.
That dependency shapes what the tool can see. The README's compatibility table is explicit that MAC addresses and manufacturer names require elevated privileges: binary on Linux with sudo, binary on macOS with sudo, binary on Windows as Administrator, or a package install that runs as a root service. Run the binary without sudo and the table says you get IP addresses and hostnames only. That is an nmap property, not a LAN Orangutan bug, but it means the quality of your device inventory is decided by how you launch the process.
The data flow the README implies is: detect networks, run nmap against one or all of them, merge results into a stored device list keyed by address and enriched with labels, groups and notes, then present that list in the web UI or as CLI output. The CLI exposes JSON output, which matters if you want to feed the inventory somewhere else rather than read it by hand.
Live scan progress with cancellation is listed as a feature, which suggests scans run asynchronously rather than blocking the UI. The README does not describe the storage format or where the SQLite-or-whatever file lives beyond the Docker case, where data sits in a data/ folder next to the compose file. Treat the on-disk schema as undocumented in the material available.
Getting it running: one binary, or Docker with host networking
There are three install paths. The release binaries are the simplest: download for your platform, then run `sudo ./orangutan serve` on Linux or macOS, or `orangutan.exe serve` as Administrator on Windows, and open http://localhost:291. The first visit asks you to create a password, and the README states that nothing else is reachable until you do. That is the entire setup.
The Docker path is `docker pull 291group/lan-orangutan`, or fetching the compose file and running `docker compose up -d`. The image is published to both Docker Hub and GHCR (ghcr.io/291-group/lan-orangutan); the compose file uses GHCR. The container uses host networking deliberately, because on Docker's default bridge it would only see other containers on 172.17.0.0/16.
The package path covers .deb, .rpm and .apk, which run as a root service and therefore get MAC addresses without you typing sudo. If you are upgrading from the older Python and PHP build that lived in /opt/lan-orangutan, the new install.sh replaces it with the binary at /usr/local/bin/orangutan and removes the old directory. The README is specific that /etc/lan-orangutan and /var/lib/lan-orangutan are left alone, so config and device list survive. Two visible changes: you create a password again on first load, and PHP and Python become removable if you installed them only for this.
CLI surface, from the README: `orangutan scan`, `orangutan scan 192.168.1.0/24`, `orangutan scan all`, `orangutan serve`, `orangutan serve --port 8080`, `orangutan serve --bind 127.0.0.1`, `orangutan serve --allow-insecure`, and `orangutan list` with an `--online` filter. The `--bind 127.0.0.1` flag is documented as needing no password, and `--allow-insecure` disables it entirely. Both are deliberate trade-offs you should read the Security section for rather than discover later.
The Docker-on-macOS failure mode, and why it is the honest part of the README
The most useful paragraph in the README is the one explaining why Docker on macOS and Windows does not work. Docker Desktop runs Linux inside a virtual machine. The container never touches the real network. Worse, the VM's gateway answers probes on behalf of addresses that do not exist, so a scan appears to succeed while reporting devices that were never there. The README calls this worse than finding nothing because the result looks convincing, and that is correct.
What makes this worth noting is that the project detects the condition itself. The README states that if it cannot reach a real network it says so at startup and puts a warning on the dashboard, so results are never silently wrong. A tool that tells you when its own output is meaningless is doing more than most scanners in this category.
The practical rule from the compatibility table: Docker on Linux with host networking works fully; Docker on Linux with bridge networking finds nothing; Docker on macOS or Windows is unsupported and there is no setting that fixes it. If you are on a Mac or Windows machine, run the binary directly. It is one file and one command.
There is a second, quieter limitation. Without elevated privileges you lose MAC addresses and vendor names, which are the two fields that make a device inventory stable across DHCP changes. A non-root scan gives you IP addresses and hostnames, and hostnames are frequently absent on IoT hardware. So the tool is at its best in exactly the setup the README recommends: root or Administrator, real network, nmap installed.
Tailscale peers alongside local devices
Tailscale integration is listed as connect, disconnect, and discover tailnet peers from inside the app. The README does not document the mechanism, so I cannot say whether it calls the tailscale CLI, reads the local API socket, or uses an auth key. What is clear from the feature list is the intent: tailnet peers appear in the same place as LAN devices, which means one labelling and grouping workflow covers both.
That is a real convenience for the target user. A homelab that reaches a VPS over Tailscale normally means two inventories in two tools. Merging them means the notes field is useful for both, and the `orangutan list` CLI returns a single list.
The limitation is scope. This is peer discovery, not traffic analysis. Nothing in the README suggests LAN Orangutan reports which peer talked to which, or how much. If your question is "what is this machine doing on my tailnet", this is the wrong tool. If your question is "what machines are on my tailnet and which one is the backup box", it fits.
There is also an operational question the README leaves open: what happens to a peer's label when the node goes offline or is removed from the tailnet. Given the emphasis on persistent labelling, the stored record presumably survives, but the material does not say. Verify that behaviour before you rely on it for anything long-lived.
Where it sits against nmap and against passive monitoring
The obvious alternative is nmap itself, and the difference is not scanning capability. nmap does the scanning here. The difference is state. nmap gives you a report per invocation; LAN Orangutan gives you a database with labels, groups and notes that persists, plus a web dashboard and a JSON CLI. If you already have a shell script that dumps nmap XML into a file you grep by hand, LAN Orangutan is that script with a UI and a password.
A more interesting comparison is with passive or agent-based monitoring, which takes the opposite approach. Rather than probing the network on demand, an agent-based system runs on each host and reports what it sees, and a passive monitor watches traffic. Those approaches see inside machines and catch devices that do not answer probes. LAN Orangutan does neither. It is active, it is external, and a device with a host firewall that drops probes will simply not appear. That is a fundamental boundary, not a configuration problem.
The trade-off is deliberate and reasonable. Active scanning needs no software on the endpoints, which matters for IoT gear, printers, and anything you cannot install an agent on. It also means scan results are a snapshot: a device that was asleep during the scan is absent from the inventory until the next run. The README does not describe a scheduling feature, so recurring scans appear to be something you trigger, whether from the dashboard or the CLI.
Licence-wise, LAN Orangutan is MIT. That is permissive: you can use it commercially, modify it, and redistribute it, provided the copyright notice and licence text travel with it. I am not giving legal advice, and if you plan to bundle it into a product you should read the MIT text yourself. The relevant point for adopters is that MIT imposes no copyleft obligation on your own code, unlike a GPL-licensed alternative would.
Maintenance cost and what the release cadence tells you
The release history shows v3.3.8 on 2026-08-09, v3.2.1 two days earlier, and v3.1.4 in late July. That is a fast patch cadence, which cuts both ways. It suggests active maintenance. It also suggests the surface is still moving, and a minor-version bump every few weeks is not the profile of a frozen, boring tool you install once and forget.
The upgrade path is documented for the awkward case: the Python and PHP to Go migration. If you are on the old install.sh layout, the new installer moves you to /usr/local/bin/orangutan and clears /opt/lan-orangutan while preserving /etc/lan-orangutan and /var/lib/lan-orangutan. Package and Docker users need nothing extra. That is a clean story, and the explicit statement that config and device list are untouched is the detail that makes it credible.
Ongoing cost is low but not zero. You maintain nmap on the host, you keep the binary or image current, and you keep the data/ directory (Docker) or /var/lib/lan-orangutan (package) backed up if the labels matter to you. Those labels are the accumulated value of the tool, and nothing in the README suggests an export command beyond the CLI's JSON output. If you want a portable copy of your inventory, `orangutan list` with JSON is the route the material points to.
The honest assessment: this is a small Go program wrapping a well-understood tool, with a UI. The maintenance burden is closer to a self-hosted utility than to a platform. The risk is not abandonment, it is churn between minor versions.
Who should run it, and what to check first
The fit is narrow and clear. You run a homelab on Linux or macOS, you already have nmap, you want a persistent labelled inventory rather than a fresh report each time, and you either use Tailscale or would like your tailnet peers in the same list as your LAN gear. The binary install with sudo is the path the README recommends and the one with no caveats attached.
The misfits are equally clear. Docker Desktop on macOS or Windows is unsupported and produces confidently wrong output, so do not try to make it work. Anyone who needs passive monitoring, traffic accounting, or visibility into devices that do not answer probes should look at agent-based tooling instead. And if you cannot run the process with elevated privileges, you lose MAC addresses and vendor names, which removes much of the reason to keep an inventory in the first place.
Verify before adopting: that nmap is installed and reachable, that the dashboard answers on port 291 after you set the first-run password, and that a single `sudo orangutan scan` returns MAC addresses and vendor strings. If that scan comes back with IP addresses only, you are running without the privileges the rest of the tool assumes, and the labels you build will be attached to addresses that DHCP will hand to something else next week.
Editorial conclusion
Adopt LAN Orangutan if you run a homelab on Linux or macOS, already have nmap installed, and want device labels that survive between scans without standing up a database. Skip it if your machines are Windows desktops with Docker Desktop, or if you need passive, agent-based monitoring rather than scheduled active probes. Before committing, verify three things on your own hardware: that nmap is present and on PATH, that the dashboard at port 291 loads after you create the first-run password, and that a single `sudo orangutan scan` returns MAC addresses and vendor names rather than IP addresses alone, since that last result tells you whether you have the privileges the rest of the tool assumes.
Community notes