Nonce Bitcoin Mining: Multi-Farm Agent Deployment and Network Isolation Guide

When a Bitcoin farm grows from one site to many, miner management quickly shifts from "how do I find miners" to "how do I manage different farms safely and stably as one." Especially when farms may sit in different cities or countries, use different ISPs, routers, and VLANs, and even have different hosts managing the network. Bridging every miner network together is not only hard to maintain—it also widens the blast radius of faults and security incidents.

Nonce multi-farm management does not require every miner to share one LAN. A better approach is: each independent farm deploys a local Nonce Agent that can reach that farm's miner network; the Agent handles discovery, status collection, and task execution; Nonce then organizes multiple Farms in an upper Workspace. Each farm keeps its own LAN, subnets, and security boundary, while HQ ops can still view and manage many farms in one UI. That is the most important multi-farm principle: unified management does not mean a unified network.

What Does the Nonce Agent Do in a Multi-Farm Architecture?

Before multi-farm deployment, clarify where the Nonce Agent sits. In Nonce, a Workspace organizes Farms, miners, and Agents under one organization, while a Farm is a group of miners that share geography, power, or network context. Nonce Workspace creation and organization Nonce Farm creation guide

The Agent runs on a Linux host at the farm. That host must reach the miners over the network. After ops creates a scan job in Nonce, the Agent fetches it, scans the configured IP ranges, identifies miners, collects device info, and returns results to Nonce. After scanning, the Agent keeps collecting miner data on a cycle so status stays current. Nonce Agent scan mechanism

So a typical data path is Nonce → on-site Agent → ASIC miners, and ASIC miners → on-site Agent → Nonce.

The Agent is the local bridge between the cloud management layer and the farm equipment network. For farms whose physical sites are independent, it is better for each site to have its own Agent than to force one huge Layer-2 network that can reach every farm's ASICs.

How Should Agents Be Deployed Across Multiple Farms?

Teams with multiple farms can organize infrastructure as Workspace → Farm → Agent → miner network. For example, a company with three farms:

Logical layer	Farm A	Farm B	Farm C
Workspace	Same enterprise Workspace	Same enterprise Workspace	Same enterprise Workspace
Farm	Texas-01	Texas-02	Paraguay-01
Agent	Agent-A	Agent-B	Agent-C
Miner subnets	10.10.x.x	10.20.x.x	10.30.x.x
Network boundary	Independent	Independent	Independent
Must farms interconnect?	No	No	No

The last row matters most. Farm A's Agent only needs to reach miners managed in Farm A; Farm B's Agent only needs Farm B's miners. To manage multiple farms as one, you do not need Farm A's miners to reach Farm B's miners directly.

That architecture is clearer and closer to common large-infrastructure zoning. NIST's zero-trust architecture stresses that a device should not be trusted merely because it sits on the enterprise network; network location should not be the sole basis for access. NIST SP 800-207 Zero Trust Architecture

Farms can use a similar idea: between sites, device groups, and management resources, open only the communication the business needs—not open every subnet just because "they're all our miners."

If One Farm Has Multiple VLANs, Where Should the Agent Sit?

Large farms rarely have one flat LAN. As ASIC count grows, ops often split VLANs by hall, container, power zone, miner type, or management use. One site may have:

Network zone	Example use
Management VLAN	Routers, switches, servers, ops gear
ASIC VLAN 101	Zone A miners
ASIC VLAN 102	Zone B miners
ASIC VLAN 103	Zone C miners
Office network	Staff PCs and office devices
Guest network	Temporary and guest devices

That does not mean the Agent must share a VLAN with every miner. The real requirement is that the Linux host running the Agent can reach the ASICs it must manage via routing and access-control rules. Nonce scanning also probes addresses in configured IP ranges one by one, so if routing, firewalls, or VLAN ACLs sit between the Agent and target miner subnets, confirm those paths work first. For example:

Management VLAN
      |
   Agent
      |
Firewall / Router
   |    |    |
VLAN101 VLAN102 VLAN103
   |      |      |
 Miners Miners  Miners

Prefer putting the Agent on a dedicated management network rather than dumping the Agent and all miners into one huge broadcast domain. Use Layer-3 routing and firewall policy to allow the Agent only to miner networks it must manage.

CISA also recommends routing access control, stateful firewalls, and VLANs to separate device groups and reduce unnecessary east-west access. CISA network segmentation and infrastructure hardening guidance

This is the farm's own network design—not a topology Nonce mandates—but for thousands or tens of thousands of ASICs it is usually easier to maintain than "everything in one network."

Full Multi-Farm Agent Deployment Flow in Nonce

In practice, build the org layers in Nonce first, then deploy farm by farm—do not wait until every network rebuild is finished before connecting anything.

Step one: create different Farms in a Workspace. One Workspace can organize Farms, miners, and Agents for the same organization, so HQ keeps one management entry while physical sites remain separate Farms.

Step two: prepare an Agent host at each farm. Nonce Agent currently runs on Linux such as Ubuntu, Debian, or CentOS. During install, the system generates a Shell install command; copy it to a server or computer that can reach the miner network and run it.

Step three: confirm connectivity between the Agent host and the miner network. Do not only test "can the Agent reach the internet"—confirm the Agent can reach the miner IPs you plan to manage. For cross-VLAN deploy, check routing, firewall ACLs, target subnets, and miner responsiveness.

Step four: add IP ranges to scan in the Farm, then run discovery. Nonce can save scan ranges and periodically rescan saved auto-scan ranges to find miners that join later. Nonce scan miners guide

Step five: reconcile device count, models, and status. Do not assume every miner joined correctly just because a scan job finished. Compare actual ASIC count, Agent discovery count, and what Nonce shows—especially missed subnets, IP changes, cross-VLAN moves, and devices after password changes.

After one Farm is done, deploy the next the same way. Eventually:

Workspace
├── Farm A
│   └── Agent A
│       ├── ASIC VLAN 101
│       └── ASIC VLAN 102
│
├── Farm B
│   └── Agent B
│       ├── ASIC VLAN 201
│       └── ASIC VLAN 202
│
└── Farm C
    └── Agent C
        └── ASIC VLAN 301

This scopes faults more cleanly than one central server scanning every farm across the public internet, VPN, or complex leased lines. Even if one farm's local network fails, other sites need not share its ASIC network.

After Network Isolation, What Communication Should Be Open?

Isolation is not "block everything"—it changes default full access into openings by business need.

For the Agent network, two connections matter most: Agent ↔ local miners for data collection and management, and Agent ↔ Nonce services for a stable link. Exact ACLs should follow miner brands, firmware, deploy style, and current Agent config—do not blindly apply a fixed port list without validation.

So a better firewall design mindset is:

Direction	Needed?	Recommendation
Agent → this Farm's ASICs	Yes	Open only miner subnets that must be managed
Agent → Nonce services	Yes	Keep stable outbound connectivity
ASIC → Agent	Depends on the actual protocol path	Configure per status collection and management needs
Farm A ASIC → Farm B ASIC	Usually no	Isolate by default
Office net → ASIC network	Usually not fully open	Limit via management network
Guest net → ASIC network	No	Isolate
Public internet → ASIC management UI	Not recommended	Avoid exposing miner management interfaces

Distinguish clearly between "connections Nonce needs" and "farm security recommendations." Nonce requires that the Agent host can stably reach miners to manage; VLAN design, firewall policy, and office isolation are the farm's own security architecture. Network quality between the Agent host and miners also affects scan speed and collection quality. Nonce Agent hardware and deployment requirements

How Many Agents Do Multiple Farms Need?

Agent count should not be a mechanical "one farm equals one Agent." Base it on reachability, miner count, fault isolation, and site structure.

Nonce's current Agent hardware guidance uses about a 5-minute collection cycle as baseline: ~1,000 miners can use a Raspberry Pi 5 or similar SBC; ~10,000 miners suggest at least a mid-range quad-core with 4 GB RAM; ~20,000 suggest 8 GB RAM and eight-core class; ~30,000 suggest 16 GB RAM; above ~50,000 suggest a higher-spec server. Scanning, firmware work, or multiple Agent instances on one host also need more resources. Nonce Agent hardware requirements

So the decision can be simplified as:

Different physical sites → prefer separate Agents; different security domains → consider separate Agents; very large fleets → split Agents by resources and network structure; if the network can already safely route to multiple miner VLANs, do not add Agents just because VLAN count grew.

For multi-farm ops, fewer Agents is not always better. Over-centralizing cuts server count but can let one Agent, one network node, or one firewall rule affect too many miners. Sensible splits shrink the fault domain.

If the Agent Cannot Find Miners, Why Check the Network First?

One of the most common multi-farm issues is that the Agent is online but some ASICs never appear in the miner list. Usually you should not reinstall the Agent first—check scan ranges and network paths first.

In Nonce troubleshooting, IP range is a key check. Common cases include wrong subnet, scanning the management net instead of the miner net, ranges set too large, and miners moved to another VLAN or subnet. Routing, packet loss, and firewall rules can also slow discovery or fail scans. Nonce Agent scan troubleshooting

A more efficient order is:

Is the Agent online?
        ↓
Did the scan job run?
        ↓
Is the IP range correct?
        ↓
Can the Agent reach the target VLAN?
        ↓
Is a firewall / ACL blocking?
        ↓
Is the miner password correct?
        ↓
Are model and firmware supported?

Especially after expansion, rack moves, or network re-splits, ASICs may have moved from the old IP range to a new subnet. If the Agent still only scans the old range, devices may mine fine yet never be discovered by the management platform.

Multi-Farm Management Is Not About Bridging Networks—It Is About Unifying the Management Layer

Once you grow from one farm to five, ten, or more sites, what must be unified is miner status, anomaly discovery, permissions, ops process, and operating data—not the underlying ASIC networks.

Nonce's multi-farm architecture lets one Workspace organize many Farms, while each Farm connects to its own miner network through a local Agent. HQ can view farms under one management system while sites keep independent network boundaries.

Ultimately, a structure that fits scaled Bitcoin farms is: unified above, isolated below; centralized management, partitioned networks; Agents close to the miners—not miner management UIs exposed to the public internet.

For teams with many countries, many hosted sites, or large ASIC fleets, another advantage is that adding a farm does not require redesigning the whole enterprise network. Create a Farm, prepare a local Linux host, install the Agent, configure miner IP ranges, scan—and the new site joins the existing Nonce management system. Nonce's standard onboarding is itself organized as create Workspace → create Farm → install Agent → scan miners → view Farm.

That is the multi-farm Agent design principle most worth keeping: do not sacrifice network isolation to get centralized management. A good farm management architecture should let independent sites be observed and operated together while shrinking how far any single network fault, security event, or config error can spread.