> For the complete documentation index, see [llms.txt](https://docs.bountysecurity.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bountysecurity.ai/burp-bounty-server/distributed-scanning.md).

# Multiple servers

Distribute scans across as many servers as you need, through Pro or MCP agents.

Deploy **as many Burp Bounty Server instances as you need** on workstations, dedicated servers or VPSs. The workflow is not limited to a local server and one remote server: add more instances to increase capacity or reach different target networks.

Deployments remain subject to [per-user licensing and activation limits](/licensing.md): each license has 10 registered activations, shared across Pro and Server when using a Pro license. Multiple server connections do not provide extra activations or user seats.

Connect them in either of these ways:

* **Burp Bounty Pro:** add each instance in Settings and let the extension distribute the submitted work across eligible servers.
* **AI agents:** register each instance as a named MCP connection and instruct the agent to divide the work across those connections.

```mermaid
flowchart LR
    pro["Burp Bounty Pro"] -->|REST| servers["Server 1, Server 2, ... Server N"]
    agent["AI agent"] -->|"One MCP connection per server"| servers
    servers --> work["Assigned requests and profiles"]
    work --> findings["Findings from each server"]
```

Each server is an independent worker. The benefit depends on network access, target capacity and how the work is divided.

## Through Burp Bounty Pro

Register each instance in **Settings → Burp Bounty Servers**, repeating Add for every server you want to use. 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](/burp-bounty-pro/remote-scanning.md).

## Through an agent

Register one MCP connection per server, with a unique alias, endpoint and the license header configured for that instance. Repeat for every server you want the agent to use, then identify the eligible aliases and any roles or network restrictions. The agent assigns work through each connection; a server does not discover its peers or distribute a single `create_scan` automatically.

Example with five registered servers (the count is illustrative):

> Use `scanner_1`, `scanner_2`, `scanner_3`, `scanner_4` and `scanner_5`. Verify every server's status and catalogue, and select the same enabled profile names on each. Divide the supplied requests into five disjoint batches. Keep the combined budget at 30 RPS and concurrency 10 by assigning 6 RPS and concurrency 2 to each server. Record the owning connection for every scan ID. Do not resubmit failed polling calls as new scans. Collect findings from all participating servers and preserve their source IDs when combining the report.

For a different number of servers, adjust the assignments so their RPS and concurrency totals stay within the requested combined budget. Use fewer workers when the available work or budget cannot support all of them.

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.