💥 Problem

Developers often store sensitive information, such as API keys and tokens, insecurely, using plaintext files or chat communications. This practice leads to poor control, lack of visibility, and no audit trail.

Additionally, as noted in Issue #7087, there is a need for a user-level secrets management system. While third-party solutions like HashiCorp Vault and AWS Secrets Manager offer powerful features, they can be complex due to the management of authentication. A native solution in Coder could simplify this process, balancing security and usability.

✅ Solution

Coder will support built-in secrets with 3 scopes:

• Account – personal secrets per user
• Template – shared with all workspaces from a template
• Organization – shared org-wide across all workspaces

Secrets can be:

• Set via CLI/API (coder secret set)
• Injected as environment variables AND/OR accessed at runtime via coder secret get
• Audited for reads/updates/deletes

🔧 CLI Examples

# Set a secret from the prompt
$ coder secret set MY_API_KEY

# Use in script
$ export OPENAI_KEY=$(coder secret get MY_API_KEY)

# List secrets
$ coder secret list

NAME              UPDATED
MY_API_KEY        2 days ago
VERCEL_TOKEN      10 days ago

🖥️ UI Sneak Peek

Secrets will also be configurable via the web UI (Account, Template, Org):

🔍 Auditing (Premium)

All secret usage (set, get, inject) will be logged with:

• User, Workspace, Timestamp, Secret Name

Example:

atif accessed SECRET_C in dev workspace at 09:00 UTC

💬 Feedback Wanted

1. Would automatic secret injection help your workflows, or would you prefer coder secret get and script it out?
2. Do you currently use Codespaces/Gitpod secrets—how’s that experience?
3. What would your preference be for overwriting secrets when a user, a template, and an organization have a secret with the same name? The current proposal is to follow the preference in order User > Template > Org.

Let us know what you think!