Gatling load testing: a review of the JVM tool

Gatling is a free, Apache 2.0 load testing tool in which every test is a simulation written as code and run on the JVM, with an HTML report after each run. Gatling load testing suits developer teams who want tests in the repository, open or closed workload models and assertions that fail the build. Teams that want a GUI test builder or many protocols are better served by JMeter, and teams that want one binary with no JVM by k6.

We have not run Gatling for this review. The facts come from Gatling’s own documentation, repository and release pages, checked on 9 October 2026, and the judgements are ours.

Who makes Gatling, and is it still maintained?

Gatling Corp, a French company, develops Gatling and owns its copyright. It is actively maintained, with three JVM releases so far in 2026.

The licences page gives Gatling Corp the copyright. Maven Central lists 3.15.0 in February, 3.15.1 in May and 3.16.0 on 29 September 2026, and the JavaScript SDK reached 3.16.1 on 6 October. The 3.16 release notes add GraphQL and shared queues between virtual users. The README calls the repository the Community Edition, free to use including commercially (checked on 9 October 2026).

What do you need to run Gatling?

A 64-bit JVM for Java, Kotlin or Scala, or Node.js for JavaScript and TypeScript. Either way, the simulation itself runs on a JVM.

The installation page supports OpenJDK LTS versions 11 to 25 and excludes 32-bit JVMs and OpenJ9. The JavaScript CLI needs Node.js 24 or later and downloads a Gatling runtime bundle and, per the gatling-js README, GraalVM (checked on 9 October 2026).

How is a Gatling simulation structured?

A simulation defines scenarios, gives each one an injection profile and attaches a protocol configuration, all registered in one setUp call.

In the simulation reference, a scenario chains requests with pauses, loops and conditions. This Java simulation saves a product id from a search, pauses one to three seconds and opens the product, while arrivals ramp to 20 users per second and hold for ten minutes:

public class ShopSimulation extends Simulation {

  HttpProtocolBuilder api =
      http.baseUrl("https://staging.example.com");

  ScenarioBuilder shoppers = scenario("Shoppers")
      .exec(http("search").get("/api/products?q=lamp")
          .check(jsonPath("$[0].id").saveAs("id")))
      .pause(1, 3)
      .exec(http("product").get("/api/products/#{id}"));

  {
    setUp(shoppers.injectOpen(
        rampUsersPerSec(1).to(20).during(120),
        constantUsersPerSec(20).during(600)))
      .protocols(api)
      .assertions(
          global().responseTime().percentile(95.0).lt(800));
  }
}

Imports are left out, and #{id} is Gatling’s Expression Language reading the saved value. Gatling vs k6 shows a JavaScript simulation.

Should you inject users open or closed?

Open, for most websites and APIs, where new users keep arriving however slow the system gets. Closed suits systems that cap concurrency, such as a ticket queue.

The injection reference splits the API: injectOpen takes arrival rates such as rampUsersPerSec, and injectClosed takes concurrency targets such as constantConcurrentUsers. The workload models page says most websites are open systems and one profile cannot mix the two (checked on 9 October 2026). Our open vs closed workload model guide explains the choice.

How do checks, assertions and the report work?

Checks verify each response and can save values from it, while assertions judge the whole run once it ends. Every run then writes an HTML report.

Without an explicit status check, Gatling checks that each HTTP response is 2XX or 304. Assertions test response times, request counts or requests per second, globally or per request, and one failure fails the simulation. The HTML report charts response time ranges and percentiles, users started per second, concurrent users and requests per second; its percentiles over time count successful requests only (checked on 9 October 2026).

How does Gatling fit into a build and CI?

Through its Maven, Gradle, sbt or npm plugin, which runs in any CI system. A failed assertion fails the build.

The Maven plugin binds gatling:test to the integration-test phase, so mvn verify runs it, and with CI=true it skips the simulation prompt (the run then fails if the project has more than one simulation and none is named). The Gradle plugin uses gatlingRun, and the sbt plugin takes Scala simulations only. Gatling’s CI integrations, such as its GitHub Action, start Gatling Enterprise runs (checked on 9 October 2026). Our GitHub Actions guide covers the workflow.

Which protocols does Gatling support?

HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events and JMS ship without limits. gRPC, MQTT and GraphQL are separate plugins capped at 5 users and 5 minutes outside Gatling Enterprise.

The README puts the first five under Apache 2.0. The gRPC, MQTT and GraphQL setup pages put each plugin under the Gatling Enterprise Component License: unlimited on Gatling Enterprise, while a Community Edition test stops at 5 users or 5 minutes. That licence grants free use for up to one year, only for internal testing of your own web applications; it ends as soon as a limit is reached, and Gatling may change the limits. GraphQL needs 3.16.0 or later. Its release notes and the README say the JavaScript SDK does not support it yet, although the setup page already lists an npm package, so check before planning a JavaScript GraphQL test (checked on 9 October 2026). Our guide on how to load test a GraphQL API works around the cap with plain HTTP requests.

What does Gatling Enterprise add?

Gatling Enterprise is the commercial edition on the same engine. It generates load from managed or private infrastructure, which the free edition does not.

Per the README, Enterprise runs tests on managed load generators or in your own AWS, Azure, GCP or Kubernetes accounts, and adds live dashboards, trends, teams with SSO and CI/CD integrations. The FAQ says the Community Edition does not support distributed testing and that simulations move to Enterprise unchanged (checked on 9 October 2026).

LoadFocus, which publishes this site, does not run Gatling simulations. It runs JMeter test plans and k6 scripts from 25 cloud regions, so for Gatling the route to more machines is Gatling Enterprise.

What does Gatling do well, and where are its limits?

It is strong on tests as reviewable code, on load models and on reports with no setup. It is weaker on protocols beyond the web and messaging, and on free scaling past one machine.

The README credits its engine: non-blocking, built on Netty, with each virtual user a lightweight message. Limits the docs state themselves (checked on 9 October 2026):

• Gatling is not a browser: per the HTTP protocol page, it runs no JavaScript.
• The JavaScript SDK has no JMS and cannot use npm libraries that need native binaries or Node.js APIs.
• HTTP caching is on by default, which can lower request counts.
• The simulation.log format is undocumented and can change at any time.

When should you choose k6, JMeter or Locust instead?

Choose another tool when its language, protocols or free scaling route fit your team better.

Our open source load testing tools overview covers five others.

Choose k6 instead when you want one binary in CI with no JVM, thresholds that can stop a failing run early, or gRPC among its built-in protocols (checked on 9 October 2026). Gatling vs k6 compares the two.

Choose JMeter instead when testers build tests in a GUI, or you need JDBC, LDAP or FTP from its core (checked on 9 October 2026). LoadFocus runs existing JMeter test plans from 25 cloud regions, and Gatling vs JMeter goes deeper.

Choose Locust instead when your team writes Python and wants a distributed mode in the free tool (checked on 9 October 2026). Our Locust review covers it.

FAQ

Is Gatling free for commercial use? Yes. The Community Edition is Apache 2.0. The gRPC, MQTT and GraphQL plugins have their own licence and stop at 5 users and 5 minutes outside Gatling Enterprise.

Do you need Java to use Gatling? For Java, Kotlin or Scala, yes: a 64-bit OpenJDK LTS from 11 to 25. The JavaScript SDK needs Node.js 24 or later, and its CLI downloads the JVM runtime itself.

Can LoadFocus run Gatling tests? No. LoadFocus runs JMeter test plans and k6 scripts. To spread a Gatling simulation across several machines, use Gatling Enterprise.

Related reading

• Gatling vs JMeter: tests as code or a GUI test plan?
• Gatling vs k6: JVM simulations or a single Go binary?
• Open source load testing tools: six options reviewed
• Gatling vs Locust: JVM simulations or Python locustfiles?
• NBomber load testing: a review of the .NET framework

The technical claims in this article have not been independently reviewed.