Multiple servers

Divide work between servers while keeping ownership and budgets clear.

Each server is an independent worker. Deploy near a target network, move load away from a laptop, or split a large set of exchanges across multiple machines. The benefit depends on network access, target capacity and how the work is divided.

Through Burp Bounty Pro

Register each server in Settings → Burp Bounty Servers, wait for Healthy and select all eligible servers in the Server Scanner dialog. Pro distributes work and can divide overall RPS/concurrency budgets. See the Pro integration guide.

Through an agent

Register two MCP aliases and tell the agent their roles. The server does not discover its peers or distribute a single create_scan automatically.

Example instruction:

Use burp_bounty_local and burp_bounty_vps. Verify both catalogues and select the same enabled profile names on each. Divide the supplied requests into disjoint batches. Keep the combined budget at 30 RPS and concurrency 10 by assigning 15 RPS and concurrency 5 to each server. Record the owning connection for every scan ID. Do not resubmit failed polling calls as new scans. Collect findings from both and preserve their source IDs when combining the report.

Prefer dividing complete requests. To split one request by vulnerability checks, assign disjoint exact profile names. Keep all steps of a multi-step profile together. Tags may overlap; two different tags are not necessarily disjoint sets.

Boundaries

Capability	Current behavior
Aggregate limit within a server	Strictest live scan budget, shared across its clients.
Aggregate limit across servers	Planned by Pro or the agent; no shared global limiter.
Catalogue synchronization	Copy/version the pack yourself; verify each live catalogue.
Deduplication	Avoid duplicate assignments; baseline/control traffic can still repeat.
Failure recovery	Reconnect to the owning server and reconcile IDs.
Failover	No automatic migration or exactly-once resubmission.
History	Stored independently on each server.

Do not move an uncertain submission to another server immediately: it may be running on the first. active_scans indicates ongoing work, not available CPU, RAM or network capacity.