Give computers secrets and variables

Store a value once in a workspace and give it to computers by name. The value stays out of your commands and shell history.

You need the CLI, a selected workspace and the editor role to write. Roles are in Workspace permissions.

	Secret	Variable	Literal `-e KEY=value`
Value shown again	Never	Yes, to every workspace viewer	No
Use it for	Anything sensitive	Plain configuration	One-off values

Put anything sensitive in a secret. Names start with a letter and use letters, digits or _. Secrets and variables share one per-workspace limit, and going past it fails with 409 limit_exceeded. Put -- before a name such as ls: nevia secrets -- ls.

Set and list a secret

A secret's value is write-only. No command returns it. Read the value from stdin or a file:

nevia secrets DB_PASSWORD --file -
nevia secrets API_TOKEN --file ./token.txt

Secrets have no --value flag, so values stay out of ps and shell history. At a terminal, --file - prompts for one hidden line.

Replacing a value asks for confirmation. -y or --yes skips the prompt.

nevia secrets
nevia secrets DB_PASSWORD

The first command lists secrets. The second shows metadata only.

Set and list a variable

A variable is plain text that every workspace viewer can read. Set it with --value or --file:

nevia variables LOG_LEVEL --value debug
nevia variables CONFIG --file ./config.txt
nevia variables
nevia variables LOG_LEVEL

--file - reads stdin. Replacing a variable asks for confirmation, as a secret does. The last command shows the value.

Import a `.env` file

nevia variables .env -f ./.env

Each entry becomes a variable. The file uses standard NAME=VALUE syntax with optional export , quotes and # comments. Values don't expand ${...}. The CLI validates the whole file before it writes anything. It warns about credential-like names such as API_TOKEN and asks before importing. It refuses a connection string with a password, so store that as a secret.

Use them in a computer

nevia new and nevia exec (including -i and -t) take -e with a reference to a secret or variable:

nevia new app \
  -e variables.LOG_LEVEL \
  -e 'POSTGRES_URI=postgres://app:{{secrets.DB_PASSWORD}}@db:5432/app'
nevia exec app -e secrets.API_TOKEN -- ./deploy.sh

-e secrets.NAME sets NAME from a secret. -e variables.NAME sets it from a variable. Use single quotes around templates so the shell leaves the braces alone. An unknown name fails the request. Check the result with nevia status.

The full -e grammar and limits are in Computer environment variables. Flags are in nevia new and nevia exec.

Rotate a secret

nevia secrets DB_PASSWORD --file -

Confirm the replacement. The next exec gets the new value. Running processes keep the old one. Editing a variable works the same way.

Interactive sessions

nevia exec -i and -t use the computer's stored env plus any -e overrides, as a one-shot exec does. Minting the session URL needs the editor role on the computer. If the merged env references a secret, you also need the editor role in the workspace; if it references only variables, any workspace role works.

The session URL is a bearer credential. If its env references a secret, the URL reaches every secret in the workspace, including ones created later, in sessions on that computer until it expires (default 1 hour, at most 12). You can't revoke a URL, and removing a member doesn't revoke URLs already issued. Treat the URL like a secret. A URL whose env has no secret reference reaches none.

A command in the session can print its env, so processes that use a secret can see its value.

Delete a secret or variable

nevia secrets unset DB_PASSWORD
nevia variables unset LOG_LEVEL

A computer that references a deleted entry fails its next exec. Recreate the entry under the same name, or detach it with nevia set CMP --unset-env NAME. Deleting doesn't revoke the credential, and running processes keep the value. Rotate it at its source. See what deleting does.

Command options are in nevia secrets and nevia variables.