Planning Daemon Deployment

Daemons are lightweight agents that scan your network and report findings to the server. Most networks need at least one, and many need several. This guide helps you decide how many daemons to deploy and where to place them based on your network topology.

Layer 2 vs Layer 3 discovery

This tradeoff drives every decision on this page. When a daemon has a network interface on a subnet, it gets Layer 2 access. When it can only route to a subnet, it's limited to Layer 3.

Layer 2 is always preferred. It's faster, finds more devices, and gives you complete visibility. Layer 3 is a fallback for subnets where you can't place a daemon — it will miss hosts that don't have open ports and won't collect MAC addresses. When planning your deployment, aim for Layer 2 coverage on every segment you care about.

See Layer 2 vs Layer 3 for more detail.

Deployment strategies

Single daemon with routing

Start with one daemon and extend its reach before adding more. A single daemon automatically scans every subnet its host has an interface on (Layer 2). It can also scan remote subnets it can route to, but those fall back to Layer 3 — a good way to get initial visibility while you plan where to place additional daemons for full coverage.

Extending what a single daemon scans:

• Remote subnets: The daemon can scan subnets it can route to but doesn't have an interface on (Layer 3 only). See Scanning Remote Subnets.
• VPN networks: If the daemon's host is connected to a VPN, it can scan that network with full Layer 2 access. See Scanning VPN Networks.

Best for: Getting started quickly. For subnets the daemon can only route to, plan to deploy additional daemons for full Layer 2 coverage when you can.

Daemon per network segment

Deploy a daemon on each VLAN or network segment for full Layer 2 access everywhere.

Each daemon runs on a host within its segment and reports full Layer 2 data. Install each one through Discover > Daemons — see Managing Daemons for setup instructions.

When a device appears on multiple VLANs, it may show up as separate hosts. Use host consolidation to merge them.

Best for: Any multi-segment network. This is the ideal deployment — every segment gets full discovery. Required for isolated networks with no routing between segments.

Multiple daemons on one host

Run several daemon instances on a single machine that bridges multiple isolated networks. This is common with hypervisors, routers, or servers that have interfaces on VLANs that don't route to each other.

Each instance gets a name and is restricted to specific interfaces so they don't overlap:

scanopy-daemon --name production --interfaces eth0
scanopy-daemon --name iot --interfaces eth1

Create a separate daemon entry in Discover > Daemons for each instance. Each gets its own API key and can target the same or different Scanopy networks.

This gives you Layer 2 discovery on each segment without needing a separate physical host per VLAN. See Scanning Isolated Networks from One Host for the full setup guide, including config namespacing, systemd templates, and Docker configuration.

Best for: Hypervisors, routers, or multi-NIC servers bridging isolated VLANs where deploying separate hosts isn't practical.

Hybrid

Use a central daemon for routable subnets and add dedicated daemons only where you need Layer 2 access or where networks are truly isolated. Most real-world deployments end up here — one daemon covers the majority of the network, with one or two more for specific segments.

Choosing a polling mode

Each daemon uses a polling mode that determines which side initiates the connection.

Use DaemonPoll unless your daemon cannot reach the server. It's simpler to set up and requires no inbound firewall rules on the daemon host.

Network requirements

Firewall rules for DaemonPoll mode (default)

Daemon initiates all connections. Minimal firewall changes needed.

Firewall rules for ServerPoll mode

Server initiates scan requests. Daemon must be reachable.