reconYa defaults to zero outbound calls, which is unusual for a discovery tool

Four environment variables decide whether your scanner talks to the internet

Most asset discovery tools send something somewhere. A MAC address goes to a vendor API, an address gets geolocated, and a public IP lookup happens for a badge nobody asked for. reconYa takes the opposite position and states it in the first line of its network isolation section: the backend makes zero outbound network connections by default, and scanning, device tracking and the console all work from data gathered on the local network itself.

The mechanism is four environment variables, each mapping to a specific host.

PUBLIC_IP_LOOKUP_ENABLED=false
GEOLOCATION_ENABLED=false
VENDOR_LOOKUP_ONLINE_ENABLED=false
OUI_DOWNLOAD_ENABLED=false

Enabling them opens, respectively, a call to api.ipify.org over HTTPS to show your public IP in the HUD, a plain HTTP call to ip-api.com to turn that address into a city and country, a per-device HTTPS call to api.macvendors.com when a MAC is missing from the bundled table, and a monthly plain HTTP refresh of the MAC vendor table from standards-oui.ieee.org.

Two details in that table deserve attention. The MAC vendor lookup is sent once per discovered device, so on a large segment enabling it is not one request but hundreds over time. And the geolocation and OUI download paths are plain HTTP, not HTTPS, so the queries and responses travel unencrypted even when you do opt in.

With all four false, the README states the public IP tile shows a placeholder dash instead of erroring, and vendor resolution falls back to the OUI table already bundled in the binary. The tool degrades rather than breaks, which is the right choice for a deployment where the whole point is not leaking the network.

One exception the README does not let you close

There is a leak in the isolation story, and it is not in the backend. The web interface loads its fonts from Google Fonts at fonts.googleapis.com. The README is explicit that this is the one remaining browser-side exception, while all other UI assets, meaning CSS and JavaScript, are embedded in the binary and served locally.

That distinction matters for what kind of deployment the claim actually covers. For a server operator worried about leaking network topology or device data, the isolation claim holds, because nothing about your network leaves the box. For anyone with an egress-filtered or air-gapped network, it does not: the console will render with fallback fonts and every page view will attempt a request that cannot complete, which is both a visible defect and an unnecessary failure mode in a locked-down environment.

Vendoring the fonts is described as tracked future work for fully offline use. So the current state is that the backend is isolated and the frontend is not, and the README does not present that as a complete solution for either case.

The scanning pipeline, and why it needs root

Discovery runs on a 30 second cycle with three strategies rather than one. ICMP ping sweeps run in privileged mode, TCP connect probes to common ports act as a fallback for hosts that drop ping, and ARP table lookups resolve MAC addresses on the local segment.

That combination is what makes the tool work on a home or office LAN, where dropping ICMP is common and many devices answer on a known port instead. It is also why the quick install tells you to start the binary with sudo. Raw sockets for ICMP sweeps and ARP table reads both require privileges, so running unprivileged means the discovery stage silently loses its most reliable signal.

From there the pipeline identifies and profiles. An IEEE OUI database resolves vendors locally, hostname resolution runs through several methods including DNS, NetBIOS and mDNS, and device type is classified from the combination of ports and vendor. Port scanning then covers the top 100 ports with service detection and banner grabbing, run concurrently by a worker pool. Web service detection picks out HTTP and HTTPS services automatically and captures screenshots plus metadata such as titles and server headers.

Screenshot capture is the part that will surprise a Windows host, because it shells out to something on the machine. Without the chromedp build tag, the README states screenshots fall back to whichever of chrome or chromium, firefox, wkhtmltoimage or webkit2png is installed on the host.

IPv6 is observed passively rather than scanned

IPv6 handling is the part of the design that differs most from a typical IPv4 sweep. The README describes it as passive monitoring that detects IPv6 devices through neighbour discovery and interface monitoring, with no traffic generated.

Mechanically, the monitor activates automatically during network scans and watches the Neighbor Discovery cache plus the network interfaces. It then classifies addresses by range, with link-local fe80::/10 and unique local fc00::/8 called out, rather than probing them. Nothing is sent to a host to find out whether it exists, because on IPv6 you can often just read the neighbour table.

The behaviour is gated by four settings in backend/.env:

IPV6_MONITORING_ENABLED=true
IPV6_MONITOR_INTERFACES=
IPV6_MONITOR_INTERVAL=30
IPV6_LINK_LOCAL_MONITORING=true
IPV6_MULTICAST_MONITORING=false

An empty IPV6_MONITOR_INTERFACES means no interface restriction, so the monitor watches all of them. The 30 second interval is independent of the IPv4 discovery cycle. Multicast monitoring is off by default, which means unicast neighbour discovery is observed but solicited-node multicast is not.

The practical benefit is that a dual-stack network does not lose its IPv6 devices to a tool that only sweeps the IPv4 range, and the cost is nil, since nothing extra is transmitted.

Installing: curl to sh, make targets, or the backend directly

The quick route pipes a shell script into sh, which auto-detects OS and architecture, downloads the correct binary and sets up the config:

curl -sL https://raw.githubusercontent.com/Dyneteq/reconya/master/install.sh | sh

It covers Linux on x86_64 and ARM64, and macOS on Intel and Apple Silicon. Then run it with privileges, because of the ICMP and ARP work described above:

cd reconya && sudo ./reconya-*

The console is then at http://localhost:3008 with the default credentials admin and password, which the README says to change in .env.

The source route needs Go 1.25 or newer and make:

git clone https://github.com/Dyneteq/reconya.git
cd reconya
make install     # downloads dependencies, creates a default .env
make start       # start reconYa as a daemon

The Makefile confirms how that daemon target works, which is worth knowing because it is lighter than it looks. The start target stops any existing instance, then runs `cd $(BACKEND_DIR) && nohup go run $(LDFLAGS) ./cmd` with output redirected to a log file and an error file, writing the PID to .reconya.pid and sleeping two seconds before checking the process survived. Because the recipe uses go run rather than a compiled binary, a make start on a source checkout compiles on every start. Other targets are make start-dev in the foreground, make stop, make status, make logs, make help. The version string is read from a VERSION file and injected through ldflags.

For running the backend without the Makefile:

git clone https://github.com/Dyneteq/reconya.git
cd reconya/backend
cp .env.example .env   # edit to set your credentials
go mod download
go run ./cmd

On Windows the README flags a specific problem: the SQLite driver needs cgo, so a CGO error means running with CGO_ENABLED=1 and having TDM-GCC or Visual Studio Build Tools installed. That is the one platform where the quick path does not exist.

Alerts, networks and multi-tenancy by CIDR range

The output side is what makes this more than a scan result page. Alerts are acknowledgeable and cover new devices, new or risky open ports, unreachable hosts, duplicate MACs and unidentified hosts. A duplicate MAC alert in particular is the kind of finding that catches a misconfigured switch port or an address conflict before users start reporting strange connectivity.

The web console is server-rendered, with a topology map, a host list and a live event log, written in Go templates with vanilla JavaScript and all assets embedded in the binary. There is no separate frontend build and no SPA framework, so there is nothing to npm install to deploy it.

Networks are a first-class object. A deployment can manage several networks, each spanning one or more CIDR ranges, scanned independently and toggled in or out without losing history. That matters in a segmented environment where the VLAN you monitor on Monday is not the one you monitor on Tuesday.

Usage is five steps: log in, set up a network and start a scan, watch devices appear, click a device for MAC, vendor, open ports and services, OS fingerprint and screenshots, then use the topology map and the alert feed.

The optional chromedp build tag exists for the screenshot path. The README quantifies the cost precisely: it adds about 24 percent of the dependency graph and about 2MB to the binary, for a feature that already works through an external binary. It is off by default for that reason.

Licensing is the thing to read before using this at work

The repository licence is listed as Other, a custom licence that GitHub cannot classify, with the LICENSE file at the root. The LICENSE file is where the actual terms live, and for a commercial deployment that file needs reading before anyone installs it on a work network.

The custom classification is not an accident. A tool that scans a network and stores an inventory of every device with MAC addresses and vendor names touches data that in many jurisdictions is subject to employee monitoring and privacy rules, and a commercial licence rather than an open licence is a common response to that.

The repository is not archived and the last push was on 2026-08-12. The recent releases are v0.26.0 on 2026-08-10, v0.25.0 the same day and v0.24.1 on 2026-03-05, so two of three recent tags landed within hours of each other, which reads as an active project shipping in bursts.

The top-level layout also contains an experimental/ directory, a CLAUDE.md, a docs/ directory, a CNAME pointing at reconya.com, scripts/ and screenshots/, which is the shape of a project that is still moving.

Editorial conclusion

reconYa fits a network administrator or a home user who wants a continuously updated device inventory with an alert feed, on a network where the tool must not itself phone home. It does not fit a Windows-only shop, since the SQLite driver needs cgo there and the documented quick install covers Linux and macOS only, and it does not fit an air-gapped deployment outright, because the web UI still loads fonts from Google Fonts. Before deploying, leave PUBLIC_IP_LOOKUP_ENABLED, GEOLOCATION_ENABLED, VENDOR_LOOKUP_ONLINE_ENABLED and OUI_DOWNLOAD_ENABLED at false, replace the admin/password default in backend/.env, and confirm the machine's network position since ICMP sweeps and ARP lookups need privileges.

Frequently asked questions

Official sources

1. Dyneteq/reconya on GitHub
2. Issues
3. Project website
4. README
5. Releases