Running k6 at Scale: k6 OSS vs Grafana Cloud k6 vs LoadFocus

Key takeaways

• Self-hosted k6 is cheapest until you need distribution, which is where the operational cost starts.
• Managed options mostly sell orchestration and retention rather than a faster engine.
• Decide by how often you run at scale, not by peak virtual users.

There are three ways to run k6 at scale: self-host the open source binary (on several machines or with the k6 Operator on Kubernetes), run it on Grafana Cloud k6, or upload the same script to a managed load testing platform such as LoadFocus. The k6 engine is the same in all three. What changes is who provisions the load generators, who merges the results, and how you pay.

k6 is free and open source, and on a laptop it is a pleasure to use. The moment you need tens of thousands of virtual users, traffic from several regions at once, and results you can read afterwards, “k6 is free” and “running k6 at scale is free” turn out to be two different statements. We run k6 in the cloud on LoadFocus, so we will be upfront about where each option fits, including ours.

What Does “k6 at Scale” Require?

Scale for k6 means more than a big --vus number. A single k6 process is efficient: Grafana’s own guide to running large tests says one instance can run 30,000 to 40,000 virtual users on a well-sized machine, with simple tests using about 1 to 5 MB of memory per VU. Most teams need more than one machine for other reasons: network bandwidth, regions and coordination.

To generate a large, realistic load you need four things beyond the binary:

• Enough load generators. One machine runs out of CPU, memory or network bandwidth first. Grafana recommends keeping k6 under about 80% CPU, and notes that a 1 Gbit/s network card can cap the load before k6 does.
• Geographic distribution. Real users are not all in one data centre, so meaningful tests originate from several regions at once.
• Coordination. Starting and stopping many generators together, then merging their metrics into one result with correct percentiles.
• Result storage and charts. k6 prints an end-of-test summary and can stream metrics out; something has to receive, store and chart them.

Every option below solves these four problems differently. That is really what you are choosing between. If you are still sizing the test, our explainer on what virtual users are and how many you need is a good starting point.

One k6 Script for All Three Options

The script does not change between options, which is the main reason k6 scales well as a workflow. This one ramps to 200 virtual users, holds for five minutes and fails the run if more than 1% of requests fail or the 95th percentile goes over 500 ms. It reads the target from an environment variable so the same file runs against staging or production.

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

export const options = {
  scenarios: {
    steady_browse: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '2m', target: 200 }, // ramp up
        { duration: '5m', target: 200 }, // hold
        { duration: '1m', target: 0 },   // ramp down
      ],
    },
  },
  thresholds: {
    http_req_failed: ['rate<0.01'],   // under 1% errors
    http_req_duration: ['p(95)<500'], // 95% of requests under 500 ms
  },
};

const BASE_URL = __ENV.BASE_URL;

export default function () {
  const res = http.get(`${BASE_URL}/`);
  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1);
}

Thresholds are what make a run at scale useful in CI: k6 exits with a non-zero code when one fails, so a pipeline can stop on a regression without anyone reading a chart. We use p95 rather than the average for the reason covered in why percentiles beat averages. In a script with several scenarios, a tag filter such as {scenario:checkout} gives each one its own pass or fail, as our run of per-scenario thresholds in k6 shows.

Option 1: Self-Hosted k6 OSS and the k6 Operator

The open source k6 binary is free under the GNU AGPL v3 licence, and you can run large tests with it. On one machine it is a single command:

k6 run -e BASE_URL=https://staging.example.com load-test.js

For repeatable distributed runs, the common approach is the k6 Operator on Kubernetes. It splits one test across several k6 runner pods, each taking an equal share of the load, so a 200-VU test with parallelism: 4 becomes four runners of 50 VUs. Install it and store the script in a ConfigMap:

# install the operator (Helm: helm install k6-operator grafana/k6-operator)
curl https://raw.githubusercontent.com/grafana/k6-operator/main/bundle.yaml | kubectl apply -f -

# put the script in a ConfigMap
kubectl create configmap k6-test --from-file load-test.js

Then describe the run as a TestRun resource and apply it with kubectl apply -f testrun.yaml:

apiVersion: k6.io/v1alpha1
kind: TestRun
metadata:
  name: k6-at-scale
spec:
  parallelism: 4
  arguments: -e BASE_URL=https://staging.example.com
  script:
    configMap:
      name: k6-test
      file: load-test.js

Good for: teams that already run Kubernetes, want full control, and have the operations capacity to manage load generators.

The catch: the software is free, but the infrastructure and the time are not. You pay for the nodes while they run, you build the multi-region setup yourself (a cluster or node pool in each region you want load from), and you assemble the results pipeline, for example k6 streaming to Prometheus or InfluxDB with Grafana on top. Each runner pod reports its own end-of-test summary, so for one combined view of the run you send every pod’s metrics to a shared backend. For a single machine, the built-in web dashboard (K6_WEB_DASHBOARD=true) gives live charts and an HTML report. Self-hosting is the cheapest in licence cost and the most expensive in engineering effort, much like running distributed JMeter tests yourself.

Option 2: Grafana Cloud k6

Grafana Cloud k6 (formerly k6 Cloud) is the official managed way to run k6, and part of Grafana Cloud. You keep writing the same JavaScript tests, authenticate with k6 cloud login, and start a run on Grafana’s infrastructure with k6 cloud run -e BASE_URL=https://staging.example.com load-test.js. Since k6 v2.0, every k6 cloud command needs a Grafana Cloud stack configured. Grafana handles distribution across its load zones, which you choose in the script under options.cloud.distribution, and gives you hosted dashboards next to the rest of your Grafana data. There is also k6 cloud run --local-execution, which runs the test on your machine and streams the results to Grafana Cloud.

Good for: teams whose observability already lives in Grafana and who want the first-party option, with test results next to their metrics, logs and traces.

How pricing works: Grafana Cloud k6 bills by virtual user hours (VUh). The free tier is limited to 500 VUh per month; the Pro plan starts at $0.15 per VUh on top of a $19 monthly platform fee, with lower per-hour rates at higher volume (grafana.com/pricing, October 2026). Grafana’s baseline formula is peak VUs x test duration in minutes / 60, so the example script above (200 VUs, 8 minutes) comes to about 27 VUh per run, and the free tier covers about 18 such runs a month. Newer subscriptions bill per minute, which can count somewhat less. Runs with --local-execution also use VUh.

Option 3: A Managed Cloud Load Testing Platform

The third path is a managed platform that runs your existing k6 scripts without you adopting Grafana Cloud or building your own generators. You upload the same JavaScript file, choose how many virtual users and which regions, and the platform handles distribution, coordination, storage and charts.

This is where LoadFocus fits. k6 load testing on LoadFocus runs the k6 open source engine in its own cloud, from 25+ cloud regions, with up to 20,000 concurrent virtual users depending on the plan. You upload a standard k6 script that uses export default function, pass variables such as BASE_URL as environment variables, and split the load between regions with custom percentages. Your check() and threshold rules decide whether the run passes, and paid plans include AI analysis that explains the results in plain language. Runs can be scheduled, with an email when a threshold fails.

Good for: teams that want managed, multi-region k6 runs on a flat monthly plan, without running performance testing inside Grafana Cloud.

Cost and Effort, Side by Side

LoadFocus figures are from loadfocus.com/pricing and the k6 load testing page; Grafana figures from grafana.com/pricing, both read in October 2026. Prices and limits change, so check both before you budget.

How to Choose a Way to Run k6 at Scale

The deciding factor is usually how often you run large tests, not the peak number of virtual users. A team running one big test before each quarterly release can live with some setup work. A team running a multi-region test on every release needs that setup to cost nothing per run.

• Choose self-hosted k6 OSS if licence cost is what you are optimising for, you already run Kubernetes, and you have the capacity to own load generators and a results pipeline.
• Choose Grafana Cloud k6 if your observability already lives in Grafana and you want the first-party managed option, and your usage fits per-VUh billing.
• Choose a managed platform like LoadFocus if you want distributed, multi-region k6 runs with no infrastructure to manage, a fixed monthly price, and you would rather not run performance testing inside Grafana Cloud.

These are not mutually exclusive. Plenty of teams use the free binary for quick local checks and a managed cloud for the large, multi-region runs that need scale. To estimate the size of that run, see how to calculate concurrent users for a load test.

Run k6 in the Cloud With LoadFocus

Bring your existing k6 script, run it from 25+ cloud regions, set pass and fail thresholds, and read an AI analysis of the results, with no load generators to manage. Start a free load test or see how cloud load testing works. Prefer JMeter? The same platform also runs JMeter cloud load testing from your .jmx files.

Frequently Asked Questions

Is k6 free?

Yes. k6 is open source under the GNU AGPL v3 licence, and you can run large tests with it at no licence cost. What is not free is the infrastructure and operations work needed to run it across many machines and regions, or the managed cloud services that do that for you.

What license is k6 under?

The k6 engine is licensed under the GNU Affero General Public License v3 (AGPL-3.0). The AGPL’s source-sharing obligations are aimed at modified versions of the software offered to others, including over a network, so check them with your legal team if you plan to modify or redistribute k6 itself.

Is Grafana Cloud k6 free?

Grafana Cloud k6 has a free tier limited to 500 virtual user hours per month. Beyond that it is billed per virtual user hour on a paid Grafana Cloud plan; in October 2026 the Pro plan started at $0.15 per VUh plus a $19 monthly platform fee. Check grafana.com/pricing for current figures.

How do I run k6 in the cloud without Grafana?

Use a managed load testing platform that runs k6 scripts, such as LoadFocus, where you upload your script and run it from 25+ cloud regions with no infrastructure to manage. Alternatively, self-host distributed k6 on your own cloud machines, for example with the k6 Operator on Kubernetes.

How do I run distributed k6 tests?

Run several k6 instances yourself, or install the k6 Operator on Kubernetes and create a TestRun resource with a parallelism value, which splits the load evenly across runner pods. You then need a metrics backend to merge their results. The managed alternatives are Grafana Cloud k6 and platforms that distribute the run across regions for you.

How many virtual users can k6 generate?

Grafana’s guidance is that a single k6 instance can run 30,000 to 40,000 virtual users on a machine with enough CPU, memory and network bandwidth, with simple tests using about 1 to 5 MB of memory per VU. Heavier scripts reduce that number. To go higher, or to generate load from several regions at once, distribute the test across multiple generators.

Sources

• Grafana k6 documentation, Running large tests (grafana.com/docs/k6/latest/testing-guides/running-large-tests) (VUs per instance, memory per VU, CPU and network guidance), October 2026.
• Grafana k6 documentation, Install k6 Operator (grafana.com/docs/k6/latest/set-up/set-up-distributed-k6/install-k6-operator) and Run k6 scripts with the TestRun CRD (grafana.com/docs/k6/latest/set-up/set-up-distributed-k6/usage/executing-k6-scripts-with-testrun-crd), October 2026.
• Grafana k6 documentation, k6 v2.0.0 release notes (grafana.com/docs/k6/latest/release-notes/v2.0.0) (stack required for k6 cloud commands), October 2026.
• Grafana k6 documentation, Web dashboard (grafana.com/docs/k6/latest/results-output/web-dashboard), October 2026.
• k6 licence: LICENSE.md in the grafana/k6 repository (GNU AGPL v3), checked October 2026.
• Grafana Cloud k6 pricing and load zones: grafana.com/pricing and the Grafana Cloud k6 “Use load zones” documentation, read October 2026.
• LoadFocus: loadfocus.com/k6-load-testing and loadfocus.com/pricing, read October 2026.

Related reading

• k6 vs JMeter vs Gatling vs Locust Compared (2026)
• Open Source vs Commercial Load Testing Tools
• LoadFocus vs JMeter for Enterprise Load Testing