Best Self-Hosted Load Generation & Traffic Replay Tools 2026: GoReplay, Siege, wrk, and Vegeta

Every infrastructure team eventually faces the same question: can our services handle what’s coming? Whether you’re launching a new feature, preparing for a seasonal traffic spike, or validating architecture changes, you need real load data. Commercial platforms charge per virtual user, per test hour, or per report. The open-source alternatives cost nothing, run on your own hardware, and give you full control over every request.

This guide covers the best self-hosted load generation and traffic replay tools available in 2026: GoReplay for production traffic replay, Siege for simple concurrent load testing, wrk for high-performance HTTP benchmarking, Vegeta for constant-rate load generation, and k6 for developer-friendly scripting. You’ll learn when to use each tool, how to install and configure them, and how to interpret results.

Why Self-Host Your Load Testing Infrastructure

Running load tests against staging environments with cloud-based services introduces several problems that self-hosted tools eliminate:

• Data privacy: Cloud load testing services send your actual URLs, headers, and request payloads through their infrastructure. For internal APIs, healthcare endpoints, or financial services, this is often a compliance violation. Self-hosted tools keep all traffic within your network perimeter.
• Network realism: Cloud-based generators test your application from a single external IP and network path. Self-hosted tools let you generate traffic from the same network topology your real users experience — same latency, same NAT, same egress points.
• Cost at scale: A 24-hour soak test with 10,000 virtual users can cost hundreds of dollars on commercial platforms. Running the same test on a spare VM or a few containers costs the price of electricity.
• No rate limits or quotas: When you’re iterating on a fix, you want to run tests back-to-back. Cloud services throttle you; self-hosted tools don’t.
• Custom protocols: Most cloud platforms only support HTTP and HTTPS. Self-hosted tools like GoReplay and Vegeta can replay any TCP-based protocol, including WebSocket connections, gRPC calls, and raw socket traffic.
• Integration with internal monitoring: When your load generator runs inside the same datacenter, you can correlate test results with internal metrics from prometheus, Grafana, or your APM system without cross-network noise.

Understanding the Different Approaches

Load generation tools fall into three categories, and choosing the right one depends on what you’re trying to validate:

The fundamental difference is that traffic replay tools don’t generate synthetic requests — they capture real ones and play them back. This means your tests automatically include the right mix of endpoints, request sizes, timing patterns, and header combinations that your actual users produce.

HTTP benchmarking tools are the fastest way to answer a simple question: how many requests per second can this endpoint handle? They’re ideal for comparing configurations, validating code changes, or establishing baseline numbers.

Programmable load tools give you the most control. You define the request rate, the payload mix, the ramp-up curve, and the pass/fail criteria in code. Use these when you need to test specific scenarios like “what happens when 80% of traffic hits the search endpoint simultaneously.”

GoReplay: Production Traffic Replay

GoReplay is the most powerful open-source tool for capturing live HTTP traffic and replaying it against a staging environment. It sits between your load balancer and backend servers, records requests and responses, and can replay them at any speed you choose.

How GoReplay Works

GoReplay captures HTTP traffic at the TCP level using libpcap. It reconstructs complete HTTP requests and responses, stores them in a binary format, and replays them with exact timing reproduction or at an accelerated/decelerated rate. Because it captures at the network level, it works with zero changes to your application code.

1
2
3
4

# Install GoReplay
wget https://github.com/buger/goreplay/releases/download/v2.0.5/gor_2.0.5_x64.tar.gz
tar -xzf gor_2.0.5_x64.tar.gz
sudo mv gor /usr/local/bin/gor

Capturing Production Traffic

The simplest capture command records all HTTP traffic on port 80 and writes it to a file:

1
2

# Capture traffic on port 80, save to .gor files
sudo gor --input-raw :80 --output-file requests.gor

This creates timestamped request files that you can replay later. For production systems, you’ll want to filter and limit what you capture:

1
2
3
4
5
6
7

# Capture only specific endpoints, limit file size, rotate every hour
sudo gor --input-raw :80 \
  --input-raw-track-response \
  --http-allow-url /api/.* \
  --http-allow-method POST \
  --output-file requests.gor \
  --output-file-max-size-limit 500m

Key flags explained:

• --input-raw-track-response: Captures response bodies alongside requests, useful for validating that the replay target produces the same results
• --http-allow-url: Whitelist URL patterns — only capture API calls, not static assets
• --http-allow-method: Filter by HTTP method — capture only writes if you’re testing a database migration
• --output-file-max-size-limit: Cap file size to avoid filling disk on busy systems

Replaying Traffic Against Staging

Once you have captured traffic, replaying it is straightforward:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# Replay at recorded speed
gor --input-file requests.gor --output-http "http://staging.example.com:8080"

# Replay at 2x speed (compressed timeline)
gor --input-file requests.gor \
  --output-http "http://staging.example.com:8080" \
  --input-file-rewrite-timestamp \
  --stats --output-http-stats=/stats

# Replay at 10x speed for soak testing
gor --input-file requests_20260410.gor \
  --input-file-rewrite-timestamp \
  --input-file-loop \
  --output-http "http://staging.example.com:8080" \
  --output-http-workers=20

The --input-file-loop flag makes GoReplay cycle through the capture file continuously, which is useful for soak tests. --output-http-workers controls how many concurrent connections GoReplay uses when replaying — set this high enough to saturate your staging server.

Running GoReplay with docker

For containerized deployments, GoReplay runs as a sidecar:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# docker-compose.yml for GoReplay traffic capture
version: "3.8"
services:
  app:
    image: myapp:latest
    ports:
      - "8080:8080"

  goreplay:
    image: buger/goreplay:latest
    network_mode: host
    volumes:
      - ./captures:/captures
    command: >
      --input-raw :8080
      --output-file /captures/traffic.gor
      --http-allow-url /api/.*
      --output-file-max-size-limit 200m
    restart: unless-stopped

Note that GoReplay requires network_mode: host or the NET_ADMIN capability because it captures traffic at the raw socket level:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Alternative: capability-based (better for non-host network mode)
  goreplay:
    image: buger/goreplay:latest
    cap_add:
      - NET_ADMIN
    network_mode: host
    volumes:
      - ./captures:/captures
    command: >
      --input-raw :8080
      --output-file /captures/traffic.gor

Advanced GoReplay Patterns

Middleware for request modification: You can modify requests on the fly using a middleware HTTP server:

1
2
3

gor --input-raw :80 \
  --middleware "http://localhost:9000/middleware" \
  --output-http "http://staging.example.com:8080"

Your middleware receives each request as JSON, can modify headers, paths, or bodies, and returns the modified request. This is useful for stripping authentication tokens, changing host headers, or injecting test data.

Comparing production and staging responses: GoReplay can split traffic to both production and staging, then compare responses:

1
2
3
4
5

gor --input-raw :80 \
  --output-http "http://production.example.com:8080" \
  --output-http "http://staging.example.com:8080" \
  --output-http-track-response \
  --split-output

Siege: Simple Concurrent Load Testing

Siege is a veteran HTTP load testing tool that excels at one thing: simulating a specific number of concurrent users hitting a URL for a defined duration. Its simplicity makes it the fastest way to get a baseline performance number.

Installation

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# Debian/Ubuntu
sudo apt install siege -y

# RHEL/CentOS/Fedora
sudo dnf install siege -y

# macOS
brew install siege

# From source
wget https://download.joedog.org/siege/siege-latest.tar.gz
tar -xzf siege-latest.tar.gz
cd siege-*/
./configure
make
sudo make install

Siege uses a URL file to define what it tests. Create a file called urls.txt:

1
2
3
4
5

https://example.com/api/health
https://example.com/api/products
https://example.com/api/products/1
https://example.com/api/products?category=electronics&sort=price
https://example.com/api/search?q=laptop

Running Tests

The basic syntax is siege [options] url_or_file. Here are the most useful patterns:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 50 concurrent users for 30 seconds
siege -c 50 -t 30S -f urls.txt

# 100 concurrent users, each hitting URLs 10 times
siege -c 100 -r 10 -f urls.txt

# 200 concurrent users for 5 minutes, with delay between requests
siege -c 200 -t 5M -d 2 -f urls.txt

# Quiet mode — output only the final stats (useful for CI pipelines)
siege -c 50 -t 30S -q -f urls.txt

Key flags:

Understanding Siege Output

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

Transactions:                   4523 hits
Availability:                  99.82 %
Elapsed time:                  29.67 secs
Data transferred:              12.45 MB
Response time:                  0.32 secs
Transaction rate:             152.44 trans/sec
Throughput:                     0.42 MB/sec
Concurrency:                   48.97
Successful transactions:       4523
Failed transactions:              8
Longest transaction:            2.14
Shortest transaction:           0.01

The most important metrics:

• Transaction rate: Sustained requests per second — your primary throughput number
• Response time: Average time per request — latency indicator
• Availability: Percentage of successful requests — anything below 99.5% indicates a problem
• Concurrency: Average number of simultaneous connections maintained

Sieging with POST Data

For testing write endpoints, create a POST body file and reference it:

1
2
3
4
5

echo '{"title":"Test Product","price":29.99,"category":"test"}' > /tmp/post.json

siege -c 50 -t 1M \
  --content-type "application/json" \
  "https://example.com/api/products POST < /tmp/post.json"

wrk: High-Performance HTTP Benchmarking

wrk is a modern HTTP benchmarking tool written in C with LuaJIT scripting support. It can generate significant load on a single multi-core CPU — routinely achieving 100,000+ requests per second on modest hardware. Its Lua scripting engine lets you customize requests, parse responses, and generate dynamic data.

Installation

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Debian/Ubuntu
sudo apt install wrk -y

# macOS
brew install wrk

# From source (recommended for latest features)
git clone https://github.com/wg/wrk.git
cd wrk
make
sudo cp wrk /usr/local/bin/

Basic Usage

1
2
3
4
5

# 12 threads, 400 connections, 30-second test
wrk -t12 -c400 -d30s https://example.com/api/health

# Single-threaded, 100 connections, 10 seconds
wrk -t1 -c100 -d10s https://example.com/api/products

Understanding wrk Output

1
2
3
4
5
6
7
8

Running 30s test @ https://example.com/api/health
  12 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    12.34ms    8.21ms 145.67ms   89.23%
    Req/Sec     2.73k   412.45     4.12k    78.45%
  978234 requests in 30.05s, 234.56MB read
Requests/sec:  32553.78
Transfer/sec:      7.80MB

The critical insight from wrk that other tools don’t show clearly: latency distribution. The Avg, Stdev, Max, and +/- Stdev columns tell you not just the average latency but how consistent it is. A low average with high standard deviation means your service is usually fast but occasionally stalls — a pattern that kills user experience.

Lua Scripting in wrk

wrk’s real power comes from Lua scripts. Create a file called api_test.lua:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

-- Load testing script for REST API with multiple endpoints
local counter = 1
local paths = {
  "/api/products",
  "/api/products?page=1&limit=20",
  "/api/products?page=2&limit=20",
  "/api/categories",
  "/api/search?q=phone",
  "/api/search?q=laptop",
}

request = function()
  local path = paths[counter]
  counter = counter + 1
  if counter > #paths then
    counter = 1
  end
  return wrk.format("GET", path)
end

response = function(status, headers, body)
  if status ~= 200 then
    print("Unexpected status: " .. status .. " for " .. paths[counter - 1])
  end
end

Run it with:

1

wrk -t4 -c200 -d60s -s api_test.lua https://example.com

For POST requests with dynamic JSON bodies:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

-- wrk_post.lua
local json = require "json"

request = function()
  local body = string.format(
    '{"name":"User %d","email":"user%d@test.com","role":"viewer"}',
    math.random(1, 10000),
    math.random(1, 10000)
  )
  return wrk.format("POST", "/api/users", nil, body)
end

Run with:

1

wrk -t2 -c50 -d30s -s wrk_post.lua https://example.com

Vegeta: Constant-Rate Load Generation

Vegeta, written in Go, takes a fundamentally different approach: instead of generating as many requests as possible, it maintains a constant request rate. You tell it “100 requests per second” and it will sustain exactly that rate, regardless of how fast or slow the server responds. This makes Vegeta ideal for finding the exact breaking point of a system.

Installation

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# Go (recommended — always gets the latest version)
go install github.com/tsenart/vegeta/v12@latest

# Debian/Ubuntu (may be older version)
sudo apt install vegeta -y

# macOS
brew install vegeta

# Pre-built binary
VEGETA_VERSION=12.12.4
wget "https://github.com/tsenart/vegeta/releases/download/v${VEGETA_VERSION}/vegeta_${VEGETA_VERSION}_linux_amd64.tar.gz"
tar -xzf "vegeta_${VEGETA_VERSION}_linux_amd64.tar.gz"
sudo mv vegeta /usr/local/bin/

Basic Usage

Vegeta uses stdin/stdout for its attack pipeline. You pipe targets into the attack command, then pipe results into report commands:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Attack at 100 requests/second for 30 seconds
echo "GET https://example.com/api/health" | \
  vegeta attack -rate=100 -duration=30s -output=results.bin

# Generate text report
vegeta report results.bin

# Generate JSON report (for CI integration)
vegeta report -type=json results.bin > metrics.json

# Generate HTML plot
vegeta plot results.bin > plot.html

Multi-Endpoint Attacks

Create a targets.txt file:

1
2
3
4
5
6
7

GET https://example.com/api/products
GET https://example.com/api/products/1
POST https://example.com/api/products
Content-Type: application/json
{"name":"Test","price":19.99}
GET https://example.com/api/categories
GET https://example.com/api/search?q=test

The file format supports blank-line-separated request groups. Each group is a complete HTTP request with optional headers and body:

1

vegeta attack -rate=50/1s -duration=2m -targets=targets.txt -output=results.bin

The rate format supports flexible syntax: 100/1s (100 per second), 1000/1m (1000 per minute), or just 100 (defaults to per second).

Ramp-Up and Spike Testing

Vegeta can vary the rate over time using a rate file:

1
2
3
4
5
6
7

# Start at 10 rps, ramp to 500 rps over 60 seconds, hold for 30 seconds
echo "10
100
250
500
500
500" | vegeta attack -rate=- -duration=90s -targets=targets.txt -output=results.bin

Or use the built-in ramp pattern:

1
2

# Ramp from 10 to 1000 rps over 5 minutes
vegeta attack -rate='10+1000/300s' -duration=5m -targets=targets.txt -output=results.bin

Vegeta Report Output

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

Requests      [total, rate, throughput]  15000, 100.00, 95.23
Duration      [total, attack, wait]      2m30s, 2m30s, 452.3ms
Latencies     [min, mean, 50, 90, 95, 99, max]  12ms, 234ms, 189ms, 412ms, 567ms, 1.2s, 3.4s
Bytes In      [total, mean]              45678901, 3045.26
Bytes Out     [total, mean]              1234567, 82.30
Success       [ratio]                    98.45%
Status Codes  [code:count]               200:14768 500:189 503:43
Error Set:
500 Internal Server Error (189 responses)
503 Service Unavailable (43 responses)

The percentile breakdown (50, 90, 95, 99) is Vegeta’s most valuable output. It tells you exactly how many users experience slow responses. If your p99 latency exceeds your SLA but your average is fine, you have a tail latency problem — and Vegeta is the tool that reveals it.

k6: Developer-Friendly Load Testing

k6 stands out for its JavaScript API, which makes writing load tests feel like writing unit tests. You define scenarios, set thresholds, and write assertions in familiar JavaScript syntax. It’s the best choice when you want load tests in your CI/CD pipeline.

Installation

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Debian/Ubuntu
sudo gpg -k
sudo gpg --no-default-keyring --keyring /usr/share/keyrings/k6-archive-keyring.gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D69
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt update
sudo apt install k6

# macOS
brew install k6

# Docker
docker pull grafana/k6

Writing Your First Test

Create a file called load_test.js:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

import http from 'k6/http';
import { check, sleep } from 'k6';
import { Rate } from 'k6/metrics';

// Custom metrics
const errorRate = new Rate('http_errors');

// Thresholds — test passes only if these conditions are met
export const options = {
  thresholds: {
    http_req_duration: ['p(95)<500'], // 95% of requests must complete within 500ms
    http_req_failed: ['rate<0.01'],   // Less than 1% errors allowed
    http_errors: ['rate<0.05'],       // Custom error rate under 5%
  },
  stages: [
    { duration: '30s', target: 50 },   // Ramp up to 50 users over 30 seconds
    { duration: '1m', target: 50 },    // Stay at 50 users for 1 minute
    { duration: '30s', target: 200 },  // Spike to 200 users
    { duration: '1m', target: 200 },   // Stay at 200 users
    { duration: '30s', target: 0 },    // Ramp down to 0
  ],
};

export default function () {
  // Test the products API
  const productsRes = http.get('https://example.com/api/products');
  check(productsRes, {
    'products status is 200': (r) => r.status === 200,
    'products response has items': (r) => JSON.parse(r.body).length > 0,
    'products loads in <200ms': (r) => r.timings.duration < 200,
  });

  errorRate.add(productsRes.status !== 200);
  sleep(1);

  // Test a single product lookup
  const idRes = http.get('https://example.com/api/products/1');
  check(idRes, {
    'single product status is 200': (r) => r.status === 200,
  });
  sleep(1);

  // Test search
  const searchRes = http.get('https://example.com/api/search?q=laptop');
  check(searchRes, {
    'search returns results': (r) => r.status === 200,
  });
  sleep(1);
}

Run it:

1

k6 run load_test.js

k6 Output and Thresholds

1
2
3
4

     ✗ http_errors......................: 2.34%   threshold crossed: true
       ✗ http_req_duration..............: avg=234.5ms min=12ms med=189ms p(90)=412ms p(95)=567ms max=3400ms
         ✓ threshold crossed: true  (p(95)=567ms > 500ms threshold)
       ✓ http_req_failed................: 0.87%   threshold crossed: true

The threshold system is k6’s killer feature for CI/CD integration. If any threshold fails, k6 exits with a non-zero code — your pipeline automatically catches performance regressions.

Running k6 with Docker and Docker Compose

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# docker-compose.yml for k6 load testing
version: "3.8"
services:
  k6:
    image: grafana/k6:latest
    volumes:
      - ./tests:/tests
    command: run /tests/load_test.js --out json=/tests/results.json
    environment:
      - K6_NO_CONNECTION_REUSE=false
    networks:
      - app-network

  # Your application under test
  app:
    image: myapp:latest
    ports:
      - "8080:8080"
    networks:
      - app-network

networks:
  app-network:
    driver: bridge

Running the test:

1
2

docker compose up -d app
docker compose run k6

k6 with Environment Variables for Flexibility

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

import http from 'k6/http';

const BASE_URL = __ENV.BASE_URL || 'http://localhost:8080';

export const options = {
  vus: parseInt(__ENV.VUS) || 50,
  duration: __ENV.DURATION || '1m',
};

export default function () {
  http.get(`${BASE_URL}/api/health`);
  http.get(`${BASE_URL}/api/products`);
}

1
2

# Override settings from the command line
BASE_URL=https://staging.example.com VUS=200 DURATION=5m k6 run load_test.js

Tool Comparison: Which One Should You Use?

Decision Guide

• You want to test with real user patterns: Use GoReplay. Nothing matches the authenticity of actual production traffic, including the messy edge cases and unexpected request combinations.
• You need a quick “how fast is this” number: Use wrk. It gives you the highest throughput measurement with minimal setup time.
• You want to find the exact breaking point: Use Vegeta. Its constant-rate model lets you increase load incrementally until the system fails, giving you a precise capacity number.
• You want load tests in your CI/CD pipeline: Use k6. Its threshold system, JavaScript API, and native JSON output integrate cleanly into automated workflows.
• You need to simulate N concurrent users hitting a known URL set: Use Siege. It’s the simplest tool for this specific job.

Real-World Testing Strategy

A production-ready load testing strategy combines multiple tools at different stages:

1. Development: Run wrk benchmarks against local changes to catch obvious performance regressions before merging.
2. Pre-release: Run GoReplay traffic replay against staging to validate that new code handles real production traffic patterns correctly.
3. Capacity planning: Use Vegeta to determine the maximum sustainable request rate for each endpoint, establishing baseline capacity numbers.
4. CI/CD: Run k6 tests with defined thresholds on every pull request to prevent performance regressions from reaching production.
5. Soak testing: Run GoReplay or Siege at moderate concurrency for 24-48 hours to catch memory leaks, connection pool exhaustion, and database connection issues that only appear under sustained load.

Conclusion

The best load testing tool is the one that matches your specific question. GoReplay answers “does this code handle real traffic correctly?” Siege answers “how many concurrent users can this handle?” wrk answers “what’s the maximum throughput?” Vegeta answers “at what request rate does this break?” And k6 answers “does this change meet our performance requirements?”

All five tools are open source, free to run at any scale, and integrate with standard monitoring stacks. Running them on your own infrastructure keeps your API details private, eliminates cloud testing costs, and gives you the freedom to run tests as often and as aggressively as your staging environment can handle.

Start with wrk for quick benchmarks, add GoReplay for realistic traffic validation, and build k6 tests into your CI pipeline. That three-tool combination covers 95% of what most teams need from a load testing infrastructure.

Frequently Asked Questions (FAQ)

Which one should I choose in 2026?

The best choice depends on your specific requirements:

• For beginners: Start with the simplest option that covers your core use case
• For production: Choose the solution with the most active community and documentation
• For teams: Look for collaboration features and user management
• For privacy: Prefer fully open-source, self-hosted options with no telemetry

Refer to the comparison table above for detailed feature breakdowns.

Can I migrate between these tools?

Most tools support data import/export. Always:

1. Backup your current data
2. Test the migration on a staging environment
3. Check official migration guides in the documentation

Are there free versions available?

All tools in this guide offer free, open-source editions. Some also provide paid plans with additional features, priority support, or managed hosting.

How do I get started?

1. Review the comparison table to identify your requirements
2. Visit the official documentation (links provided above)
3. Start with a Docker Compose setup for easy testing
4. Join the community forums for troubleshooting