Variables & Environments
Load Test environments use the exact same model as the Flow Runner and Projects — three variable sources (Manual / OS Secret / Vault) stored on the enclosing spec group, with a single active environment selected per spec. If you already know Flow Variables, you already know this section; the only differences are where the environments are scoped and how the active selection is tracked.
Scoping
Environments live on the spec group, not on individual specs. Every spec inside a group sees the same environment list, and switching specs does not reset the active environment choice. The store maps each spec slug to its own active environment ID — so two specs in the same group can point at different environments simultaneously (e.g. one spec targets staging while another targets the preview deploy).
Opening the panel: the environment panel has two entry points — the Environments option on the spec group menu, and the Manage Environments link at the bottom of the environment dropdown in the action bar.
Three Variable Sources
Every variable you add has a source that determines where its value comes from. The same three sources that power Flow and Projects are available here, selected via the secret checkbox and a source dropdown on each row:
| Source | Stored where | When to use |
|---|---|---|
| Manual | Plain text in the spec group file — versionable, committable | Base URLs, feature flags, non-secret tunables that belong in git |
| OS Secret | OS keychain (macOS Keychain / Windows Credential Manager / libsecret) via the module: 'load' namespace | Per-machine secrets that never leave your laptop — local dev tokens, personal API keys |
| Vault | A team vault connection; resolved on demand via vaultConfig | Shared credentials the whole team needs — production tokens, staging keys, rotation-protected secrets |
Each row has an enabled toggle: disabled rows are skipped entirely during resolution, so you can keep old values around for reference without feeding them into a run.
Resolution Pipeline
When you press Start, Tigrister resolves the active environment in this order before any VU spawns:
- Find the active environment for the current spec slug — if no selection, there's nothing to resolve
- Vault session check — for every Vault-sourced variable, make sure the vault connection has an active session; if not, prompt the user to log in first
- Pre-resolve vault variables — pull every Vault value up front so VUs don't hit the vault during the hot path
- Resolve OS secrets — query the OS keychain for every
source='os'secret, in parallel - Merge — Manual values, resolved Vault values, and resolved OS Secret values are flattened into a single
Record<string, string>that every VU iteration reads from
Why pre-resolve? At high VU counts the runner performs thousands of variable lookups per second. Hitting the vault or the OS keychain on every lookup would be prohibitively slow and fragile. Pre-resolution happens once at Start time so the hot path stays pure in-memory.
Choosing the Active Environment
The environment dropdown in the action bar lists every environment defined on the current spec's group, plus a No Environment option at the top for running with only built-in variables. The selection is persisted per spec — leave a spec, come back to it, and the same environment is still active.
Switching environments is instant and does not require re-running any script — the next time you press Start, the newly selected environment is resolved and fed into Before All, every VU iteration, and After All.
Reading Variables from Scripts and Steps
Resolved variables are available everywhere the runtime is:
- •Step fields — URL, headers, body, params, vars all support
{{env.KEY}}templating that resolves to the merged map - •Lifecycle scripts —
tg.environment.get('KEY')reads values;tg.environment.set('KEY', val)writes them back and persists the change - •Flow variables —
tg.flow.set / tg.flow.getoperate on a separate per-run store that Before All typically seeds; every VU sees the same flow state
Same Model as Flow & Projects
The Load Test environment panel is literally a reuse of the shared EnvironmentPanel component that powers Flow Runner environments and Project environments — same UI, same row editor, same secret toggle, same vault config dialog. The only thing load-test-specific is the state adapter ( createLoadTestEnvState) that points the panel at the active folder instead of a flow group or project.
If you've already set up Flow variables or Project environments, refer to those guide sections for screenshots and edge cases — everything applies here verbatim.