Grafana k6: load testing as JavaScript you can version and run in CI

The problem k6 solves, and who it is actually for

Most load testing tools were designed around a GUI: you record a session, save a project file, and hand the result to whoever owns the environment. That model breaks down when the thing under test changes every day. The README frames k6 as "like unit testing, for performance", and the framing is the product. A k6 script is a text file. It goes into the same repository as the service, it goes through the same review, and it can be run by the same CI pipeline that runs the unit tests.

The intended user is a developer or a tester working in a DevOps setting, not a dedicated performance engineer with a separate toolchain. The README lists "Tests as code" and "the best developer experience" as design goals, and the scripting API is the surface that matters. If your team already writes JavaScript, the syntax is not the obstacle. If your team does not, you are adopting a scripting language as part of adopting the tool.

One thing the README states plainly: you do not have to write code. k6 Studio is a separate desktop application, in its own repository, that generates k6 scripts. That matters for the adoption story, because it means the code-first model is a default rather than a hard requirement.

Go runs the load, JavaScript describes it

The architecture is a Go program with an embedded JavaScript engine. The README puts it as "the performance of Go, the scripting familiarity of JavaScript". The go.mod file names the engine: github.com/grafana/sobek, a fork of the Go JavaScript interpreter. k6 does not shell out to Node, and it does not run your script in a browser context. It parses and executes the script inside the k6 process.

That choice has consequences worth understanding before you write a large test suite. Your script can import k6 modules such as k6/http and k6, and the README points at a full JavaScript API reference. It cannot import arbitrary npm packages or Node built-ins, because the runtime is not Node. Bundling and transpilation happen inside k6 through esbuild, which appears in go.mod as github.com/evanw/esbuild. So modern syntax works, but the module graph is k6's, not npm's.

Load generation is configured from the script itself. The example in the README exports an options object with a thresholds block and a stages array, and the default export is the function each virtual user runs. Metrics are collected by the Go side, and the README describes flexible storage and visualization: summary statistics, or granular metrics exported to a service of your choice. Protocols beyond HTTP come from the core or from extensions; the README names WebSockets, gRPC and Browser, and points at an extension catalog.

Installing k6 and running a first threshold test

The README does not carry install instructions itself. It links to a Download page on GitHub Releases and to the documentation site, which covers getting started. So the canonical install path is the releases page or the docs, not a command reproduced here. What the repository does give you is a Dockerfile, and that is a legitimate way to run k6 without installing anything on the host.

The Dockerfile builds a release stage that runs as user 12345 with k6 as the entrypoint, and a second stage named with-browser that adds chromium and chromium-swiftshader and sets CHROME_BIN, CHROME_PATH, K6_BROWSER_HEADLESS and K6_BROWSER_ARGS. If you want browser tests in a container, that second stage is the one to build.

FROM release as with-browser

USER root

COPY --from=release /usr/bin/k6 /usr/bin/k6
RUN apk --no-cache add chromium chromium-swiftshader

USER 12345

ENV CHROME_BIN=/usr/bin/chromium-browser
ENV CHROME_PATH=/usr/lib/chromium/

ENV K6_BROWSER_HEADLESS=true

That is the browser-enabled stage copied from the repository's Dockerfile, including the environment variables it sets. Build it with the target name and tag it, then run a script against it. The image's entrypoint is k6, so the arguments you pass are k6 subcommands and flags.

For a local binary, the README's example script is the smallest useful test. Save it as script.js and run it. Note the two parts: the options export declares a threshold that 99 percent of requests finish within 3000ms, and the default export performs one GET and one check.

import http from "k6/http";
import { check, sleep } from "k6";

export const options = {
  thresholds: {
    http_req_duration: ["p(99) < 3000"],
  },
  stages: [
    { duration: "30s", target: 15 },
    { duration: "1m", target: 15 },
    { duration: "20s", target: 0 },
  ],
};

export default function () {
  let res = http.get("https://quickpizza.grafana.com");
  check(res, { "status was 200": (r) => r.status == 200 });
  sleep(1);
}

What you should see is a ramp from zero to 15 virtual users over 30 seconds, a minute at 15, then a ramp down to zero over 20 seconds. At the end k6 reports the metrics and evaluates the threshold. That threshold is the part that makes this a CI tool rather than a dashboard: a breached threshold gives a non-zero exit status, which is what a pipeline needs in order to fail the build.

Where k6 is the wrong tool

The JavaScript engine is the sharpest limitation. If your test needs a library that only exists on npm, or a Node built-in, k6 will not run it. You either rewrite the logic against the k6 API, or you move the logic out of the test and into the service. Teams coming from Node-based tooling discover this late, usually after the script has grown.

The second limitation is protocol coverage. The README advertises HTTP, WebSockets, gRPC and Browser, with extensions for more. That list is broad, but it is not universal, and extension support means building a custom binary rather than using the released one. If your target speaks a protocol that neither the core nor an extension covers, k6 is the wrong starting point.

Third, the README's note about k6 Studio is also a boundary. If your organization's model is that a non-developer records a flow in a GUI and the tool produces the artifact, k6's default path is the opposite: a text file that someone maintains. k6 Studio exists, but it is a separate desktop application in a separate repository, and it is not the same as the CLI workflow the README documents.

Finally, be careful about what the cloud service is and is not. The README describes native integration with Grafana Cloud as a SaaS solution for test execution, metrics correlation and data analysis. That is a commercial product adjacent to the open source tool. Nothing in the README says the cloud service is required to run a test locally, and nothing in the README states its pricing.

k6 against JMeter: two different centers of gravity

The comparison people reach for is JMeter, and the difference is not a feature list. It is where the test lives. JMeter's center of gravity is a GUI and an XML project file; you build a tree of thread groups, samplers and listeners, and the artifact is that tree. k6's center of gravity is a JavaScript source file that a reviewer can read as a diff.

That changes the workflow around the tool more than it changes the load generation. A k6 test can be parameterized by environment variables, imported by another script, and run with different options per environment without opening an editor. A JMeter test plan can be run headlessly too, and JMeter has a far longer history and a much wider set of protocol samplers. If your requirement is a protocol that k6 does not cover in core or in an extension, that history is the deciding factor.

The honest framing is that k6 trades breadth for a code-shaped workflow. If your team reviews tests in pull requests and wants a threshold breach to fail a build, k6 fits. If your team needs a mature GUI, a large library of off-the-shelf samplers, and a non-developer authoring path, JMeter's model is not a deficiency, it is the point.

Maintenance, releases and the AGPL-3.0 question

The repository is not archived, and the last push was on 2026-09-10, which is recent. Releases are frequent: the release list shows v1.8.1 on 2026-08-12, v2.2.0 on 2026-08-10, and v2.1.0 on 2026-06-30. Note the version numbers. A v1.8.1 and a v2.2.0 sit close together, and go.mod declares the module path as go.k6.io/k6/v2. That is a signal to pin an exact version in CI rather than tracking a floating tag, and to check which line a given release belongs to before upgrading.

Upgrade cost is mostly in your scripts, not in the binary. The scripting API is the contract you depend on, and a major version bump is where that contract can move. The practical hedge is to keep the test scripts in the same repository as the service, so a k6 upgrade and the script fixes land in one reviewable change.

On licensing: k6 is AGPL-3.0. That is a strong copyleft licence with a network clause, and it is a different proposition from a permissive licence. Whether it affects you depends on how you use k6 and what you distribute. Running k6 as a test tool against your own service is one thing; shipping a product that embeds k6, or offering a modified k6 as a network service, is another. The repository carries a LICENSE.md and a SUPPORT.md, and the README does not resolve the boundary cases. If your use is not clearly the first kind, read the licence text and get your own advice rather than relying on a summary.

Editorial conclusion

Adopt k6 if your tests should live in the repository next to the service they load, and if a threshold like p(99) < 3000 should be able to fail a CI job. Do not adopt it if your team needs a GUI-driven recorder as the primary authoring path, or if you need a JavaScript runtime with npm packages and Node built-ins, because k6 is neither. Before committing, verify three things: that the AGPL-3.0 licence fits how you distribute anything built on k6, that your chosen protocol is covered by the core build or an extension rather than by the cloud service, and that the binary you install is the same version you will pin in CI. The repository's last push was on 2026-09-10, and the newest release listed is v1.8.1 from 2026-08-12.

Frequently asked questions

Official sources

1. grafana/k6 on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases