CI/CD load testing

LoadStrike docs already describe the runner key, report formats, thresholds, CLI arguments, and JSON config surfaces that usually matter first in CI workflows. Teams can use those building blocks to move a working scenario into automation without changing the runtime model.

That makes the CI path straightforward: keep the scenario code the same, choose the CLI or JSON configuration surface your pipeline needs, then promote the report artifacts and thresholds your team already enforces in automation.

Who this is for

Teams moving an existing LoadStrike scenario into CI or another automation pipeline and wanting the shortest path through the docs.

What the docs cover today

Automation teams usually need four things first: a runner key, a launch surface, pass-fail thresholds, and report artifacts that can be stored or inspected after the run. Those are already documented across the LoadStrike docs, so the job here is to connect them into one CI-friendly path.

How LoadStrike fits

LoadStrike keeps the runtime model stable between local execution and automation. Teams can keep one scenario definition, move configuration into CLI or JSON when needed, and let the pipeline enforce the same report formats and thresholds they already use for engineering reviews.

CLI arguments

See launch-time overrides and report format controls.

JSON config

Move runtime settings outside code where needed.

Reports overview

Review the report artifacts you would carry into automation.

Where should I start for automation today?

Start with the quick start, CLI arguments, JSON config, and reports overview pages. Those docs already describe the runner setup, overrides, thresholds, and artifacts most teams need first in CI.

Does the site publish vendor-specific pipeline templates?

No. The site documents the LoadStrike runtime building blocks that fit into automation, such as runner setup, config files, thresholds, and report artifacts, rather than vendor-specific CI recipes.

CLI Arguments

CLI arguments let you change a run at launch time without editing code. They are useful for CI, containers, and reusable test hosts.

JSON Config

Use JSON config when you want runtime settings outside the source code. This is useful for shared environments, CI, and repeatable test hosts.

Report Overview

This page explains how to read a LoadStrike report. Use it when you want to know what each section means and where to look first.

LoadStrike vs k6

Compare LoadStrike and k6 across code ergonomics, protocol scope, downstream correlation, reporting depth, browser workflows, and distributed self-hosted execution.

LoadStrike and OTEL Collector

See how the LoadStrike OTEL Collector sink fits into OpenTelemetry-oriented reporting workflows.

Examples

See the example hub.

Reports overview

Review the run artifacts most teams carry into automation.

Pricing

Check self-hosted plan fit before a broader rollout.