Secrets and environments
Performance tests need credentials: API tokens, service-account passwords, webhook signing keys. They often run against more than one environment too (staging, pre-prod, production). This page shows how to keep secrets out of test files and how to point one test at different environments safely.
Why not inline
Section titled “Why not inline”A token written into a test file:
- Is stored in your project (and in version control, if you upload from a repo).
- Appears in the run bundle, which every teammate with project access can download.
- Needs a test-file edit and re-upload to rotate, instead of a change to one value.
Project secrets fix all three. MaxoPerf stores the value encrypted, injects it at run time and redacts it from run output.
How project secrets work
Section titled “How project secrets work”- A project secret is a named, encrypted value stored at the project level.
- Each test binds the secrets it needs and maps each one to an environment-variable name.
- At run time, MaxoPerf injects those variables into the runner before your test starts.
- The runtime payload is short-lived and belongs to a single run.
Create and bind a secret
Section titled “Create and bind a secret”- Open the project that owns the test, switch to the Secrets tab and click New secret. Give it a clear name, like
checkout-api-token. - Paste the value. MaxoPerf encrypts it when you save.
- Open the test’s Dependencies tab and bind the secret. Pick it from the picker, then choose the environment-variable name the test expects.
Read the variable in your test files as usual:
- Taurus:
${__env(SECRET_CHECKOUT_API_TOKEN)} - k6:
__ENV.SECRET_CHECKOUT_API_TOKEN - JMeter:
${__BeanShell(System.getenv("SECRET_CHECKOUT_API_TOKEN"))}
Manage test secrets covers the full secrets workflow, including rotation.
Running the same test across environments
Section titled “Running the same test across environments”The pattern that keeps a token out of a test file also keeps environment-specific values out of it (base URLs, tenant IDs, feature-flag keys):
- Bind an environment-specific value, such as a staging or production base URL, the way you bind a secret. The test reads a named variable at run time instead of a value hardcoded into the scenario.
- Keep one test definition per scenario and change only the bound values per run. Don’t keep near-duplicate test files per environment. The request flow or user journey then lives in one place, and a change to the scenario doesn’t have to be copied into each environment’s file.
- Use one naming convention across environments (
checkout-api-token-staging,checkout-api-token-prod). You can then see which secret backs which run. This matters most when an AI agent picks the secret to bind.
What never happens
Section titled “What never happens”- Secret values are never written to result pages, run logs, or downloaded artifact bundles.
- Secret values are never available to teammates without project-level access.
- The runner never logs secret values. Only the names of injected variables appear in diagnostic output.
Where to go next
Section titled “Where to go next”- Manage test secrets: the full secrets UI walkthrough, including rotation.
- Get an API key: the MaxoPerf account credential, which you keep out of test files the same way.
- Connect AI tools: tell an agent to follow this pattern when it generates tests.