> 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-pro/remote-scanning.md).

# Connect Burp Bounty Servers

Keep Burp as your workspace and move scan execution to your servers.

Connect as many Burp Bounty Server instances as you need and distribute scans across them from Burp. Servers can run on your own machines, dedicated hosts or VPSs; the extension is not limited to two instances.

Your Pro license covers one individual user and includes **10 registered activations shared between Pro and Server**. See [users, products and activations](/licensing.md); adding server connections does not increase this allowance or provide extra user seats.

## Add a server

1. Start the server and set its `BURPBOUNTY_LICENSE_KEY` environment variable.
2. Open **Burp Bounty Pro → Settings → Burp Bounty Servers → Add**.
3. Enter a descriptive name, a complete **Server URL**, and the **same license key used by that server**.
4. Enable **Use this server for scans** and save.
5. Wait for **Healthy** before dispatching work.

Repeat these steps for each additional server. Use descriptive names so you can recognize its location or role.

{% hint style="info" %}
**Server URL**

Use a base URL such as `http://127.0.0.1:8081` or `https://scanner.example.test:8443`. This is the REST base URL, not `/mcp`. Burp must be able to reach it from the machine running the extension. A saved server credential is independent of text entered in Pro's own activation tab.
{% endhint %}

Health checking uses the license header too. An open browser tab at `/health` without that header is not an authenticated health check.

## Launch remotely

Choose **Burp Bounty Pro → Burp Bounty Server Scanner → Active Scan** or **Passive Scan**, then a tag. Select a specific eligible server or all eligible servers. Only enabled, healthy servers participate.

Pro packages the selected profiles and exchanges for each server. It preserves the original service protocol and port. You do not need `--mcp` or `--profiles-dir` for this workflow.

For passive response checks, capture the response before submitting. Pro shows retrieved passive findings in **Scanners → Passive** as well as Burp's issues.

## Multiple servers and budgets

The extension distributes work items among eligible servers. It does not split every HTTP request into a transparent cluster or migrate a running scan.

Let **N** be the number of servers participating in this batch:

| Choice                            | Behavior across N servers                                                   |
| --------------------------------- | --------------------------------------------------------------------------- |
| Req/Sec limit per server = 30     | Each server receives 30 RPS; combined traffic may reach 30 × N RPS.         |
| Overall Req/Sec limit = 30        | Pro divides the total of 30 RPS across participating servers.               |
| Concurrency limit per server = 10 | Each server receives concurrency 10; combined concurrency may reach 10 × N. |
| Overall concurrency limit = 10    | Pro divides the total concurrency of 10 across participating servers.       |

The amount of work and small overall budgets can reduce how many configured servers participate in a particular batch. Other live scans on a server can impose a stricter shared limit. This is distribution of the submitted batch, not a global cross-client target limit.

## Connection loss and controls

Each scan retains its owning server and ID. Temporary failures cause reconnection and result/control reconciliation. Do not launch the same batch again merely because polling is slow: the first submission may already be running.

Pause, resume and cancel are sent to the owning server. If the server is unreachable, inspect the recovered state when contact returns. There is no automatic migration to another server.

## Persistence

Findings added to Burp can be retained in a persistent Burp Suite Professional project. Extension/server scan-row state is not equivalent to that project history. Pro's current REST submissions do not request persistent Server history by default; see [results and retention](/burp-bounty-server/results-and-retention.md) for MCP and REST opt-in behavior.