LoadStrike SDK for TypeScript and JavaScript

LoadStrike is a developer-first load testing SDK for Node.js applications, services, and test suites. Use it when you want to model real transactions in code, execute them in-process, and capture structured results without moving into a separate runner or DSL.

What This SDK Is For

• Author scenario-based load tests in TypeScript or JavaScript.
• Generate safe starter scenarios from captured HAR, OpenTelemetry trace JSON, browser recordings, or message pairs with Trace-to-test Autopilot.
• Exercise HTTP and event-driven workflows across multiple steps.
• Apply load simulations, thresholds, and custom metrics to real transactions.
• Split a single load profile across weighted scenario mixes.
• Generate local reports and, on Enterprise, publish observability data to supported sinks.

Built-in transport coverage includes HTTP, Kafka, RabbitMQ, NATS, Redis Streams, Azure Event Hubs, Push Diffusion, and delegate-based custom streams. Local report output supports HTML, Markdown, TXT, and CSV, and Enterprise can publish to InfluxDB, TimescaleDB, Grafana Loki, Datadog, Splunk HEC, OpenTelemetry Collector, and the expanded built-in sink family.

Requirements

• Node.js 20 or later

Install

npm install @loadstrike/loadstrike-sdk

Quick Start

import {
  LoadStrikeResponse,
  LoadStrikeRunner,
  LoadStrikeScenario,
  LoadStrikeSimulation,
  LoadStrikeStep,
} from "@loadstrike/loadstrike-sdk";

const scenario = LoadStrikeScenario
  .create("orders", async (context) => {
    return LoadStrikeStep.run(
      "publish-order",
      context,
      async () => LoadStrikeResponse.ok("200")
    );
  })
  .withLoadSimulations(
    LoadStrikeSimulation.inject(10, 1, 20)
  );

const result = await LoadStrikeRunner
  .registerScenarios(scenario)
  .withRunnerKey("rkl_your_runner_key")
  .run();

run() returns the detailed run result, including generated report files, scenario statistics, metrics, and sink status.

Traffic Mixes

Use LoadStrikeTrafficMix on Pro and Enterprise plans when one total load profile should be distributed across multiple scenario lanes. For example, a 1000 requests-per-second profile with scenario weights of 60, 30, and 10 sends roughly 600 requests per second to the first scenario, 300 to the second, and 100 to the third.

Each lane is still a normal scenario with its own named steps, thresholds, reports, and portal results. Register the mix with LoadStrikeRunner.registerTrafficMix(...) or add it to a runner with .addTrafficMix(...).

Trace-To-Test Autopilot

Use await LoadStrikeAutopilot.generate(...) to infer a starter plan from a captured artifact. Set Options.RunnerKey so generation can validate the Trace-To-Test Autopilot entitlement. Check result.Readiness and result.ReadinessFailures first; call result.buildScenario() only when it is LoadStrikeAutopilotReadiness.Ready, then execute the scenario through the normal runner with a valid RunnerKey.

Use SecretBindings to map redaction locations such as header:Authorization or body:$.client_secret to environment variables, TrackingSelector when the selector cannot be inferred, and EndpointBindings, AllowedReplayHosts, or BaseUrlRewrite when a replay target must be bound. Secret values are resolved when the generated scenario runs; they are not written into the generated plan. Any gate satisfied by user setup is omitted from ReadinessFailures.

Runner Keys

Runnable workloads require a RunnerKey. Supply it with .withRunnerKey(...) or through your application configuration before calling run().

Documentation

• Product documentation: https://loadstrike.com/documentation