Executors

When you upload a script instead of using a scriptless builder, MaxoPerf runs it through one of many underlying load-testing and browser-automation tools. This page is the complete catalog of supported executors — every engine MaxoPerf can drive a test with.

Executors, not a manual picker

MaxoPerf detects the executor from the file you upload — a .jmx is JMeter, a k6 .js/.ts is k6, a Taurus YAML’s executor: field names its own executor, and so on. You never pick the executor from a dropdown; upload the right file and MaxoPerf infers it, then validates the scenario against that executor’s rules.

📷 Screenshot to capture — tests-builders/engine-detection

What to show:MaxoPerf New test authoring page showing the detected engine badge above the scenario/files drop zone after a scenario file is uploaded

Scenario and files: MaxoPerf shows the detected executor as a badge once it recognizes the uploaded file — there is no manual executor picker.

Executor source of truth

The authoritative executor list is defined in packages/test-config/src/detect-taurus-executors.ts (SUPPORTED_TAURUS_EXECUTORS) and is the single source of truth for the database engine-kind enum, the Platform API DTOs, and this page. When MaxoPerf validates your upload, it checks the executor value against this same list.

The full executor catalog

Executor	Underlying tool	Entrypoint file kind	Support level	Notes
taurus	Taurus native HTTP runner	.yaml / .yml (no executor: key, or executor: taurus)	First-class	The default when no executor: is set. Handles HTTP requests directly — no separate engine required. Good for simple HTTP load with a single declarative YAML.
jmeter	Apache JMeter	.jmx (referenced by scenarios.*.script) or direct .jmx upload	First-class	The most widely used executor. Upload your .jmx directly or reference it from a YAML. MaxoPerf validates JMX well-formedness and thread-group presence.
k6	Grafana k6	.js / .ts k6 script	First-class	Full k6 support via direct upload or a YAML reference. Your k6 script is the entrypoint.
selenium	Selenium WebDriver	.py script or Selenium IDE .side file	First-class	Real-browser tests — see Browser tests. Gets full video, step timeline, HAR, and console capture on Chrome/Chromium.
playwright	Playwright	.js / .ts Playwright script	First-class	Real-browser tests via Playwright. Distinguished from other JavaScript executors by content, not just extension. Same capture pipeline as Selenium tests — see Browser tests.
gatling	Gatling (Scala)	.scala simulation file	Supported	Point scenarios.*.script at a Gatling Scala simulation. Runs through the Gatling execution path; configure Gatling-specific settings in the YAML rather than a dedicated console UI.
locust	Locust (Python)	locustfile.py or any .py with from locust import	Supported	Manages Locust’s master/worker topology and metrics collection. Upload locustfile.py as a test asset and reference it from the YAML.
apiritif	Apiritif (Python HTTP client)	.py Apiritif script	Supported	Python-native HTTP client framework with a recorder. Good for teams that prefer Python over YAML or JavaScript. Pure HTTP — not a browser executor.
wdio	WebdriverIO	.js / .ts WebdriverIO spec	Supported	Browser automation via the WebdriverIO JavaScript API — similar coverage to Selenium, without the dedicated capture pipeline.
robot	Robot Framework	.robot keyword-driven test	Supported	Runs Robot Framework keyword-driven tests as load. Good for teams already invested in Robot Framework.
siege	Siege	URL-list file or inline URLs	Supported	Simple multi-threaded HTTP benchmarking. Effective for quick URL-list hammering; limited scenario expressiveness compared to JMeter or k6.
ab	Apache Benchmark (ab)	No file — URLs specified inline in the YAML	Supported	The classic HTTP microbenchmark. Good for single-endpoint baseline measurements; not suited to multi-step flows.
vegeta	Vegeta (Go)	.txt URL-list or inline targets	Supported	High-performance HTTP load generator with constant-rate (rate:) attacks — better rate control than ab for sustained throughput tests.
tsung	Tsung (Erlang)	Tsung XML config	Supported	Distributed load testing for HTTP, WebSocket, XMPP, and more. Complex setup; use when you need Erlang-based distributed load or XMPP protocol support.
molotov	Molotov (Python asyncio)	.py Molotov scenario	Supported	Async Python load-testing library. Scenarios are Python functions decorated with @scenario.
grinder	The Grinder	.py Grinder script (Jython)	Supported	Java-based framework with Jython scripting. Legacy tool; prefer JMeter or k6 for new work.
junit	JUnit (Java)	Maven pom.xml or JAR	Supported	Runs Java JUnit load tests. Requires a Maven project structure; better suited to teams with existing JUnit performance tests.
testng	TestNG (Java)	Maven pom.xml or JAR	Supported	Like junit, using the TestNG framework. Same considerations apply.
mocha	Mocha (Node.js)	.js Mocha test file	Supported	Runs Node.js Mocha tests as load. Prefer k6 for new JavaScript load tests.
pbench	Pbench-fio / Pbench tools	Pbench config	Supported	Performance benchmarking suite from Red Hat. Niche use case — use when you specifically need Pbench’s tooling.
scalable	Scalable (internal)	YAML	Supported	An internal executor for distributed load-generation scenarios. Rarely needed — MaxoPerf handles distribution at the runner-fleet level.
external	External process	Any command	Supported	Runs an arbitrary external process as the load generator. MaxoPerf validates that the command: key is set. Use only when no other executor fits.

This list is live

This table mirrors SUPPORTED_TAURUS_EXECUTORS directly — if you count a different number of rows than you expected, the code changed since this page was last updated, and the code is authoritative.

Choosing between executors

Most new MaxoPerf tests should use one of the first-class executors:

• taurus (native) — a single declarative YAML with no external tooling.
• jmeter — for teams with existing JMX files, or who need JMeter’s plugin ecosystem.
• k6 — for teams that prefer JavaScript and want fast iteration on API load tests.
• selenium / playwright — for browser tests, see Browser tests.

The remaining supported executors work well but receive less specialized console tooling. If you hit a problem with one of them, MaxoPerf support can help.

Specifying the executor in a YAML

execution:
  - executor: locust          # must be one of the executors listed above
    concurrency: 20
    hold-for: 5m
    scenario: locust-scenario

scenarios:
  locust-scenario:
    script: locustfile.py     # must be uploaded as a Test asset

Single executor per YAML

MaxoPerf enforces exactly one executor: value per YAML (or none, defaulting to taurus). If you need to run two different engines together, create two separate tests and combine them into a VarioTest.

Where to go next

• Performance tests — load-testing with any executor.
• Functional API tests — single-iteration correctness checks.
• Browser tests — real-browser tests with selenium or playwright.
• Scriptless test builders — skip scripting entirely.