Scanopy: a Rust daemon that keeps network diagrams current
Network diagrams that update themselves
At a glance
- What is it?
- Scanopy scans a network on a schedule and emits four linked views (L2, L3, workloads, applications) instead of a drawing that goes stale. This review covers the mechanism, the Docker Compose path, the AGPL-3.0 terms, and where the approach breaks down.
- Who is it for?
- Adopt Scanopy if you run a segmented or multi-site network and want the topology derived from SNMP, LLDP and ARP rather than redrawn by hand, and if AGPL-3.0 source disclosure is acceptable for how you deploy it. Do not adopt it if you need a one-off static diagram, or if you cannot expose a scanner to the segments you want mapped.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, 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
What Scanopy replaces, and for whom
The README frames the problem in one line: "Network documentation, without the drawing." That is a fair summary of the gap it targets. A diagram exported from draw.io is accurate on the day it is saved and wrong the following week, and the README points at a second failure mode as well: infrastructure-as-code state misses drift and resources provisioned outside the pipeline. Scanopy's answer is to stop treating the diagram as an artifact and treat it as a rendered view of a model that gets rebuilt on a schedule.
The audience named in the README is broad, and the four groups it lists have genuinely different needs. Platform and DevOps teams are pointed at service dependency tracing without an APM agent. Network engineers are pointed at multi-VLAN, multi-site topology derived from SNMP, LLDP and ARP. IT operations gets inventory and dependency tracking across teams and sites, and MSPs get per-client documentation with shareable live views. Home labs are listed last, which is telling: the feature set is aimed at environments where someone already knows the network is segmented and wants that segmentation recorded without manual effort.
One scan, four views: how the model is built
The architecture described in the README is a daemon plus a server. The daemon scans on a schedule and produces four views from each scan: L2 (physical), L3 (logical), workloads, and applications. The README describes the L2 view as "every switch, every port, every link" and the L3 view as subnets and how hosts connect across them. Workloads covers the range from bare metal to hypervisors to containers, and applications groups services with their dependencies.
That layering is the interesting design decision. A port-to-port map and an application dependency graph are usually produced by different tools with different data sources, and reconciling them is manual work. Scanopy derives both from the same scan pass, which means a change in the physical layer propagates into the application view without a separate update step. The README also states that discovery is agentless ("One scanner, no per-device agents") and that service identification relies on a library of "230+ service definitions", with native discovery for containerized services and network hardware via Docker and SNMP integration.
Distributed scanning is the mechanism for segmented networks: daemons are deployed across segments to map multi-site and multi-VLAN topologies. The README does not describe how daemons authenticate to the server or how scan results are merged when two daemons observe the same subnet, so treat cross-segment reconciliation as something to verify in the installation guide rather than assume.
Getting it running with Docker Compose
The quick start for self-hosting is two commands. The README gives this example:
curl -O https://raw.githubusercontent.com/scanopy/scanopy/refs/heads/main/docker-compose.yml docker compose up -d
The UI is then reachable at http://<your-server-ip>:60072, where you create an account and wait for the first discovery to complete. There are two other install paths listed: a Proxmox helper script that creates a Scanopy LXC, and an Unraid community app. Beyond the port and the compose file, the README defers configuration to the installation guide at scanopy.net/docs/server-installation, so specific environment variables and scan schedules are not documented in the repository README itself.
Two practical notes follow from the material. First, the compose file is fetched from the main branch rather than a tagged release, so pinning means editing the file after download or writing your own. Second, the daemon and server are separate images (the README's badges reference mayanayza/scanopy-daemon and mayanayza/scanopy-server), which matters if you plan to run scanners on hosts other than the server. If you want to look before installing, demo.scanopy.net runs the full UI against a sample dataset.
The AGPL-3.0 boundary and what it costs you
Scanopy is AGPL-3.0 with a commercial alternative. The README states the self-hosted AGPL path is "Free for all use" but "Requires source disclosure for network services and copyleft compliance." That phrasing is doing real work. AGPL-3.0 is the variant of GPL that treats users interacting with the software over a network as recipients, which is precisely the deployment shape Scanopy is built for. If you run it as an internal service and modify it, the licence question is not the same as running an unmodified binary. The README offers a commercial licence for "those who cannot comply with AGPL-3.0 terms", with contact at licensing@scanopy.net. This is not legal advice; the point is that the licence choice is a deployment decision, not a footnote, and the project itself flags it as such.
Maintenance cost is harder to pin down from the material. The release cadence visible in the repository is fast: v0.17.12, v0.17.13 and v0.17.14 landed between 2026-08-25 and 2026-09-03. Frequent patch releases in the 0.17.x line suggest active development, and also suggest that pinning a version and reading release notes before upgrading is a reasonable posture. The README does not describe a database migration policy or a supported upgrade path between minor versions, so that is a question for the installation guide or the Discord.
Where the scanning model breaks down
The central limitation is inherent to the approach: Scanopy sees what a scan can reach. The README lists SNMP, LLDP, ARP and Docker as discovery inputs. That set does not cover encrypted or routed traffic it cannot observe, hosts that block SNMP, or segments no daemon is deployed to. A device that appears in no scan appears in no view, and there is no described mechanism for marking a known-but-unreachable device so it does not silently vanish from the documentation. For a network with a hard segmentation boundary and no appetite for placing a scanner behind it, the L2 view will simply be incomplete.
The second limitation is scope. This is a documentation tool, not a monitoring or alerting system. The README describes scheduled rescans that keep documentation current; it does not describe thresholds, notifications, or anomaly detection. If your actual need is to know when a link goes down, a scanner that runs on a schedule is the wrong instrument, and the gap between two scan intervals is invisible to it. The third is that an auto-generated model is only as trustworthy as its inputs. A misidentified service definition produces a confidently wrong application dependency graph, and the README gives no accuracy figures for the 230+ service definitions.
How it differs from NetBox and IaC state
The README positions Scanopy against two things directly: hand-drawn diagrams and infrastructure-as-code state. The IaC comparison is the more substantive one. A Terraform state file records what the pipeline created, and the README's own criticism is that it "misses drift and resources provisioned outside the pipeline." Scanopy inverts the source of truth: instead of declaring intended state and comparing, it observes running state and derives the model from it. That means anything on the wire shows up regardless of who provisioned it, which is exactly the drift case, but it also means Scanopy has no concept of intent. It cannot tell you a device is present but should not be.
For teams already running NetBox or a similar source-of-truth system, the README is explicit that Scanopy is not trying to replace it: the model can be "fed into your existing source of truth." The distinction is direction of flow. NetBox is curated by humans and is authoritative about what should exist; Scanopy is generated by observation and is authoritative about what does exist. The README also lists SVG, Mermaid and Confluence as export targets and live map embedding, which is the practical bridge between the two: Scanopy supplies the discovered topology, the source-of-truth system supplies the annotations and ownership.
Who should adopt it, and what to check first
Adopt Scanopy if the documentation problem you have is staleness rather than absence. A segmented network with VLANs, multiple sites, and a mix of containers and hardware is the case the README designs for, and the agentless single-scanner model keeps deployment small. MSPs running per-client documentation with shareable live views are a plausible fit given the multi-user and RBAC features the README lists. Home labs are supported but are not where the four-view model earns its complexity.
Do not adopt it if you need a static diagram for a one-time deliverable, if you cannot place a scanner with line of sight to the segments you want mapped, or if you need alerting rather than documentation. Before committing, verify three things. Check the daemon and server image sizes against your host, since the README carries separate size badges for each. Confirm which segments a daemon can actually reach in your topology, because unreachable segments produce an incomplete L2 view with no warning mechanism described. And settle the licence question for your deployment model before you build on it, since AGPL-3.0 network-service obligations and the commercial alternative are a decision the README leaves to you.
Editorial conclusion
Adopt Scanopy if you run a segmented or multi-site network and want the topology derived from SNMP, LLDP and ARP rather than redrawn by hand, and if AGPL-3.0 source disclosure is acceptable for how you deploy it. Do not adopt it if you need a one-off static diagram, or if you cannot expose a scanner to the segments you want mapped. Before committing, verify the daemon image size and port exposure against your host, and confirm with legal counsel whether your deployment model triggers the AGPL network-service clause or requires the commercial licence.
Community notes