Skip to main content
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).
Build Secrets are in beta and rolled out per workspace. To request access, contact Qlty Support.

​
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.
Only project admins can view the list of secrets or add, change, and remove them.

​
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: 
[[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.
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.

​
Security

Pull requests from forks never receive project secrets, since the fork author controls the code the build runs.
Build Secrets are handled in line with Qlty’s overall security practices.