Dyneteq/reconya: Go-Based Network Reconnaissance for Real-Time Asset Discovery

Dyneteq/reconya: Go-Based Network Reconnaissance for Real-Time Asset Discovery

Network visibility remains a persistent blind spot for infrastructure teams. Whether you're managing a homelab, securing a small office, or auditing cloud-adjacent networks, you can't protect what you can't see. Most discovery tools either demand enterprise licensing or bury you in configuration complexity before you find a single device.

Dyneteq/reconya takes a different approach. Built in Go with an HTMX-powered web interface, it's an open-source network reconnaissance and asset discovery tool designed for real-time device monitoring without the operational overhead. With 1,364 GitHub stars and active development through July 2026, it targets network administrators, security professionals, and home users who need immediate visibility into IPv4 and IPv6 assets.

This article walks through what Dyneteq/reconya actually does, how to deploy it correctly, and where its architectural choices create genuine trade-offs you should understand before adopting it.

What is Dyneteq/reconya?

Dyneteq/reconya is a network reconnaissance and asset discovery tool maintained by Chris Veleris under the Dyneteq organization. Written primarily in Go, it combines native network scanning capabilities with a lightweight web dashboard rendered through HTMX templates rather than a heavy JavaScript^{↗ Bright Coding Blog} frontend framework.

The project sits at the intersection of several active technical trends: the resurgence of hypermedia-driven applications (HTMX), Go's dominance in systems and networking tools, and growing demand for self-hosted observability without SaaS dependencies. Its 1,364 stars and 103 forks indicate modest but genuine community traction—not viral hype, but sustained utility for a specific use case.

Reconya's architecture reflects deliberate constraints. It uses SQLite for device storage and event logging rather than requiring external database setup. The backend exposes port 3008 for web access. Scanning logic is implemented natively in Go without wrapping external tools like Nmap or Masscan, which simplifies deployment but places implementation burden on the maintainers.

The license requires attention: Creative Commons Attribution-NonCommercial 4.0 International. Commercial use requires explicit permission from the maintainer. This isn't standard for developer tools (most use Apache-2.0 or MIT), and it affects adoption decisions for organizations. The "Other" license classification in repository metadata reflects this non-standard choice.

Notably, the project explicitly rejects Docker^{↗ Bright Coding Blog} as a primary deployment method—a rare stance worth understanding, covered in detail below.

Key Features

Dyneteq/reconya's capabilities cluster around four operational areas: discovery, identification, monitoring, and interface.

IPv4 Network Scanning uses native Go implementations for ICMP ping sweeps, TCP connect probes to common ports as fallback, and ARP table lookups for MAC resolution. The 30-second discovery cycle provides near-real-time visibility without the configuration complexity of enterprise NMS platforms.

IPv6 Passive Monitoring distinguishes Reconya from tools focused exclusively on legacy IP. It monitors Neighbor Discovery Protocol (NDP) caches and network interfaces to detect IPv6 devices without generating probe traffic. The system classifies addresses into Link-Local (fe80::/10), Unique Local (fc00::/7), and Global (2000::/3) scopes, and correlates IPv6 addresses to IPv4 devices via shared MAC addresses when possible.

Device Identification combines IEEE OUI database lookups for vendor detection with multi-method hostname resolution (DNS, NetBIOS, mDNS). Device type classification derives from open ports and vendor fingerprints rather than active OS fingerprinting probes.

Port Scanning and Service Detection runs as background workers scanning top 100 ports with concurrent worker pools. It performs banner grabbing and automatically discovers HTTP/HTTPS services, capturing screenshots via headless Chrome and extracting metadata like page titles and server headers.

Real-Time Web Dashboard delivers live device status through HTMX's server-rendered partial updates rather than WebSocket or polling-heavy SPAs. The dark-themed interface shows device lists, network maps, event logs, and per-device detail views including ports, services, OS fingerprints, and web screenshots.

Multi-Network Management supports CIDR-based network configuration for segmented environments, with dropdown selection between configured networks.

Use Cases

Homelab and Small Office Visibility For operators running mixed environments—IoT devices, VMs, containers, and physical hardware—Reconya provides unified discovery without SNMP configuration or agent deployment. The SQLite backend eliminates database administration overhead suitable for single-administrator contexts.

Security Audit Baselines Before hardening a network, you need accurate asset inventory. Reconya's automated discovery establishes baseline device populations, identifies unauthorized hardware via MAC address changes, and tracks service exposure through port scanning. The event log captures network activity patterns for anomaly detection.

IPv6 Transition Monitoring Organizations migrating to dual-stack infrastructure often lack visibility into IPv6 device populations because legacy tools ignore NDP and interface monitoring. Reconya's passive IPv6 detection fills this gap without requiring active scanning that might disrupt sensitive IPv6 configurations.

Web Service Inventory The automatic HTTP/HTTPS discovery with screenshot capture serves web operations teams needing to catalog internal applications, identify shadow IT deployments, or verify SSL/TLS configurations across discovered endpoints.

Incident Response Preparation During active incidents, rapid device enumeration becomes critical. Reconya's pre-configured network definitions and 30-second scan cycles provide faster initial visibility than tools requiring scan policy configuration during high-stress events.

Installation & Setup

Reconya offers two supported installation paths: pre-built binary or source compilation. Docker is explicitly not recommended due to network architecture limitations preventing reliable Layer 2 MAC address discovery.

Quick Install (Pre-built Binary)

The fastest deployment uses the install script with auto-detection for OS and architecture:

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

Supported platforms: Linux (x86_64, ARM64), macOS (Intel, Apple Silicon).

After installation:

cd reconya && sudo ./reconya-*

Then access http://localhost:3008 with default credentials admin / password.

The sudo requirement is significant: privileged mode is necessary for ICMP ping sweeps and ARP table access. Running unprivileged degrades discovery capabilities.

Build from Source

For customization or platforms without pre-built binaries:

Prerequisites:

• Go 1.21 or later
• make (pre-installed on most Unix systems)

One-command installation:

git clone https://github.com/Dyneteq/reconya.git
cd reconya
make install

This downloads dependencies and creates a default .env configuration file.

Post-installation commands:

make start       # Start reconYa as daemon
make start-dev   # Start in foreground (dev mode)
make stop        # Stop reconYa
make status      # Check service status
make logs        # View logs
make help        # Show all commands

Access at http://localhost:3008, default login admin / password.

Manual Installation

For explicit control over the build process:

# Clone repository
git clone https://github.com/Dyneteq/reconya.git
cd reconya

# Setup backend
cd backend
cp .env.example .env
# Edit .env to set credentials
go mod download

# Start application
cd backend
go run ./cmd

Windows-specific note: If SQLite CGO errors appear:

cd backend
CGO_ENABLED=1 go run ./cmd

This requires a C compiler (TDM-GCC or Visual Studio Build Tools).

Configuration

Edit backend/.env for customization:

LOGIN_USERNAME=admin
LOGIN_PASSWORD=your_secure_password
DATABASE_NAME="reconya-dev"
JWT_SECRET_KEY="your_jwt_secret"
SQLITE_PATH="data/reconya-dev.db"

# IPv6 Monitoring Configuration
IPV6_MONITORING_ENABLED=true
IPV6_MONITOR_INTERFACES=
IPV6_MONITOR_INTERVAL=30
IPV6_LINK_LOCAL_MONITORING=true
IPV6_MULTICAST_MONITORING=false

The empty IPV6_MONITOR_INTERFACES defaults to all interfaces. Specifying interfaces restricts monitoring to defined network segments.

Real Code Examples

The README provides explicit commands for operational workflows. Below are reproduced examples with contextual explanation.

Binary Installation and Launch

# Download and install with automatic platform detection
curl -sL https://raw.githubusercontent.com/Dyneteq/reconya/master/install.sh | sh

# Navigate to installation directory and start with elevated privileges
cd reconya && sudo ./reconya-*

The pipe-to-shell pattern (| sh) is common for developer tools but warrants security awareness—review the script contents before execution in sensitive environments. The sudo prefix enables raw socket access for ICMP and ARP operations; without it, Reconya falls back to TCP connect scanning with reduced accuracy.

Makefile-Driven Development Workflow

# Clone and build from source
git clone https://github.com/Dyneteq/reconya.git
cd reconya
make install

# Development iteration cycle
make start-dev   # Foreground mode with direct log output
make stop        # Clean shutdown
make logs        # Post-hoc log review

The make install target encapsulates dependency resolution and environment setup, reducing onboarding friction. The separation between make start (daemon) and make start-dev (foreground) supports both production deployment and debugging contexts.

Windows CGO-Enabled Build

cd backend
CGO_ENABLED=1 go run ./cmd
# For binary builds:
make build-cgo

This addresses the go-sqlite3 driver's CGO requirement. The standard go run ./cmd may fail on Windows with "Binary was compiled with 'CGO_ENABLED=0'" because the pure-Go SQLite alternatives aren't used. The explicit flag ensures the C bridge compiles correctly.

Environment Configuration Template

# Core authentication
LOGIN_USERNAME=admin
LOGIN_PASSWORD=your_secure_password
JWT_SECRET_KEY="your_jwt_secret"

# Storage paths
SQLITE_PATH="data/reconya-dev.db"

# IPv6 tuning
IPV6_MONITORING_ENABLED=true
IPV6_MONITOR_INTERVAL=30

The JWT secret requires cryptographic strength for session security in multi-user deployments. The 30-second IPv6 monitor interval balances responsiveness against system load; reducing this increases CPU usage without proportional discovery benefit on stable networks.

Advanced Usage & Best Practices

Deployment Topology: Run Reconya on a host within each target broadcast domain. MAC address discovery fails across routed segments—this is fundamental ARP behavior, not a tool limitation. For multi-segment environments, deploy instances per subnet or accept IP-only visibility for remote segments.

Credential Hardening: Change default credentials before network exposure. The .env file stores plaintext passwords; restrict filesystem permissions (chmod 600 backend/.env) and exclude from version control.

Scan Timing Tuning: The default 30-second discovery cycle suits dynamic environments. For stable infrastructure, consider extending intervals to reduce background traffic. Conversely, during active incident response, temporary manual scans via the web interface supplement automatic discovery.

IPv6 Strategy: Enable IPV6_LINK_LOCAL_MONITORING=true for local segment visibility, but evaluate IPV6_MULTICAST_MONITORING=false (default) carefully. Multicast monitoring increases discovery scope but generates additional traffic; enable only when Unique Local or Global address visibility is insufficient.

Screenshot Storage: Headless Chrome captures consume disk space proportionally to discovered web services. Monitor data/ directory growth and implement retention policies for the SQLite database and screenshot artifacts.

Docker Avoidance: The experimental/ directory contains container configurations, but the maintainers explicitly moved these from primary support due to Docker's network isolation preventing Layer 2 MAC access. For environments requiring containerization, consider host-network mode with privileged caps as an experimental path, with acceptance of degraded identification accuracy.

Comparison with Alternatives

Nmap offers deeper inspection capabilities and scripting extensibility but lacks persistent monitoring and device relationship tracking without additional tooling. Reconya trades probe sophistication for operational simplicity and continuous monitoring.

OpenNMS/NetBox target enterprise scale with multi-user workflows, asset lifecycle management, and extensive integrations. Reconya's SQLite backend and single-binary deployment suit smaller scopes where database administration overhead is undesirable.

Fing provides polished mobile and desktop experiences but requires proprietary cloud connectivity for full features. Reconya's self-hosted model maintains data locality, critical for sensitive network environments.

The non-commercial license is Reconya's most significant comparative limitation—organizations must negotiate commercial terms or select alternatives for production infrastructure management.

FAQ

Why does Reconya require sudo? Raw socket access for ICMP echo requests and ARP table reads requires elevated privileges. Without sudo, TCP connect scanning operates but MAC address discovery fails.

Can I run Reconya in Docker? Technically possible via experimental/ configurations, but MAC address discovery is unreliable due to container network isolation. Local installation is recommended for full functionality.

What Go version is required? Go 1.21 or later for source builds. Pre-built binaries eliminate this requirement.

Is commercial use permitted? No—the CC BY-NC 4.0 license requires explicit permission for commercial applications. Contact the maintainer for licensing terms.

How does IPv6 discovery work without active scanning? Passive monitoring of Neighbor Discovery Protocol caches and interface addresses detects IPv6 presence without generating probe traffic.

What databases are supported? SQLite only. The SQLITE_PATH configuration controls file location; no external database server is required.

How do I troubleshoot missing devices? Verify same-network-segment placement, check make status for service health, and confirm port 3008 availability. Some devices suppress ARP responses by design.

Conclusion

Dyneteq/reconya occupies a specific niche: teams needing continuous, lightweight network visibility without enterprise NMS complexity or SaaS dependencies. Its Go-native implementation, HTMX dashboard, and SQLite backend prioritize operational simplicity over feature breadth.

The tool fits best for homelab operators, small security teams, and organizations in early network inventory phases. The explicit Docker rejection and non-commercial license are genuine constraints—not marketing positioning—that shape adoption decisions. Users accepting local installation and evaluating license terms gain a responsive, low-maintenance discovery platform.

For teams ready to deploy, start with the pre-built binary at https://github.com/Dyneteq/reconya and validate discovery accuracy in your specific network topology before scaling deployment. The 30-second feedback cycle between configuration changes and visible results supports rapid iterative tuning.

For broader infrastructure observability strategies, see [INTERNAL_LINK: network-monitoring-tools-comparison] for additional context on integrating Reconya into multi-tool workflows.