Environments & Variables

Environments are named sets of key-value variables scoped to a project. Switching the active environment changes the values injected into all probes and chains without modifying any probe configuration. This lets you reuse the same probes against different targets (e.g. dev, staging, prod).

Where environments live

Environments belong to a project — not a bundle. Open the project dashboard (click the project chip in the app bar, then Project Dashboard) to manage its environments. The environment editor is the main (left) panel of the dashboard; the linked bundles, probes, chains and scripts sit in the panel on the right.

The active project and its active environment are always visible in the app bar:

Creating an environment

In the project dashboard, type a name in the environment name input at the top of the editor (e.g. dev, staging) and click the + button. Each environment becomes a tab — click a tab to edit that environment.

Per-environment actions

With an environment tab selected, its actions appear in the action toolbar at the top of the app:

Action	Effect
Save	Persists the environment’s variables
Clone	Duplicates the environment as … (copy)
Rename	Renames the selected environment
Delete	Removes it (with a confirmation prompt)
Export	Downloads it as a standard environment file (<name>.environment.json)
Import	Adds an environment from a file (see below)

Variables take effect when you save

A variable is only used by probes, chains and scripts after the environment is saved. Until then it lives in the editor and nowhere else, so a probe with {{baseUrl}} in its URL would send the placeholder as written and fail.

The editor marks unsaved changes with a dot on the environment tab and a warning, and a send that still contains an unresolved placeholder now says so by name instead of reporting an invalid URL.

Adding variables

Add key-value pairs to the environment. Variable names are case-sensitive.

Key	Value
host	api.dev.example.com
token	dev-secret-token
email	test@example.com

Using variables in probes

Reference a variable anywhere a text field is supported using double curly braces:

https://{{host}}/api/users
Authorization: Bearer {{token}}

Supported fields per probe type:

Probe	Fields
HTTP	URL, body, headers, query parameters, cookies
SMTP	Host, each command’s data
IMAP	Host, each command’s data
LDAP	Host, DN, password, filter, attribute, value
DNS	Resolver host, query name
SpamAssassin	Host, message body

Switching environments

Click the environment chip in the app bar to open the environment picker for the active project. Click any environment to activate it in one step. To deactivate all environments, choose No environment at the top of the list.

The active environment per project is stored locally and persists across sessions — it is restored automatically the next time you open the app or switch back to that project.

The active environment is stored locally and does not affect other users.

Variable priority

If a probe defines its own inline variables with the same name as an environment variable, the probe’s inline variable wins.

Credential bindings

Environments can bind credentials the same way they hold variables. A credential binding maps a name to one of your stored credentials; a probe references that name in its Auth, and switching the active environment swaps the whole credential (scheme, configuration and secrets) without editing the probe.

This is the classic prod-vs-staging case: staging authenticates with a different token endpoint and client secret than production, sometimes even a different scheme. Instead of two probes, you keep one and let the environment decide.

To set it up:

1. In the Project Dashboard, select an environment and open the Credential bindings card below the variables.
2. Add a binding: give it a name (for example authCred) and pick the credential to use in this environment.
3. Repeat for your other environments, reusing the same binding name.
4. In an HTTP probe’s Auth picker, choose the binding under Environment bindings (it is stored as {{authCred}}).

Now switching the environment chip swaps the credential the probe resolves to. The effective-credential summary under the Auth picker shows an env binding source and which concrete credential it currently points at. Bindings resolve for a direct send, in chains and in scripts.

If a binding is not defined in the active environment, a direct send falls back to the project’s default credential and a chain step fails with a clear message naming the missing binding. Credential bindings work for every probe that uses the credential store: HTTP, SMTP, IMAP, LDAP, MySQL and MongoDB.

Importing & exporting environments

Use Export (in the action toolbar with an environment selected) to download the environment as a standard environment file. The file uses the common environment schema, so it imports into other request tools as well as back into VirtuProbe.

Use Import to add an environment from a file. Supported formats:

• A standard environment export (.json)
• A dotenv file (.env) — KEY=value lines
• A Bruno environment file

The imported environment is created in the active project and selected automatically.

Comparing environments

Once a project has two or more environments, the Compare environments action in the toolbar opens a side-by-side diff. Pick two environments and VirtuProbe shows, for both variables and credential bindings, which entries exist only on one side, which differ, and which match (identical rows are hidden until you ask for them).

From the diff you can copy an entry either direction, or copy every missing entry at once. That is a quick way to bring a new environment up to date with an existing one, or to reconcile two that have drifted apart. Copies are held until you choose Save changes, which writes both environments.

Environments in chains

Chains resolve variables server-side at execution time using the active project’s environment. Variables produced by extractors in earlier steps take precedence over environment variables of the same name.