Yandex.Tank: a load testing orchestrator for Linux users who script their benchmarks

What Yandex.Tank actually solves, and who it is for

Load generators are easy to find and annoying to operate. phantom, JMeter, BFG and the experimental Go generator pandora each have their own configuration, their own output format and their own way of being started. Yandex.Tank sits above them. The README describes it as an extensible open source load testing tool for advanced linux users, especially good as part of an automated load testing suite. That phrase, advanced linux users, is doing real work. The tool is console-first, its monitoring plugin works over SSH, and the documentation points to readthedocs rather than to a web UI.

The audience is therefore a performance engineer who already knows what RPS and quantiles mean and wants the orchestration handled. The README lists the pieces: multiple load generators, ammo formats such as a plain URL list or an access.log, an autostop plugin that ends a test once the result is obvious, and customizable monitoring over SSH. Results can be shipped to Overload, a separate performance analytics service at overload.yandex.net. If you want a hosted dashboard with no server of your own, that service is the intended path, not the tank itself.

The mechanism: a configuration layer that drives external shooters

setup.py is explicit about the architecture. Yandex.Tank is a performance measurement and load testing automatization tool that uses other load generators such as JMeter, ab or phantom inside of it for load generation, and provides a common configuration system for them and analytic tools for the results they produce. So the tank is not a shooter. It is a controller plus a result pipeline.

The default shooter is phantom, described in the README as a very fast (100 000+ RPS) shooter written in C++. JMeter is offered as the extendable and widely known option. BFG is the Python-based generator that lets you write load scenarios in Python. pandora is labelled experimental and written in Go. Load is described to the tank as ammo, and the README names plain URL lists and access.log files as supported formats. The autostop plugin watches the running test and stops it when the outcome is clear, which matters when a benchmark would otherwise run to completion for no new information. Monitoring is pluggable and works over SSH, so you can pull host metrics from the machines under test.

The dependency list in setup.py shows where the analysis side comes from: pandas capped at 2.0.3, numpy capped at 1.26.4, influxdb, cerberus for configuration validation, pyyaml, psutil and environ-config. Those caps are worth reading before you upgrade a shared environment, because the tank will hold pandas and numpy back.

Installing Yandex.Tank and running a first test

The README does not inline install commands. It links to an Installation page on readthedocs, at yandextank.readthedocs.org/en/latest/install.html, and that page is the authoritative source for your distribution. What the repository does state is the interpreter requirement. The README says yandextank has been moved to Python 3 and links to the latest stable release for Python 2 for anyone who cannot move, and setup.py declares python_requires='>=3.12'. The distribution name declared in setup.py is yandextank.

A load test is driven by a configuration file, and the readthedocs documentation is where the plugin and option names are defined. The README does not print a full config, and the repository keeps its documentation sources in the docs/ tree, so the concrete option names to copy come from there rather than from the README. Read the configuration reference for your installed version before writing the file.

The run itself is started from the console, and the reader should expect console output as the test progresses plus result artefacts written to the working directory. The README shows a quantiles chart as the visual output of a run, and points to Overload if you want the results stored and analysed online rather than on the box that ran the test. For a reproducible environment, the repository ships Dockerfile-test and a docker/ directory, and the README links a third-party Vagrant environment with Yandex.Tank.

Where Yandex.Tank is the wrong tool

The first limitation is stated by the project itself: it is for advanced linux users. The classifiers in setup.py list Operating System :: POSIX. There is no Windows story in the README, and the monitoring plugin assumes SSH. If your team runs its load tests from Windows workstations, this is friction you will feel on day one.

The second is the release situation. The releases page shows a Python 2 tag dated 2020-10-30 as the latest stable release for Python 2, and the two entries before it are v1.12.8 from 2020-01-21 and v1.12.3 from 2019-07-04. The README frames the Python 2 tag as a fallback. Meanwhile setup.py requires Python 3.12 or newer, which is a recent interpreter floor. That combination means the tagged releases and the current source tree are far apart. Anyone pinning to a tag should read what that tag actually supports rather than assuming parity with master.

The third is dependency drag. pandas is pinned at or below 2.0.3 and numpy at or below 1.26.4 in the install requirements. If you install the tank into the same environment as a modern data stack, pip will resolve downward and you may break something else. A virtualenv or container is the sane isolation, and the repository does ship Docker-related entries (Dockerfile-test, a docker/ directory) plus a third-party Vagrant environment linked from the README.

A fourth, quieter limitation: because the tank delegates load generation, its ceiling is the ceiling of the shooter you pick. Choosing JMeter for convenience gives you JMeter's resource profile, not phantom's.

How it compares with k6 and Locust

The nearest alternatives are k6 and Locust, and the difference is architectural rather than cosmetic. k6 and Locust are self-contained: the generator and the test script live in one process, written in JavaScript or Python respectively, and you install one binary or one package and go. Yandex.Tank is a coordinator. It owns the configuration, the ammo, the autostop logic and the monitoring, and it hands the actual shooting to phantom, JMeter, BFG or pandora.

That split is the whole argument. You get to keep a generator you already trust, or swap one for another, without rewriting the surrounding harness, and you get one configuration format across all of them. The cost is more moving parts: a tank process, a shooter process, an ammo file, and possibly an Overload account for online analysis. Locust's Python scenarios and BFG's Python scenarios are the closest overlap, but BFG is a generator plugged into the tank, not the tank itself.

The README also lists ab among the generators the tool can drive, which tells you the project's design intent is breadth of backends rather than a single opinionated engine.

Maintenance, upgrades and the licence question

The repository is not archived and its last push was on 2026-09-22, so work is landing on master. That is the only maintenance signal available here. It does not tell you the cadence of tagged releases, and the releases page suggests tags are not the primary distribution channel for current users. If you deploy from a tag, budget time to compare it against master before you file a bug.

Upgrading carries a real cost because of the pinned analysis stack. Moving the tank forward may require moving pandas and numpy backward relative to the rest of your tooling. The Python floor of 3.12 in setup.py also means an interpreter upgrade on the load-generator host, which is a change to a machine whose job is to saturate a target. Keep the tank in its own environment.

On licensing: setup.py declares license='LGPLv2' and the classifiers say GNU Lesser General Public License v2 or later (LGPLv2+), while the repository metadata reports NOASSERTION. That disagreement is worth resolving with your own legal review before you redistribute anything built on it. The practical shape of the LGPL is that linking to the library does not force your own code under the same licence, but modified versions of the library carry obligations. This is a description of what the files say, not legal advice.

Editorial conclusion

Adopt Yandex.Tank if you run Linux, already script your load tests in CI, and want one configuration layer over phantom, JMeter, BFG or pandora with SSH monitoring and autostop. Do not adopt it if you need a GUI, a managed cloud service, or a tool you can install on a stock Python 3.11 or older interpreter, because setup.py requires Python 3.12 or newer. Before committing, verify the install path in the readthedocs installation page against your distribution, check that the ammo format you already have (a URL list or an access.log) is accepted, and confirm whether your team is willing to run a Python 2 release tag from 2020 if you are pinned to an older interpreter. The repository's last push was on 2026-09-22, so the code is moving even though the newest tagged release on the releases page is the Python 2 tag from 2020-10-30.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. yandex/yandex-tank on GitHub