robodev

DocsSign in

Guides

Secrets

Encrypted project environment variables injected as ctx.env.

Getting startedOffline dev with robodev devConnect a frontendStartersDatabaseBackupsDomainsFile-based APIsAuthEmailPDFOrganizationsStorageSecretsPushJobsSocketsMCP toolsLLMAgentsDeployEnvironmentsArtifactsLocal developmentSelf-host a projectCLI referenceChangelog

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.

Per environment

Each environment has its own secrets: production's are the project's existing secrets, and staging's are separate. Settings → Secrets shows the environment selected in the top bar. From the CLI pass --env (robodev secrets set STRIPE_KEY --env staging, or ROBODEV_ENV=staging); MCP tools take an optional environment; the REST routes take the environment's own project id. Without an environment everything acts on production. A new environment created with Copy env vars from gets a one-time copy of that environment's secrets, never a live link, and values stay write-only. The 50-secret limit applies per environment. See Environments (/docs/environments).

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.

Error reporting

Set the secret SENTRY_DSN and unhandled API, job and worker errors are reported to any Sentry-compatible server, including GlitchTip. Optional secrets: SENTRY_ENVIRONMENT, SENTRY_RELEASE, and SENTRY_TRACES_SAMPLE_RATE. When SENTRY_TRACES_SAMPLE_RATE is a number greater than 0, each API call and job run is sampled as a transaction. GlitchTip's production recommendation is a low rate such as 0.01. Unset, 0, or an invalid rate sends no transactions. When SENTRY_DSN is unset, nothing is sent. Handlers can call ctx.sentry.captureException(error). The event does not include the body, cookies, auth headers, or secrets. SENTRY_AUTH_TOKEN, SENTRY_ORG and SENTRY_PROJECT (optional SENTRY_URL, default https://sentry.io) make a successful deploy create a release and record a deploy. That notification never fails the deploy.

api/config.ts

import { defineApi } from "@robodev-ai/sdk";

export const get = defineApi({
  handler: async ({ env }) => ({ hasKey: Boolean(env.API_KEY) }),
});