The CLI reads a small, fixed set of environment variables. Some of them are how a machine authenticates when there is no browser to log in with; the rest change behaviour or output and are useful when you are scripting. This page collects all of them, because otherwise each one is only mentioned on whichever command page happens to need it.
Machine credentials
These three exist so a CI runner, container or production host can read variables without an interactive login. See Production and CI for how they fit together.
| Variable | Purpose |
|---|---|
ENVLESS_TOKEN | The machine identity. Holds an ev_sk_ key created on the Keys page. Puts the CLI into machine mode, which reads through the public API. Authenticates the fetch and decrypts nothing. |
ENVLESS_KEY | The base64url raw AES-256 workspace key, exported from Settings, CI / Machine Access. Used locally and never sent. Prefer this on machines: it skips key derivation entirely. |
ENVLESS_PASSPHRASE | The workspace passphrase, as an alternative to ENVLESS_KEY. The CLI derives the key locally the same way it would interactively, which costs one PBKDF2 pass per run. |
ENVLESS_TOKEN on its own reads nothing. Machine mode aborts unless ENVLESS_KEY or ENVLESS_PASSPHRASE is also present, so a leaked token by itself does not decrypt a single value. Supply exactly one of the two decryption credentials.
Choosing a target
These stand in for a committed .envless file, and they lose to explicit flags. Resolution order for each is the flag first, then the environment variable, then the .envless file.
| Variable | Purpose |
|---|---|
ENVLESS_PRODUCT | Product slug. Only needed when the same project slug exists in more than one product. |
ENVLESS_PROJECT | Project slug or unique id. |
ENVLESS_ENV | Environment slug, or a comma-separated list. run and build merge a list into one process, later winning a name collision. sync writes one file per entry instead. |
These three names, along with the credentials above, are refused by envless push if they appear in a .env file you are importing. They boot envless itself rather than your app, so storing them as project variables would be circular.
Output and behaviour switches
| Variable | Effect |
|---|---|
NO_COLOR | Set to any value, including an empty string, and every command drops ANSI colour. Follows the no-color.org convention. |
FORCE_COLOR | Set to 0 to drop colour. Any other value is left to the terminal detection below. |
ENVLESS_NO_UPDATE_CHECK | Disables the background check for a newer CLI version on npm. Worth setting in CI, where the check is wasted work. |
ENVLESS_NO_INSECURE_CACHE_WARNING | Suppresses the warning printed when the on-disk cache directory has permissions looser than expected. Silence it only when you know why the permissions differ. |
ENVLESS_VERBOSE | Turns on verbose diagnostic output. Useful when a command fails and the message alone is not enough. |
Without either colour variable set, the CLI colours output when stdout or stderr is a TTY and stays plain otherwise, so piping into a file or a CI log already strips escape codes without any configuration.
The switches are read as boolean-ish: presence is what matters for NO_COLOR, while FORCE_COLOR is compared against the exact string 0. When in doubt, set them to 1 or leave them unset.
A CI block that sets everything
export ENVLESS_TOKEN=ev_sk_xxxxxxxxxxxx
export ENVLESS_KEY=xxxxxxxxxxxx
export ENVLESS_PROJECT=billing-api
export ENVLESS_ENV=production
export ENVLESS_NO_UPDATE_CHECK=1
export NO_COLOR=1
envless run -- npm startWith those set, no .envless file is required and no command prompts for anything, which is exactly what you want inside a container image or a pipeline step.
Going deeper
Where these variables get used in practice.