Secrets

What this is

Secrets are encrypted key-value pairs stored per workspace. They let you inject credentials, tokens, and other sensitive strings into test runs without hard-coding values in test scripts. Once a secret is created, its value is never returned by any API or UI — only the secret name and metadata (version number, last-updated timestamp) are visible.

Secrets are workspace-scoped: each workspace has its own isolated vault. A secret in Workspace A is not visible to tests running in Workspace B.

Where to find it

Click Secrets in the left sidebar. When a workspace is selected in the top-bar scope switcher, the Secrets link navigates directly to that workspace’s vault at /workspaces/:workspaceId/secrets. When no workspace is selected, it navigates to the account-wide Secrets hub at /secrets, which shows a selector to 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 — no need to go through the hub first. 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 — incremented each time the value is rotated (updated). Useful for confirming a rotation landed.
• Last updated — the timestamp of the most recent create or rotate operation.

No secret value is ever displayed in the list. The vault is append-and-rotate only from the UI perspective: values go in, but 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 key 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 with a new one and bumps the version number. Tests that reference the secret by name automatically 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 without saving.

Zero-downtime rotation

Update the secret value in the vault first, then trigger a new run. Tests always use the current value at run start time. There is no need to update test configuration after a rotation — 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 the deleted secret by name will fail to start until you either recreate the secret with the same name or remove the binding from the test configuration. Rotate rather than delete when possible.

---

Referencing secrets in test runs

Secrets are injected into test runs as environment variables. You bind a secret to a specific environment variable name on the test’s configuration page — the runner injects the secret value into the process environment at run start.

Environment variable name must start with SECRET_

The bound environment-variable name is required to match ^SECRET_[A-Za-z0-9_]{1,120}$ — it must start with the literal prefix SECRET_, followed by 1-120 letters, digits, or underscores. Names without that prefix are rejected with a 422 error when you save the binding.

How to bind a secret to a test:

1. Open the test you want to configure in the Tests list.
2. Go to the Configuration tab of the test detail page.
3. In the environment variables section, add a variable named SECRET_<...> (e.g., SECRET_PAYMENT_API_KEY) and select the secret from the workspace vault by name.
4. Save the configuration.
5. Run the test. The runner injects the secret value as the named environment variable. The value is never logged or surfaced in run outputs.

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. This masking is best-effort — avoid deliberately printing secret values in test scripts.

---

Tips & gotchas

• Workspace scope is strict. A secret in one workspace cannot be referenced by a test in a different workspace, even within 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 by the API (bound env var names must match ^SECRET_[A-Za-z0-9_]{1,120}$); the rest of the name is conventionally uppercase SCREAMING_SNAKE_CASE.
• Versions help audit rotations. The version counter tells you how many times a secret has been rotated. Check it after a rotation to confirm the update landed.
• No bulk export. Secret values cannot be exported in bulk from the console. If you need a backup of your secrets, maintain them 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 complete secret binding workflow, including CI examples.
• Tests — create and configure — covers the Configuration tab where secrets are bound to environment variables.
• Workspaces — workspace management including member roles that govern secret access.
• Navigating the console — explains the workspace scope switcher and how it affects the Secrets sidebar link.