Learn k6 - Pre-Requisite Skills & Environment Setup

#Introduction

Welcome to the Learn k6 series! This series takes you from zero to proficient in modern load testing and performance testing using k6 — an open-source tool from Grafana Labs written in Go with JavaScript scripting. A total of 19 episodes arranged in a step-by-step progression: starting from pre-requisites and environment setup, the history of k6 from Load Impact to its acquisition by Grafana Labs, virtual users and test lifecycle concepts, writing your first k6 script, HTTP API load testing, dynamic data and cookies, script modularization, load test configuration and environment variables, data-driven testing, complex multi-endpoint scenarios, TLS networking and WebSocket, OAuth2 and JWT authentication, security testing, performance analysis and optimization, observability with Grafana, InfluxDB, and Prometheus, resilience and failure analysis, k6 in CI/CD, distributed and cloud load testing, up to production readiness with the xk6 extensions.

Why is k6 worth learning? Because k6 reshapes the classic load testing paradigm: instead of a heavyweight GUI tool that consumes gigabytes of RAM, k6 is a single Go-based binary with small memory consumption, scripts are written in JavaScript so every developer can contribute, and the results integrate naturally with the observability stack — making it the de-facto standard for performance testing in the API and microservices era.

Episode 0 is the roadmap and foundation layer. We will make sure three things are in place: (1) the conceptual skills you must hold on to, (2) a brief understanding of the protocols and technologies that will be tested, and (3) a genuinely ready working environment — from an installed k6 binary to a comfortable editor. Don't skip around; a shaky foundation makes the following episodes feel heavy. Let's get started.

#Conceptual Skills You Must Have

#Load Testing vs Performance Testing

Before writing a single line of script, you must understand the difference between these two umbrella terms. Performance testing is the general term for any form of testing that measures how a system behaves under certain conditions. Inside it there are several genres, and load testing is one of them:

Genre	Focus Question	Example Scenario
Load Testing	Can the system handle normal-to-peak load?	500 concurrent users logging in
Stress Testing	At what point does the system start to break?	Increase users until errors appear
Soak Testing	Is performance stable over a long duration?	Normal load for 4 hours
Spike Testing	How does it react to a sudden surge?	Traffic increases 5x within 1 minute
Endurance Testing	Do memory leaks emerge over time?	Constant load for 24 hours

#Functional vs Non-Functional Testing

Functional testing answers the question "does the system do the right thing?" — the login endpoint returns a status of 200 and a valid token. Non-functional testing answers "does the system do it fast and stable enough?" — status 200 is returned in 250 milliseconds for 95% of requests, even while 500 users are active. k6 handles both at once: through check() you validate functional correctness, and through thresholds and metrics you measure non-functional quality.

Think of this difference like testing a restaurant: functional testing makes sure the menu reaches the table correctly, while non-functional testing makes sure service stays fast and friendly when the restaurant is packed at lunchtime.

#Protocols and Technologies You Should Know

k6 was born as an API performance testing tool, so you must be familiar with the language used by modern APIs.

#HTTP and HTTPS

HTTP is the communication protocol between client and server based on request-response. You should understand at least: methods (GET, POST, PUT, PATCH, DELETE), status codes (200, 201, 400, 401, 403, 404, 429, 500), headers (especially Content-Type and Authorization), and the difference between HTTP and HTTPS (HTTPS = HTTP over an encrypted TLS layer). All of these you will write directly into k6 scripts.

#WebSocket

WebSocket is a protocol that opens a persistent two-way connection between client and server — in contrast to HTTP, which is one-by-one request-response. WebSocket connections are used for real-time applications: chat, notifications, live data streaming. k6 has a dedicated module for testing WebSocket, and episode 11 of this series covers it in depth. For episode 0, it's enough to know when an application uses WebSocket and why it differs from plain HTTP.

#GraphQL and Modern APIs

GraphQL is a query language for APIs that lets clients request only the fields they need in a single request. REST breaks resources into many endpoints; GraphQL centralizes them in a single endpoint (usually /graphql) with a JSON-format query body. Other modern APIs worth knowing: gRPC (a very fast RPC protocol based on protobuf) and REST itself. k6 supports testing REST, GraphQL (via the query body), and gRPC through extensions. It's fine if you're not yet proficient in all of them — what matters is recognizing their shape.

#JavaScript and ES6 Basics

This is the most crucial one: k6 scripts are written in JavaScript, and its engine adheres to the ECMAScript standard with full support for ES6 features such as const, let, arrow functions, template literals, destructuring, and the spread operator. You don't need to be a frontend engineer, but you must understand the language basics: variables, functions, objects, arrays, for loops, and JSON (JSON.stringify / JSON.parse). Because k6 does not run on Node.js (it uses a Go ECMAScript engine named goja), some things that are common in Node — like fs, npm require, or a fully-featured console.log — have limitations. We'll break down this architecture in detail in episode 2.

#Monitoring and Metrics

k6 produces metrics for every test: http_req_duration (duration of one request), http_req_failed (failure ratio), http_reqs (throughput), and many more. You must understand the basic concepts of metrics and monitoring: what a percentile is (p95, p99 — meaning 95% or 99% of requests complete below that value), what a time series is, and how metrics flow into observability systems like Prometheus or Grafana. This concept will be used throughout the entire series.

#Environment Setup

#Install the k6 Binary

The easiest and most tested way is to install the official k6 binary from each platform's official channel. k6 is a single binary file — no separate server, no running agent. The command k6 run script.js is all you need to get started.

sudo gpg -k
sudo gpg --no-default-keyring --keyring /usr/share/keyrings/grafana.gpg --keyserver keyserver.ubuntu.com --recv-keys 379CE192D401AB61
echo "deb [signed-by=/usr/share/keyrings/grafana.gpg] https://packages.grafana.com/oss/deb stable main" | sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt-get update
sudo apt-get install -y k6

An equally valid alternative for all platforms: download the binary from the k6 GitHub releases page, extract it, and put it in a directory that is in your $PATH. Since k6 is purely a binary, this works identically on Linux, macOS, and Windows (you just download the right architecture variant).

#Verify the Installation

Once installed, run the simplest sanity check:

Verify k6

k6 version
k6 inspect --help

The output of k6 version will print a version number like k6 v0.56.0 (2025-07-18T13:00:00.0000Z, go1.24.0, linux/amd64). The second line confirms the inspect subcommand is available. If both commands run, your environment is ready to run real tests.

Tip

Always check the latest k6 release on the official releases page. k6 moves fast — new versions bring ECMAScript engine improvements, new modules, and performance fixes. Following the official stable releases is a good habit that will pay off in the upcoming episodes.

#Editor for Writing Scripts

Since k6 scripts are JavaScript, you need an editor with JavaScript support. VS Code with the built-in JavaScript and TypeScript extensions is more than enough: syntax highlighting, auto-complete, and lint errors will catch syntax mistakes before the script runs. If you like terminal editors, Neovim is also an excellent choice. One important thing: k6 script files are commonly named with the .js extension, and the load test project folder should be kept separate from the main application so they don't get mixed up.

#Stable Internet Connection

Load testing requires you to direct load at a real target — whether https://test.k6.io for practice or your team's internal endpoints. Make sure your internet connection is adequate, and understand that the load k6 generates is limited by your local machine's bandwidth and resources. For large scale, k6 offers cloud execution and distributed testing, which we'll cover in episode 18.

#Docker (Optional but Recommended)

k6 officially publishes the grafana/k6 image on Docker Hub. Running k6 through Docker keeps the environment clean and uniform across all machines — very useful for CI/CD. The simplest example:

Running k6 inside Docker

docker run --rm -i grafana/k6 run - < script.js

This command forwards the contents of script.js into the container via stdin, runs the test, then discards the container (--rm) when finished — leaving no leftovers. For more advanced usage, you'll mount the script folder with -v so k6 inside the container can read files: docker run --rm -v $(pwd):/scripts -w /scripts grafana/k6 run script.js. Episode 17, which covers CI/CD, will rely heavily on this pattern.

#Common Setup Mistakes

A k6 version that is too old. Features you'll see in the following episodes (for example, the new WebSocket module) may not exist yet. Always use the latest stable release, not a version carried over from an old tutorial.
Confusing k6 with a cloud account. The open-source k6 binary runs fully locally without any account. A Grafana Cloud account is optional for cloud execution features — it's not required to follow this series.
Mixing scripts with the application project. Load tests easily get mixed up with application code. Create a separate directory, e.g. tests/load/, and keep every script as a unit that can run on its own.
Expecting output in the browser. k6 is a CLI tool. All output lives in the terminal; dashboard visualizations only appear when you stream metrics to Grafana (episode 15).
Ignoring k6 version. Checking the version is the first diagnostic step when a feature is unavailable or behavior looks odd. Make it a habit.

#Conclusion

In this episode 0 you've set up three foundations: conceptual skills (load vs performance testing, functional vs non-functional testing), protocol understanding (HTTP/HTTPS, WebSocket, GraphQL, JavaScript ES6 basics, metric and percentile concepts), and a ready environment (an installed and verified k6 binary, a JavaScript editor, internet connection, and the Docker option).

Key points to take away:

k6 is a single Go-based binary — scripts in JavaScript, lightweight execution.
Load testing is only one genre of performance testing; k6 measures and validates functional correctness at the same time.
k6 run script.js is the core command; k6 version is the first check when something goes wrong.
Docker setup (grafana/k6) is optional but will be very helpful in the CI/CD phase.

Your environment is ready. In episode 1 we'll step back briefly to understand the history, background, and why k6 was born: from Load Impact in 2017, open-source in 2018, the Grafana Labs acquisition in 2021, up to an honest comparison with JMeter, Gatling, and Locust — and when you should choose k6. See you in episode 1!