K6 Pickup
A k6 pickup workflow lets your load test tool pull test files and target keys before a run starts. You set this up by giving your test runner read rights to a script store and target app. Teams often use a shared runner role to speed up this job. Broad roles create risk when a test script has too much power over live systems. How a native k6 pickup workflow operates In a standard setup, a build runner starts a load test job on a schedule. The runner uses a machine role to pull test scripts fr
Pickup: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A k6 pickup workflow lets your load test tool pull test files and target keys before a run starts. You set this up by giving your test runner read rights to a script store and target app. Teams often use a shared runner role to speed up this job. Broad roles create risk when a test script has too much power over live systems.
How a native k6 pickup workflow operates
In a standard setup, a build runner starts a load test job on a schedule. The runner uses a machine role to pull test scripts from a code store. Next, the job reads target host names and secret keys from a secret store. This step is the core of the k6 pickup process for most teams.
Once the runner has the files and keys, it starts the virtual users. Each virtual user sends web requests to the target app or database API. The runner collects timing logs and error counts during the entire test run. When the test ends, the runner sends those summary logs to a metrics store. The runner then stops the virtual machines and clears the local disk.
Where native test runner roles fall short
Native machine roles help your test runner log in to code and secret stores. They prove the identity of the build machine before the test starts. They also block outside users from reading your test scripts and host lists.
Still, native setup rules only check who logs in at the start. They do not inspect what each request or command does in flight. A shared test runner often holds wide write rights across staging or live apps. If a developer writes a bad script, the runner will execute destructive calls. Worse, engineers often need to log in to the runner box to check failed runs. Giving people direct shell access to that box exposes every key stored in memory. Logs from the test may also print sensitive customer emails or card numbers in plain text.
Pickup: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
How to secure test runs and runner shells
To reduce risk, split the role that pulls scripts from the role that hits the app. Give the test runner read-only rights to your code store. Use separate, narrow roles for each target app that the load test hits. Never reuse a live admin key for a basic load test job.
You also need tight controls when engineers inspect a broken test machine. Instead of sharing static machine keys, tie every debug login to an individual person. Record the commands they run while they fix the test script. Mask fields like phone numbers, emails, and national IDs in test logs and query results. Rewriting those matched fields in results stops raw user data from leaking into test dashboards.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What does k6 pickup mean in a load test pipeline?
It refers to how a test runner fetches test scripts, data files, and keys before generating load. A good setup pulls these items at run time instead of baking keys into machine images.
Why should teams avoid static keys for load test runners?
Static keys sit in build settings for months and are easy for engineers to copy. If a key leaks, anyone can send heavy traffic or read data from your backend systems.
How can we stop test logs from leaking customer data?
Use synthetic test data whenever you can during a load test. When tests touch real data stores, apply data masking to rewrite emails, card numbers, and phone numbers in flight.