Scanning Isolated Networks from One Host

This guide walks through running multiple daemon instances on a single host, each scanning different interfaces or network segments. For help deciding whether this is the right approach for your network, see Planning Daemon Deployment.

How config namespacing works

Every daemon instance has a name. The default is scanopy-daemon. When you pass --name, the daemon stores its configuration in a subdirectory named after that value:

Each named daemon gets its own config file with its own daemon ID, API key, server URL, and runtime state. They are fully independent — starting, stopping, or reconfiguring one does not affect the others.

Platform paths:

Restricting daemons to specific interfaces

Use --interfaces to limit which network interfaces a daemon scans. Without it, the daemon scans all interfaces.

# Scan only eth0
scanopy-daemon --name eth0 --interfaces eth0

# Scan two interfaces
scanopy-daemon --name production --interfaces eth0,eth1

The same setting works as an environment variable or in the config file:

# Environment variable
SCANOPY_INTERFACES=eth0,eth1

# config.json
{ "interfaces": ["eth0", "eth1"] }

When --interfaces is set, the daemon only reports and scans subnets attached to those interfaces. This prevents overlap between daemon instances sharing the same host.

Setting up multiple daemons

Create a separate daemon entry in Discover > Daemons for each instance. Each daemon gets its own API key and can target the same or different networks. During setup, use the Advanced tab to configure interface restrictions under Network Discovery. The app provides platform-specific install and run commands with your settings included.

After first run, each daemon persists its settings to its namespaced config file. Subsequent starts only need the name:

sudo scanopy-daemon --name eth0
sudo scanopy-daemon --name eth1

systemd template (Linux)

Scanopy provides a systemd template unit [email protected] for running multiple instances. Copy it to your systemd directory:

sudo cp [email protected] /etc/systemd/system/
sudo systemctl daemon-reload

The template uses the instance identifier as both --name and --interfaces:

ExecStart=/usr/local/bin/scanopy-daemon --name=%i --interfaces=%i
SyslogIdentifier=scanopy-daemon-%i

Enable and start instances by appending the interface name after @:

sudo systemctl enable --now scanopy-daemon@eth0
sudo systemctl enable --now scanopy-daemon@eth1

Each instance gets separate journal logs:

journalctl -u scanopy-daemon@eth0
journalctl -u scanopy-daemon@eth1

Listing existing daemon configs

To see which named daemons are configured on a host, list the config directory:

# Linux
ls ~/.config/scanopy/daemon/

# macOS
ls ~/Library/Application\ Support/com.scanopy.daemon/

# Windows
dir %APPDATA%\scanopy\daemon\

Each subdirectory corresponds to a named daemon instance. A config.json at the top level is the default (unnamed) daemon.

Upgrading and restarting

All daemon instances share the same binary. When the app shows an upgrade is available, it provides stop, install, and start commands. With multiple daemons you need to stop and restart each instance individually:

# systemd template instances
sudo systemctl stop scanopy-daemon@eth0
sudo systemctl stop scanopy-daemon@eth1

# replace the binary (use the install command from the app)

sudo systemctl start scanopy-daemon@eth0
sudo systemctl start scanopy-daemon@eth1

Configuration is preserved across upgrades — each daemon reads its settings from its own config file on startup.

Docker

For Docker deployments, run a separate container per daemon instance. Use the install commands from the app for each daemon entry and add the SCANOPY_INTERFACES environment variable to restrict each container to its assigned interface. Both containers need network_mode: host to access host interfaces.