> ## Documentation Index
> Fetch the complete documentation index at: https://docs.testorim.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Variables and secrets

> Where each kind of value belongs, and which of them are encrypted.

Testorim has three places to put a value, and they are not interchangeable.

<CardGroup cols={3}>
  <Card title="Variables" icon="braces">
    Plain project configuration. Substituted into steps as `{{token}}`. **Not
    encrypted.**
  </Card>

  <Card title="Environment headers and cookies" icon="lock">
    **Encrypted at rest.** Applied to the browser context, never substituted
    into a step, never shown to a model.
  </Card>

  <Card title="Mid-run prompts" icon="keyboard">
    Never stored at all. You type the value while the run waits.
  </Card>
</CardGroup>

## Variables

Project settings → **Variables**. Each one has a name and a kind: a fixed
value, or a generated one such as a random integer in a range.

Use them in an instruction as `{{name}}`:

```text theme={null}
Apply the coupon {{couponCode}} at checkout and check the total drops.
```

A variable resolves **once per run** and keeps that value for every step that
uses it.

The [built-in generators](/test-creation/test-data#built-in-generators),
`{{random.email}}`, `{{date.iso}}` and the rest, need no configuration.

<Warning>
  **Variables are not a secret store.** They are plain project configuration,
  readable by anyone who can read the project, and they are substituted into
  step values that end up in run records. Put a real secret in an environment
  cookie or header instead.
</Warning>

### What belongs in a variable

Good: a coupon code, a test account number, a search term, a SKU, a
non-sensitive feature-flag name.

Bad: an API token, a session cookie, a production password.

## Secrets

Real secrets go in [environment](/projects/environments) headers and cookies.
They are encrypted at rest with AES-256-GCM, applied directly to the browser
context, and never substituted into a step value, so they cannot leak into a
run record, a report, or a share link.

Project database connections are stored the same way.

## Credentials for signing in

Three options, best first:

1. **A login-setup test.** Sign in once as a saved test; the browser session is
   captured and encrypted onto the project, and later runs start signed in. The
   password lives in one test instead of every test.
2. **A session cookie in an environment.** Encrypted, and skips the login UI
   entirely.
3. **In the instruction, for a throwaway test account only.** The value is
   redacted before it is stored, but it was still typed into a chat box.

## Redaction

Anything typed into a field whose name suggests a secret (password, secret,
token, PIN, OTP, CVV, SSN) is stripped before the run is persisted, before the
report model sees it, and before a shared link renders. That covers the typed
value, the verification read-back, both sides of an assertion, and any error or
warning that quoted it.

Identifier-shaped names redact too: `userPassword` and `secretKey`, not just a
bare `Password`.

Link targets are masked where they appear in diagnostics, so an invite or
password-reset token inside an `href` cannot ride out in an error message.


## Related topics

- [Create a project](/getting-started/create-a-project.md)
- [Test data](/test-creation/test-data.md)
- [Writing tests in plain English](/test-creation/writing-tests.md)
- [Authentication and API keys](/developers/authentication.md)
- [Projects](/projects/projects.md)