# Give computers secrets and variables

> Store values once in a workspace and pass them to computers by reference

> Nevia is in beta and open to selected teams. Public launch in Dec 2026. The CLI installs with `curl -fsSL https://get.nevia.cloud | sh`, and the MCP server is at https://api.nevia.cloud/mcp. A person signs in once in the browser.
> Setup, sign-in and requesting access: [SKILL.md](https://nevia.cloud/SKILL.md). When Nevia fits and when it doesn't: [why.md](https://nevia.cloud/why.md).

> For the complete documentation index, see [llms.txt](https://nevia.cloud/llms.txt). This page's HTML version: https://nevia.cloud/docs/workspaces/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](https://nevia.cloud/docs/workspaces/select.md) and the `editor`
role to write. Roles are in [Workspace permissions](https://nevia.cloud/docs/reference/workspace-permissions.md).

|                   | 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`.

## 1. Set and list a secret

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

```bash
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.

```bash
nevia secrets
nevia secrets DB_PASSWORD
```

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

## 2. Set and list a variable

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

```bash
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.

## 3. Import a `.env` file

```bash
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.

## 4. Use them in a computer

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

```bash
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`](https://nevia.cloud/docs/reference/cli/status.md).

The full `-e` grammar and limits are in [Computer environment
variables](https://nevia.cloud/docs/reference/computer-env.md). Flags are in [`nevia new`](https://nevia.cloud/docs/reference/cli/new.md)
and [`nevia exec`](https://nevia.cloud/docs/reference/cli/exec.md).

## 5. Rotate a secret

```bash
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.

## 6. Delete a secret or variable

```bash
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](https://nevia.cloud/docs/reference/computer-env.md#what-deleting-does).

Command options are in [`nevia secrets`](https://nevia.cloud/docs/reference/cli/secrets.md) and
[`nevia variables`](https://nevia.cloud/docs/reference/cli/variables.md).