If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/codesenberg/bombardier shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Single-maintainer risk — review before adopting

• Last commit 5w ago
• 7 active contributors
• MIT licensed
• Tests present
• ⚠ Single-maintainer risk — top contributor 91% of recent commits
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live codesenberg/bombardier repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/codesenberg/bombardier.

What it runs against: a local clone of codesenberg/bombardier — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in codesenberg/bombardier | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 67 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of codesenberg/bombardier. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/codesenberg/bombardier.git
#   cd bombardier
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of codesenberg/bombardier and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "codesenberg/bombardier(\\.git)?\\b" \\
  && ok "origin remote is codesenberg/bombardier" \\
  || miss "origin remote is not codesenberg/bombardier (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 67 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~37d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/codesenberg/bombardier"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Bombardier is a fast HTTP(S) benchmarking tool written in Go that uses valyala/fasthttp for high-performance load testing. It can generate millions of requests against a target server and reports detailed statistics including requests/sec, latency percentiles, HTTP status codes, and errors. It supports both fasthttp (default, ultra-fast) and net/http clients (for HTTP/2+ compliance), making it suitable for benchmarking both legacy and modern HTTP services. Single-package monolith with clear separation: args_parser.go and flags.go handle CLI argument parsing, bombardier.go contains core benchmarking logic, clients.go abstracts HTTP client selection (fasthttp vs net/http), and format.go handles output rendering. Helper utilities live in cmd/utils/simplebenchserver (for testing). Tests follow Go convention of *_test.go files alongside implementation.

DevOps engineers, performance testers, and backend developers who need to benchmark HTTP services under load. They use bombardier to validate server performance before production deployments, stress-test infrastructure, and compare performance across different configurations or implementations.

Actively maintained and production-ready. The codebase shows Go 1.22+ support, comprehensive test coverage (bombardier_test.go, clients_test.go, etc.), CI/CD via Semaphore, and proper versioning (v1.1+). Recent toolchain updates to Go 1.24.0 indicate ongoing maintenance, though commit recency and issue backlog are not visible from the provided data.

Low risk for a single-purpose CLI tool. Dependencies are minimal and well-vetted (valyala/fasthttp, alecthomas/kingpin, cheggaaa/pb). The main risk is single-maintainer concentration (codesenberg org). No obvious breaking changes or deprecated dependencies visible, though fasthttp itself is known to diverge from RFC compliance (mentioned in README for Host header handling).

No recent commit data provided in repo metadata, but the toolchain was updated to Go 1.24.0 and dependencies are current (e.g., valyala/fasthttp v1.59.0, golang.org/x/net v0.35.0). The project appears to be in maintenance mode rather than active feature development.

git clone https://github.com/codesenberg/bombardier && cd bombardier && go build -o bombardier . && ./bombardier -h

Daily commands: bombardier -c 125 -n 10000000 http://localhost:8080 (10M requests with 125 concurrent connections) or bombardier -c 200 -d 10s http://example.com (10 second duration test with 200 connections). Use --http1 or --http2 flags to switch from fasthttp to net/http.

• bombardier.go: Core benchmark engine: Bombardier struct, request execution loop, statistics collection
• clients.go: HTTP client abstraction: switches between fasthttp and net/http; manages client initialization and request execution
• args_parser.go: CLI argument parsing and validation: translates raw flags into Config struct
• flags.go: kingpin flag definitions: declares all command-line options (concurrency, duration, rate limiting, etc.)
• limiter.go: Rate limiting implementation using token bucket pattern (juju/ratelimit wrapper)
• format.go: Output formatting: renders statistics tables, latency distributions, HTTP code breakdowns, and error summaries
• config.go: Configuration struct definition and validation: centralizes all benchmark parameters after CLI parsing

Start with args_parser.go and flags.go to add new CLI flags. Core request logic is in bombardier.go (Bombardier struct). Client selection logic: clients.go and client_cert.go. Output formatting: format.go. Rate limiting: limiter.go. New HTTP client features should go in clients.go alongside fasthttp setup. Tests live alongside implementations as *_test.go files.

fasthttp has known limitations with Host header handling (mentioned in README—use --http1/--http2 flags as workaround). Client certificates require both .cert and .key files (testclient.cert/testclient.key pattern). The simplebenchserver test utility (cmd/utils/simplebenchserver/main.go) is required for internal testing but not automatically built. Rate limiting via -r flag uses juju/ratelimit which has per-connection semantics, not global rate limiting. No visible environment variable configuration—all settings are CLI flags.

• Token Bucket Rate Limiting — Bombardier uses juju/ratelimit to implement request rate capping via -r flag; understanding token bucket mechanics is critical for controlling load and avoiding server overload
• Connection Pooling & Concurrent Request Batching — Core bombardier pattern: -c flag creates a pool of persistent connections reused across requests; mastering this prevents connection exhaustion and enables realistic load simulation
• HTTP/2 Multiplexing — bombardier --http2 flag requires understanding HTTP/2 framing and how multiple streams share a single TCP connection, which changes latency and throughput profiles vs HTTP/1.1
• Latency Percentile Analysis (Tail Latency) — format.go renders p50/p75/p90/p99 latency; understanding percentile distributions (not just averages) is essential for identifying performance tail risks in production
• Client Certificate Pinning & TLS Handshakes — client_cert.go handles mTLS setup; each concurrent connection performs a TLS handshake, so -c value directly impacts TLS CPU overhead and connection setup latency
• Goroutine-based Concurrency Model — bombardier spawns one goroutine per concurrent connection (-c flag); understanding Go's scheduler and goroutine overhead is critical for tuning -c to match target server capacity
• Barrier Synchronization — completion_barriers.go coordinates test start/stop across all goroutines; barriers ensure clean test boundaries and prevent race conditions in statistics collection

• codesenberg/concurrent — Direct dependency for concurrent execution primitives used in bombardier's connection pooling
• valyala/fasthttp — Core HTTP client library that powers bombardier's performance; understanding its API is essential for modifying client behavior
• rakyll/hey — Alternative HTTP benchmarking tool in Go; provides different approach to load testing and comparison point for feature/performance parity
• wg/wrk — Original inspiration for HTTP benchmarking tools (C-based, vastly popular); bombardier is the Go equivalent with similar reporting patterns
• apache/ab — Legacy HTTP benchmarking standard; bombardier provides modern replacement with better performance and feature set

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive tests for template rendering and variable substitution

The repo has a template system (templates.go, template/doc.go) but template_test.go is missing. This is critical for a benchmarking tool since request templates are likely used to generate dynamic payloads. Testing template parsing, variable injection, and edge cases would prevent regressions in core functionality.

• [ ] Create template_test.go with unit tests for template parsing and rendering
• [ ] Add test cases for variable substitution in request bodies and headers
• [ ] Test edge cases: empty templates, missing variables, special characters in templates
• [ ] Test integration between args_parser.go (which likely parses template flags) and template rendering
• [ ] Add benchmarks for template rendering performance in bombardier_performance_test.go

Add integration tests for client certificate handling with actual TLS connections

client_cert.go and client_cert_test.go exist, but the test coverage likely only covers cert parsing. The repo has test certificates (testclient.cert, testclient.key, testserver.cert, testserver.key) that should be used for end-to-end TLS tests. This is critical for users relying on mTLS benchmarking.

• [ ] Enhance client_cert_test.go to test cert loading from the testclient.* files
• [ ] Add integration tests in bombardier_test.go that benchmark an actual TLS server using the test certificates
• [ ] Test cert validation failures and error handling with invalid certificates
• [ ] Test cert + proxy combinations (see dialer.go) with TLS
• [ ] Document in docs/CONTRIBUTING.md how to run these TLS integration tests locally

Add GitHub Actions workflow for cross-platform binary release builds

The repo uses Semaphore CI (.semaphore/semaphore.yml) but lacks GitHub Actions for releasing precompiled binaries across platforms (Linux, macOS, Windows). The README mentions binary installation but the release process is opaque. This improves user experience for the tool's primary use case.

• [ ] Create .github/workflows/release.yml that builds binaries on Go 1.22+ for linux/{amd64,arm64}, darwin/{amd64,arm64}, and windows/amd64
• [ ] Use build.py logic to guide the workflow steps (or refactor build.py to be called by the workflow)
• [ ] Upload artifacts as GitHub Releases automatically on git tags matching v*
• [ ] Test the workflow builds successfully for at least one platform
• [ ] Update README.md installation section to link to GitHub Releases

• Add unit tests for proxy_reader.go (file exists but no corresponding *_test.go file visible in structure)
• Extend error_map.go to capture and categorize additional fasthttp/net.Dialer error types beyond timeout, ensuring granular error reporting in benchmark output
• Add latency percentile options (currently fixed at 50/75/90/99) via CLI flags like --latency-percentiles=25,50,75,95 to allow custom distributions

The bombardier codebase is a benchmarking utility with moderate security posture. Primary concerns include: (1) use of unmaintained UUID library requiring migration, (2) deprecated CLI argument parsing library, (3) test credentials stored in version control, and (4) potential input validation risks in file operations. The codebase does not appear to have SQL injection or XSS risks due to its nature as a benchmarking tool. Recommend addressing the outdated dependency issues and reviewing file operation inputs for path traversal vulnerabilities. No critical infrastructure misconfigurations detected in the provided context.

• High · Outdated Dependency: github.com/satori/go.uuid — go.mod - github.com/satori/go.uuid v1.2.0. The uuid library (github.com/satori/go.uuid v1.2.0) is outdated and no longer maintained. The original author has abandoned the project. This dependency should be replaced with google.golang.org/uuid or github.com/google/uuid which are actively maintained and receive security updates. Fix: Migrate to google.golang.org/uuid or github.com/google/uuid. These are actively maintained alternatives that receive security patches.
• Medium · Outdated Dependency: github.com/alecthomas/kingpin — go.mod - github.com/alecthomas/kingpin v2.2.6+incompatible. The kingpin library (v2.2.6+incompatible) is marked as incompatible and is not actively maintained. Modern alternatives like github.com/urfave/cli or github.com/spf13/cobra are preferred for CLI argument parsing. Fix: Consider migrating to actively maintained CLI frameworks like urfave/cli or spf13/cobra for better security and feature support.
• Medium · Test Credentials in Repository — testclient.key, testserver.key. SSL/TLS test certificates and private keys are committed to the repository (testclient.cert, testclient.key, testserver.cert, testserver.key). While these are test fixtures, storing any private keys in version control is a security best practice violation and could serve as a template for insecure practices. Fix: Move test certificates to a separate test fixtures directory with clear documentation that these are test-only files. Consider using certificate generation in test setup instead of storing them.
• Medium · Potential Path Traversal Risk in File Operations — headers.go, templates.go, config.go, args_parser.go. The codebase appears to handle headers, templates, and file operations. Without seeing the actual implementation, there's a risk of path traversal vulnerabilities if user-supplied paths (from CLI args or configuration) are used directly in file operations without proper validation. Fix: Implement input validation for any file paths derived from user input. Use filepath.Clean() and verify that resolved paths remain within expected directories.
• Low · Outdated Go Toolchain Version Specification — go.mod. The go.mod specifies 'go 1.22' but uses toolchain 'go1.24.0'. While this is not directly a security issue, it may indicate misaligned development environments and could lead to inconsistent builds. Fix: Align the go version and toolchain specifications. If supporting 1.22, remove the toolchain line. If requiring 1.24, update the go version field accordingly.
• Low · Missing Security Headers Configuration — clients.go, bombardier.go. As a benchmarking tool that may handle HTTP responses, there's no visible evidence of security header validation or security-conscious defaults when processing responses from target servers. Fix: Document and implement best practices for handling various HTTP security headers when analyzing benchmarked services. Add validation for security-critical headers if needed.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.