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

# Build Secrets

**Build Secrets** let you provide sensitive environment variables — such as an API token a linter plugin needs to reach a private package registry — to a project's cloud builds, without committing them to your repository. Each plugin must opt in to the secrets it needs (see [below](#making-a-secret-available-to-a-plugin)).

<Warning>
  Build Secrets are in **beta** and rolled out per workspace. To request access, [contact Qlty Support](https://qlty.sh/contact/support).
</Warning>

## Adding a secret

Open **Project Settings → Secrets**, choose **New Secret**, and enter a name and value.

* **Name** — uppercase letters, digits, and underscores only, and must not start with a digit (for example `NPM_TOKEN`). Names beginning with `QLTY_` are reserved. Up to 255 characters.
* **Value** — up to 16 KB. Multi-line values (such as a PEM-encoded key) are supported.

Secrets are **write-only**: once saved, a value is encrypted and can never be viewed again. To rotate a secret, enter a new value; to remove it, delete the secret. The list shows only names and timestamps.

<Note>
  Only project admins can view the list of secrets or add, change, and remove them.
</Note>

## Making a secret available to a plugin

Adding a secret makes it available to the build, but that alone does **not** expose it to your plugins. The Qlty CLI runs each plugin's installation and invocation in a subprocess with a restricted environment, and only passes through environment variables that the plugin definition explicitly whitelists. This keeps secrets out of plugin subprocesses that don't need them.

To expose a secret named `BAR` to a plugin named `foo`, add an `environment` entry to your `qlty.toml`:

```toml theme={"system"}
[[plugins.definitions.foo.environment]]
name = "BAR"
value = "${env.BAR}"
```

`${env.BAR}` reads the value from the build environment — the secret you defined above — and passes it to `foo`'s installation and invocation subprocesses as `BAR`. Without this entry, the plugin will not see the secret even though it is present in the build.

<Note>
  Secrets are available only while Qlty installs and runs your plugins (the tool installation and invocation phases). They are not exposed during other parts of the build, such as repository checkout.
</Note>

## Security

<Note>
  Pull requests from **forks** never receive project secrets, since the fork author controls the code the build runs.
</Note>

Build Secrets are handled in line with Qlty's overall [security practices](/cloud/security).