Docs › Features › Environments & secrets

Environments & secrets

An environment is a named set of variables you can activate per collection. Switch from dev to production and every {{baseUrl}}, {{token}}, and {{apiKey}} in your requests updates instantly without you touching a single file. Secret variables are masked in the UI and kept in a separate block in the file so you can choose what to commit to Git.

How environments are stored on disk

Each environment is a .tiger file inside an environments/ folder at the root of your collection directory. Opening a collection folder in Tiger surfaces every file in that subfolder automatically.

A minimal environment file looks like this:

meta {
  name: dev
}

vars {
  baseUrl: https://api.example.dev
  timeout: 5000
}

The meta block gives the environment its display name. The vars block holds plain key-value pairs, one per line. The file is plain text, so you can create or edit it in any editor, and diffs are clean and readable.

Creating an environment

There are two ways to create a new environment:

  1. From the UI. Open a collection, click the environment selector at the top of the sidebar (it shows "No environment" when none is active), then choose Manage environments. Click New environment, enter a name, and Tiger writes a new .tiger file into the environments/ folder of that collection.
  2. By hand. Create a file at environments/staging.tiger with a meta block and a vars block. Save it, and Tiger picks it up the next time the collection is in focus.
✓

Committing environment files that contain only non-secret, non-credential values (base URLs, feature flags, timeout durations) is encouraged. This lets every team member run the same named environments without manual setup.

Editing variables

Click the environment name in the Manage environments panel to open its editor. Each row has an enabled toggle, a name field, and a value field. The enabled toggle corresponds to the ~ prefix in the file: a disabled variable is preserved in the file but not interpolated at send time.

On disk, a disabled variable has a tilde prefix: 

vars {
  baseUrl: https://api.example.dev
  ~debugHeader: x-debug-on
}

debugHeader is stored but ignored until you re-enable it. This is useful for optional overrides you want versioned but not always active.

Switching the active environment

The environment selector appears at the top of the sidebar for each open collection. Click it to choose any environment defined in that collection's environments/ folder, or choose No environment to send requests without substituting any variables. Switching is instant and affects all requests in that collection.

Each collection remembers its own active environment independently. You can have my-api set to production and payments-api set to staging at the same time.

Secret variables

Any variable marked as secret is stored in a separate vars:secret block and displayed as masked dots in the UI. The value is never shown in plain text in the editor unless you explicitly reveal it.

File format for secrets

The serializer writes plain variables first, then secrets in their own block: 

meta {
  name: production
}

vars {
  baseUrl: https://api.example.com
  region: eu-west-1
}

vars:secret {
  token: eyJhbGciOiJIUzI1NiJ9...
  apiKey: sk-live-abc123
}

The two blocks are parsed and merged into a single variable set at runtime. The vars:secret block is what you add to .gitignore if you want the rest of the environment committed but credentials kept off the repository.

Gitignoring secrets without losing the file structure

Because plain variables and secret variables live in separate blocks in the same file, you have options:

!

Tiger does not automatically gitignore environment files that contain secrets. You are responsible for deciding what enters version control. Review your environments/ folder before the first commit on any collection that holds real credentials.

Marking a variable as secret in the UI

In the environment editor, each row has a lock icon on the right. Click it to toggle the secret flag. The variable moves into the vars:secret block the next time the file is saved.

Variable interpolation

Variables from the active environment are substituted with the {{name}} syntax everywhere a value appears: URL, query parameters, headers, request body, auth fields, and pre/post-request scripts. Interpolation happens at send time, so the raw {{variable}} tokens stay in the .tiger files on disk.

If you reference a variable that does not exist in the active environment, Tiger shows a yellow warning under the URL bar before you send. The request still goes out with the literal {{name}} string in place, which is useful for debugging but typically indicates a missing definition.

Beyond environment variables, Tiger also resolves a set of built-in dynamic variables that produce a fresh value on every send:

VariableValue
{{$uuid}}A random UUID v4
{{$timestamp}}Unix epoch in seconds
{{$isoTimestamp}}ISO 8601 datetime string
{{$randomInt}}A random integer between 0 and 1000

Response captures: writing back into the environment

A capture block in a request file reads a value from the response and writes it into the active environment, making it available to every subsequent request in that collection. This is the foundation of request chaining. 

capture {
  authToken: body.data.token
  userId: body.data.id
}

The right-hand side is a path: body refers to the parsed JSON response body, status is the HTTP status code, and headers.x-request-id reads a response header. After this request runs, {{authToken}} and {{userId}} are live in the active environment for the rest of the session. Captures do not modify the environment file on disk; they write to an in-memory overlay that is cleared when you switch environments or restart the app.

The cookie jar

Tiger maintains a persistent cookie jar per collection. When a response includes a Set-Cookie header, Tiger stores the cookie and attaches it to future requests that match its domain, path, and security constraints.

RFC 6265 compliance

The cookie store follows RFC 6265 rules precisely:

Viewing and clearing cookies

Open the collection settings tab to see the current cookie jar for that collection. Each entry shows the domain, path, name, value, and expiry. You can delete individual cookies or clear the entire jar. Clearing the jar does not affect environment variables.

i

Session cookies (no expiry) survive for the lifetime of the app process. They are kept in the in-memory jar alongside persistent cookies and are cleared when you quit Tiger or explicitly clear the jar.

Disabling the cookie jar

If you want to suppress automatic cookie handling for a collection - for example, because you are testing cookie-less flows or managing tokens manually - you can disable the jar in collection settings. When disabled, Tiger neither reads from nor writes to the cookie store for any request in that collection.

Environment file reference

A complete environment file showing all supported features:

meta {
  name: staging
}

vars {
  baseUrl: https://api.staging.example.com
  region: eu-west-1
  ~debugMode: true
}

vars:secret {
  token: eyJhbGciOiJIUzI1NiJ9.some.payload
  apiKey: sk-staging-xyz789
}

Related pages

Variables & interpolation
How {{variable}} tokens are resolved at send time, including precedence and dynamic built-ins.
Request chaining
Use capture blocks to pass values from one response into the next request.
The .tiger format
Full reference for the plain-text file format that makes collections git-native.
Built-in Git
Commit, branch, diff and push your collection from inside Tiger.