# gatling/gatling: load testing as code, and the parts the README leaves out

> Gatling is an Apache-2.0 load testing platform whose tests are written in Java, JavaScript, TypeScript, Kotlin or Scala. It is a strong fit for engineers who want version-controlled performance tests, and a poor fit for anyone who wants a GUI-first workflow.

**gatling/gatling** — Modern Load Testing as Code

- Repository: https://github.com/gatling/gatling
- Website: https://gatling.io
- Stars: 6,956 · Forks: 1,207
- Language: Scala
- License: Apache-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/gatling-gatling

## The problem Gatling solves, and who ends up using it

Load tests that live in a GUI tend to rot. The scenario is stored in a proprietary format, nobody reviews changes to it in a pull request, and the only person who can edit it is the person who built it. Gatling's answer is to make the scenario a source file. The README describes the project as a platform that lets teams "simulate real-world traffic, validate system behavior under load, detect regressions early, and make confident release decisions", with tests written in Java, JavaScript, TypeScript, Kotlin or Scala using what it calls fluent and expressive SDKs.

The intended audience is narrow and specific. The README lists the symptoms it is targeting: teams tired of maintaining heavy injection infrastructure, teams frustrated with complex GUIs and proprietary test formats, teams that want an SDK rather than XML dumps, and teams that want performance tests inside version control. If none of those sentences describe your situation, the code-first premise buys you nothing and costs you a build step.

Official protocol support is HTTP, WebSocket, Server-Sent Events, JMS, gRPC and MQTT. That list matters more than any feature bullet, because it decides whether Gatling can talk to your system at all. A team testing a proprietary binary protocol over raw TCP will not find it here.

## Non-blocking IO and the module layout behind it

The architectural claim in the README is that legacy tools rely on blocking IO and one-thread-per-user designs, which forces teams to run large farms of injection servers, while Gatling uses a non-blocking, asynchronous architecture to get more load per node. The repository layout supports that story: there is a gatling-netty-util module and a gatling-http-client module, so the HTTP path is built on Netty rather than on a thread pool sized to the virtual user count.

The code is split by concern and by language. gatling-core holds the simulation engine and gatling-core-java is the Java-facing layer; gatling-http and gatling-http-java mirror each other the same way, as do gatling-jdbc, gatling-jms and gatling-redis against their -java counterparts. gatling-charts handles report rendering, gatling-recorder is the browser session recorder the README mentions, gatling-quicklens and gatling-jsonpath support response checking, and gatling-test-framework is the piece that lets a simulation run as a test. The build is a single build.sbt, and the primary language is Scala, which is worth knowing before you file an issue about the build.

That split is the real design decision. The engine is Scala, the ergonomics are per-language wrappers, and the two are versioned together in one repository. It means a fix in the core reaches every SDK, but it also means the Java and JavaScript surfaces are bound to the core's release cadence rather than evolving independently.

## Installing Gatling and running a first simulation

The README does not contain installation commands. It points to the official tutorials at docs.gatling.io and gives two direct links: a Java JVM installation guide and a JavaScript installation guide. That is the honest starting point, and it is where the actual JDK requirement, the build tool setup and the project scaffolding are documented. Treat the tutorial as the source of truth rather than any snippet you find elsewhere.

What the README does commit to is the shape of a test: a simulation written in one of the supported languages, using the SDK for that language. The repository names the modules that back each surface, so a Java project depends on the Java artifacts and a JavaScript or TypeScript project goes through the JavaScript installation path. The Gatling Maven Central badge in the README points at io.gatling:gatling-core, which is the coordinate to look up when you need to confirm what is published.

Once a simulation exists, the workflow the README describes is: run it, compare the run against previous runs to detect regressions, and optionally enforce a performance gate in CI. The open-source repository provides the engine, the recorder, the charts and the test framework integration; the automated triggering and stop criteria are described as pipeline concerns rather than as a bundled scheduler.

```bash
# Not from the README. The README links to the installation guides at
# docs.gatling.io instead of listing commands. Follow the Java JVM guide
# or the JavaScript guide before running anything.
```

Because no commands are given in the repository README, there is nothing here to copy verbatim. Anyone who needs a working setup should start from the tutorial link and confirm the toolchain it names is present on the machine that will generate load.

## Where Gatling is the wrong tool

The README is candid about one boundary by omission: the features that make Gatling attractive to managers are in the Enterprise Edition. Real-time dashboards, trend analysis, SLO monitoring, AI-assisted summaries, APM integrations, role-based access control, SSO, quotas, shared reports, Slack, Teams and Jira integrations, and low-code or no-code test creation are all listed under Gatling Enterprise Edition or under the collaboration and governance heading. The open-source distribution is the engine, the SDKs, the recorder and the charts.

That is a genuine limitation, not a marketing quirk. A team that reads "monitor SLOs" and "automate performance gates" in the opening paragraph and then installs the Apache-2.0 build will find that the monitoring surface is thinner than the paragraph implied. The README does not document what the open-source build does for SLO tracking, so plan on verifying it before you promise it to anyone.

There is a second boundary: the code-first premise. If your organization has no build pipeline for the test project, no repository discipline, and no one willing to own a Scala-based engine's upgrade path, a GUI tool will get you a first result faster. Gatling assumes a team that treats performance tests as software. Teams that do not will spend their time on tooling instead of on load.

## Gatling against JMeter and k6, in approach rather than in features

The obvious comparison is Apache JMeter, and the difference the README draws is architectural rather than cosmetic. JMeter's classic model is thread-per-user with blocking IO, which is why large tests get distributed across many machines. Gatling's non-blocking Netty-based client is designed to keep more virtual users on one node. The practical consequence is that Gatling's capacity planning conversation is about one machine's limits, while JMeter's is often about how many remote workers you can coordinate.

The second comparison is k6, which also puts tests in code and targets CI. The difference here is the language surface and the runtime. Gatling offers Java, JavaScript, TypeScript, Kotlin and Scala SDKs over a Scala engine on the JVM, which suits teams already standardized on the JVM and its tooling. k6 is JavaScript-first on a Go runtime. Neither choice is better in the abstract; the deciding question is which language your engineers will actually maintain, and whether your build agents already have that runtime installed.

A third point of difference is the recorder. Gatling ships gatling-recorder in the repository, so browser sessions can be captured and exported to code, which shortens the gap between a manual walkthrough and a scripted scenario. The README also mentions building tests visually and exporting to code, but that sits closer to the Enterprise feature list than to the open-source core.

## Maintenance, licensing and what an upgrade actually costs

The repository is not archived, and the last push was on 2026-09-18, four days before this article. That is a live codebase, and the presence of .scala-steward.conf indicates automated dependency updates are configured, which matters for a JVM project with a Netty-based client underneath it.

The licence is Apache-2.0, stated plainly at the end of the README and present as LICENSE.txt and a NOTICE.md at the repository root. Apache-2.0 is permissive: you can use the engine commercially and modify it, and the NOTICE file is the mechanism for attribution. What the licence does not cover is the Enterprise Edition, which is a separate product with separate terms, and the README does not describe those terms. If your organization's legal review depends on knowing exactly which features fall on which side of that line, the README is not sufficient documentation and the licensing page is the place to look.

The upgrade cost is the part teams underestimate. Because the engine is Scala and the SDKs are generated per language, a major version bump can move the simulation DSL, not just the dependency version. The repository keeps gatling-core-java, gatling-http-java, gatling-jdbc-java, gatling-jms-java and gatling-redis-java as separate modules, so a Java user's compile errors will point at the Java layer while the underlying change may be in the core. Budget for reading release notes rather than for a version-string edit.

## Conclusion

Adopt Gatling if your team already keeps test code in a repository and wants performance runs to be reviewable artifacts. Do not adopt it if you need a point-and-click tool with no build step, or if you expect the open-source distribution to give you the dashboards, SSO and quota features the README attributes to Gatling Enterprise Edition. Before committing, open the Java JVM or JavaScript installation guide at docs.gatling.io and confirm that a supported JDK is available on your build agents, since the README itself never states a required version.

## FAQ

### What is Gatling used for?

Gatling is an open-source load testing platform for simulating real-world traffic, validating system behavior under load and detecting regressions before a release. It officially supports HTTP, WebSocket, Server-Sent Events, JMS, gRPC and MQTT, and integrates with CI/CD pipelines and APM tools.

### How to use Gatling for performance testing?

You define the test as code in Java, JavaScript, TypeScript, Kotlin or Scala using the SDK for that language, then run the simulation and compare the result against previous runs. The README directs new users to the official tutorials at docs.gatling.io, which cover the Java JVM and JavaScript paths.

### How to install Gatling on Windows or macOS?

The README does not list platform-specific install commands. It links to an official Java JVM installation guide and a JavaScript installation guide at docs.gatling.io, and those guides are where the setup steps for each operating system live.

## Sources

- [gatling/gatling on GitHub](https://github.com/gatling/gatling)
- [Issues](https://github.com/gatling/gatling/issues)
- [License: Apache-2.0](https://github.com/gatling/gatling/blob/main/LICENSE)
- [Project website](https://gatling.io)
- [README](https://github.com/gatling/gatling/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gatling-gatling