Secrets

Manage secrets and schedules.

What this is

Secrets are encrypted key-value pairs stored per workspace. Use them to inject credentials, tokens, and other sensitive strings into test runs without hard-coding values in test scripts. After you create a secret, no API or UI returns its value. You only see the secret name and metadata (version number, last-updated timestamp).

Secrets are workspace-scoped. Each workspace has its own isolated vault, so tests running in Workspace B cannot see a secret in Workspace A.

Where to find it

Click Secrets in the left sidebar. If a workspace is selected in the top-bar scope switcher, the Secrets link opens that workspace’s vault at /workspaces/:workspaceId/secrets. If no workspace is selected, it opens the account-wide Secrets hub at /secrets, where you pick a workspace vault.

Secrets hub: select a workspace to open its encrypted vault. Secrets are scoped per workspace.

Workspace scope switcher shortcut

With a workspace already selected in the top-bar scope switcher, clicking Secrets in the left nav takes you straight to that workspace’s vault. You skip the hub. See Navigating the console for details on the scope switcher.

---

Workspace vault

The workspace secrets vault lists every secret stored in the workspace. Each row shows:

• Name: the key you reference in your test environment configuration (e.g., STRIPE_SECRET).
• Version: goes up by one each time you rotate (update) the value. Check it to confirm a rotation landed.
• Last updated: the timestamp of the most recent create or rotate operation.

The list never displays a secret value. From the UI, the vault is append-and-rotate only: values go in and never come back out.

How to create a secret

1. Navigate to the workspace vault (via Secrets in the sidebar, or /workspaces/:workspaceId/secrets).
2. Click Create secret in the page header. A dialog opens.
3. Enter a Name for the secret. Use a descriptive uppercase name (e.g., PAYMENT_API_KEY, DATABASE_CREDENTIAL). Names must be unique within the workspace.
4. Enter the Value in the masked password field. The value is not stored in browser history or shown as plain text.
5. Click Save secret. The dialog closes and a toast confirms “Secret created (value stored encrypted; never shown again).”
6. The new secret appears in the vault list with version 1.

Value is write-only

After creation, the secret value cannot be retrieved through the console or API. If you lose the original value, use Rotate value to replace it with a new one.

How to rotate a secret value

Rotating a secret replaces its value and bumps the version number. Tests that reference the secret by name pick up the new value on their next run.

1. In the workspace vault list, find the secret you want to rotate.
2. Click Rotate value. An inline input field appears next to the secret row.
3. Enter the new value in the masked input.
4. Click Save. A toast confirms “Secret value rotated (version bumped).” The version number in the row increments.
5. Click Cancel at any point to discard your change.

Zero-downtime rotation

Update the secret value in the vault first, then trigger a new run. Tests always use the value that is current when the run starts. You don’t need to update test configuration after a rotation, because the name binding stays the same.

How to delete a secret

1. In the vault list, find the secret to delete.
2. Click Delete. A confirmation dialog appears: “Delete secret <name>? Tests lose bindings to it.”
3. Confirm the deletion. The secret is removed from the vault immediately.

Deletion breaks test bindings

Deleting a secret removes it permanently. Any test that references it by name fails to start until you recreate a secret with the same name or remove the binding from the test configuration. Rotate instead of deleting when you can.

---

Referencing secrets in test runs

Secrets are injected into test runs as environment variables. You bind a secret to an environment variable name on the test’s Dependencies tab. At run start, the runner injects the secret value into the process environment.

How to bind a secret to a test:

1. Open the test you want to configure in the Tests list.
2. Go to the Dependencies tab of the test detail page.
3. Pick the secret from the picker (grouped by kind, alongside virtual services, tunnels, and browser fleets), then type the name suffix the test expects. MaxoPerf always prefixes it with SECRET_: a suffix of PAYMENT_API_KEY injects SECRET_PAYMENT_API_KEY, and an empty suffix uses the secret’s own name, upper-cased.
4. Run the test. The runner injects the secret value as the named environment variable. The value is never logged or surfaced in run outputs.

Bound secret names always start with SECRET_

A bound environment-variable name must match ^SECRET_[A-Za-z0-9_]{1,120}$. The Dependencies tab adds the SECRET_ prefix for you; the API rejects a binding without it with a 422 error.

Secret values are masked in logs

MaxoPerf masks known secret values in run log output. If a secret value appears in your test script’s stdout, it is replaced with *** in the Logs tab of the run detail page. Masking is best-effort, so don’t print secret values in test scripts.

---

Tips & gotchas

• Workspace scope is strict. A test cannot reference a secret from a different workspace, even in the same account. Create the secret in each workspace that needs it.
• Names are case-sensitive. SECRET_DATABASE_CREDENTIAL and SECRET_database_credential are two different bindings. The SECRET_ prefix is required (bound names must match ^SECRET_[A-Za-z0-9_]{1,120}$); the Dependencies tab upper-cases the suffix, so the name is SCREAMING_SNAKE_CASE.
• Versions help audit rotations. The version counter shows how many times a secret has been rotated. Check it after a rotation to confirm the update landed.
• No bulk export. The console cannot export secret values in bulk. If you need a backup, keep your secrets in an external secrets manager and treat the MaxoPerf vault as a mirror.
• Workspace editor role required. Only members with workspace editor (or higher) permissions can create, rotate, or delete secrets. Viewers can see secret names but not values or the create/rotate/delete controls.

---

Related docs

• Manage test secrets: task-oriented how-to for the full secret binding workflow, including CI examples.
• Tests — create and configure: the Dependencies tab, where you bind secrets to environment variables.
• Workspaces: workspace management, including the member roles that control secret access.
• Navigating the console: the workspace scope switcher and how it changes the Secrets sidebar link.