Connect Burp Bounty Servers

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

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.

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.

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.

Choice	Example with two servers
Req/Sec limit per server = 30	Each server receives 30 RPS; combined traffic may reach 60 RPS.
Overall Req/Sec limit = 30	Pro divides 30 between the selected servers.
Concurrency limit per server = 10	Each server receives concurrency 10.
Overall concurrency limit = 10	Pro divides 10 across participating servers.

Small overall budgets can reduce how many servers are used. 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 for MCP and REST opt-in behavior.