Artillery load testing: a review of the Node.js tool

Artillery is an open source load testing tool that runs on Node.js and describes each test as a YAML, TypeScript or JavaScript file. Artillery load testing suits teams that live in the JavaScript ecosystem, want new users to arrive at a set rate, or want browser tests with Playwright in the same tool. Teams that want a single binary with no runtime are better served by k6, and teams that need many protocols out of the box by JMeter.

We have not run Artillery for this review. The facts come from Artillery’s documentation, repository, npm package and pricing page, checked on 19 October 2026, and the judgements are ours.

Who makes Artillery, and how is it licensed?

Artillery Software Inc. maintains it on GitHub. Most of the code is MPL-2.0, which allows commercial use; some Azure-specific modules are under the Business Source License.

The repository README says you may use Artillery on Azure for evaluation and proof-of-concept work, and that commercial or production use there needs a commercial licence. The latest release is 2.0.34, published to npm on 14 August 2026, and its package metadata asks for Node.js 22.18.0 or later; the install guide says to use the most recent LTS release (checked on 19 October 2026).

How does an Artillery test script work?

A script has two parts: config, which sets the target, the load phases and plugins, and scenarios, which list what each virtual user does. You can write it in YAML, or export config and scenarios from a TypeScript or JavaScript file.

This test ramps from 5 to 50 new users per second over two minutes, holds 50 per second for ten minutes, and fails if the 99th percentile response time reaches 800 ms:

config:
  target: https://staging.example.com
  phases:
    - duration: 120
      arrivalRate: 5
      rampTo: 50
      name: ramp
    - duration: 600
      arrivalRate: 50
      name: sustain
  plugins:
    ensure:
      thresholds:
        - http.response_time.p99: 800
scenarios:
  - name: browse and add to cart
    flow:
      - get:
          url: /products
      - think: 2
      - post:
          url: /cart
          json:
            sku: A-100

Per the test script reference, the four phase types are a constant arrival rate, a linear ramp with rampTo, a fixed arrivalCount spread over a period, and a pause. Custom code loaded through config.processor can be a TypeScript module locally and on Fargate, but not on Lambda (checked on 19 October 2026).

What load model does Artillery use?

Artillery starts new virtual users at a rate you set, whether or not earlier users have finished. That is an open workload model, which keeps arrivals steady even when the system slows down.

Each new user picks one scenario, runs it and leaves, so a slow system collects users the way real traffic would. maxVusers caps the number of concurrent users in a phase if you need to protect the load generator. Our article on the open vs closed workload model explains the difference, and Little’s law shows how arrival rate and response time set the number of concurrent users.

Which protocols and browsers can it test?

HTTP is the default, and WebSocket, Socket.IO and Playwright come built in. gRPC and AWS Kinesis need separately installed engines.

The engines page describes the model: each scenario runs on one engine, and you can write your own. On npm, artillery-engine-grpc is at 0.0.9 and artillery-engine-kinesis at 1.1.1, both MPL-2.0. The Playwright engine runs real headless browsers from your Playwright code and reports Web Vitals such as TTFB, FCP and LCP per page. The docs warn that a separate browser per user, instead of a browser context, needs a lot more CPU and memory (checked on 19 October 2026). Our roundup of WebSocket load testing tools puts Artillery next to other options for real-time apps.

How does it fit into CI?

The ensure plugin turns metrics into pass/fail checks, and a failed check makes Artillery exit with a non-zero code. That is enough for any CI system to fail the build.

The ensure reference offers two kinds of check: thresholds, where a metric must stay below a value, and conditions, which combine metrics in an expression such as http.response_time.p95 < 250 and http.request_rate > 1000. A condition marked strict: false reports without failing. The apdex plugin adds an Apdex score for HTTP tests, with a default threshold of 500 ms (checked on 19 October 2026); our article on the Apdex score explains how to read it. For a workflow file, see our guide to load testing in GitHub Actions.

How do you scale out an Artillery test?

From the command line, on your own cloud account: run-lambda and run-fargate on AWS, run-aci on Azure Container Instances. Artillery creates the resources it needs for the run and removes the temporary ones afterwards.

The Fargate guide lists the resources and IAM permissions involved. The Lambda guide states its limits: a test cannot run longer than 15 minutes, a running test cannot be stopped, and before and after hooks run once per worker. The Azure guide needs Artillery 2.0.19 or later and, outside evaluation, a subscription (checked on 19 October 2026).

LoadFocus, which publishes this site, does not run Artillery scripts. It runs JMeter test plans and k6 scripts from 25 cloud regions, so for Artillery the commands above are the way to scale.

What does Artillery Cloud cost?

The dashboard is optional: results go to it only when you run with --record and an API key. Plans run from a free tier to $499 a month.

The pricing page lists (checked on 19 October 2026):

• Free: 30 reports a month, 1 month of retention, 2 team members, distributed tests up to 5 workers and 30 minutes.
• Team, $199 a month: 1,000 reports, 6 months, 8 members, up to 25 workers and 2 hours.
• Business, $499 a month: 2,500 reports, 18 months, no limit on members, workers or duration.

Enterprise SSO, audit logs and support SLAs start at $1,199 a month, and annual billing saves 20%.

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

It is strong on arrival-rate load, short readable scripts and browser tests with Playwright. It is weaker where you need a single binary, many protocols without add-ons, or Azure use without a licence.

As a Node.js tool it can use any npm module in custom functions, at the cost of one more runtime on every test machine. Limits the docs state themselves:

• Lambda runs stop at 15 minutes and cannot be cancelled.
• TypeScript custom code (config.processor) does not run on Lambda.
• gRPC and Kinesis are separate engines.
• Production use on Azure requires a commercial licence.

When should you choose k6, JMeter or Locust instead?

Choose another tool when its runtime, protocols or language fit your team better.

Choose k6 instead when you want one Go binary with no Node.js to manage and thresholds in the script. Our k6 vs Artillery comparison covers the two side by side. LoadFocus runs k6 scripts from 25 cloud regions, though it runs arrival-rate scenarios with a fixed number of users, so for a held arrival rate run them with k6 itself.

Choose JMeter instead when you need JDBC, JMS, LDAP or FTP out of the box, or testers who build tests in a GUI.

Choose Locust instead when your team writes Python; our Locust review covers it. The open source load testing tools overview sets all of them side by side.

FAQ

Is Artillery free for commercial use? Most of the CLI is MPL-2.0, which permits commercial use. The exception is Azure: commercial or production use of its Azure modules needs a commercial licence.

Can Artillery run browser tests? Yes. Its built-in Playwright engine runs your Playwright code in headless browsers and reports Web Vitals for each page.

Can LoadFocus run Artillery scripts? No. LoadFocus runs JMeter test plans and k6 scripts. To scale an Artillery test, use run-lambda, run-fargate or run-aci.

Related reading

• k6 vs Artillery: which load testing tool fits your team?
• Open source load testing tools: six options reviewed
• Open vs closed workload model: which one should you use?
• WebSocket load testing tools: six options compared
• Apdex score: what it is and how to calculate it

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