Guides
Secrets
Encrypted project environment variables injected as ctx.env.
Dashboard Settings → Secrets (/projects/:id/settings?tab=secrets) stores name/value pairs encrypted at rest. Agents and scripts can manage the same secrets with robodev secrets, the Robodev MCP tools, or the REST API (below). Handlers and jobs read plaintext values from ctx.env.NAME. Projects whose handlers run in an isolated worker read secrets when the worker starts, so every set or delete — from the dashboard, robodev secrets, MCP or the REST API — restarts a running worker automatically in the background: about 5 seconds after the last change (a burst of changes is one restart, at most 30 seconds after the first), and the old worker keeps serving until the new one is healthy. While a deploy runs, the restart waits; a successful deploy already applies the current secrets. If the new worker fails to start, the secret stays saved, the previous worker keeps serving, the failed restart is listed on Deployments, and Settings → Secrets and Deployments → Live worker show Restart failed with View log and Retry, plus Changes not applied. Restart worker there, robodev restart and the restart_worker MCP tool remain for that retry. Projects that run handlers in-process read secrets on every request and need no restart. Names match ^[A-Z][A-Z0-9_]{0,63}$. Maximum 50 secrets per project. Values are write-only: they never appear in the list, an API or tool response, CLI output, deployment GET, logs, or the audit log.
From an agent, the CLI, or the API
- CLI: robodev secrets list, robodev secrets set NAME, robodev secrets delete NAME. set reads the value from --value-file <path>, piped stdin (echo "$KEY" | robodev secrets set KEY), or a hidden prompt; a value on the command line is refused because it ends up in shell history. See CLI reference (/docs/cli#secrets).
- MCP: robodev mcp and the hosted Robodev connector (https://robodev.povio.dev/mcp) have set_secret, list_secrets, delete_secret and restart_worker. Only set a secret with a value the human gave you, and never write values into code, files, commits or chat replies.
- REST: GET /v1/projects/:id/secrets (names and timestamps, plus autoRestart), PUT /v1/projects/:id/secrets with { name, value }, DELETE /v1/projects/:id/secrets/:name. PUT and DELETE answer restartScheduled: true when they armed the automatic worker restart; restartNeeded stays for older CLIs and is false whenever a restart was scheduled.
- autoRestart (on GET /v1/projects/:id/secrets and GET /v1/projects/:id/worker under .restart.autoRestart) is { state, scheduledFor, finishedAt, error }: state is idle, scheduled, restarting, succeeded or failed; error is { code, message, logId } after a failed restart, where logId is its row on Deployments.
- Who: any project member, or that project's deploy key (rdb_…). A key for another project gets 403. A deploy key can list names, set and delete secrets, but never read a value — still, a leaked deploy key can change or remove secrets, so revoke it on the Connect page if it leaks.
- No restart step: the CLI, MCP tools and API results say the running worker restarts automatically within a few seconds. --restart (CLI) and restart: true (MCP) are deprecated and still accepted, but no longer restart anything. robodev secrets list and list_secrets report a failed automatic restart; retry with robodev restart or restart_worker.
Audit log
Every set and delete — from the dashboard, the CLI, MCP, a deploy key or the raw API — writes a Secret set or Secret deleted row to the organization's Audit page with the secret name. A deploy-key change shows the key prefix (deploy key rdb_…) and no user; a change from the hosted MCP connector is marked MCP. The value, a hash of it, or its length are never logged.