Secrets
Add and manage developer-facing secrets. Org-secret policy is referenced from Admin.
Secrets are env vars and files your agents need at runtime, like API keys or config files that shouldn't live in the repo. Proliferate stores them encrypted and materializes them into your cloud sandboxes. Local workspaces read your shell environment and checkout directly, so nothing here applies to them.
Secrets you add in Proliferate only reach cloud workspaces. If you work
locally, keep using your usual .env files, shell profile, or secret
manager.
Three scopes
Each scope is a separate page, and the effective set of variables for a cloud workspace is the union of all three: workspace overrides personal overrides organization when the same name is set in more than one place.
| Scope | Where | Applies to |
|---|---|---|
| Personal | Settings → User → Personal secrets | Your own cloud sandbox. |
| Organization | Settings → Org → Organization secrets | Every member's cloud sandbox. Admin-managed. |
| Workspace (repo) | Settings → Repo → Environment | Only this repository's cloud workspaces. |
Screenshot: Settings > User > Personal secrets
The Personal secrets page, showing the list of stored env vars and files with add, replace, and delete controls, and a materialization status indicator.
Env vars and files
Each scope holds two kinds of secret:
- Env vars. A name and a value, injected into the environment agents run in.
- Files. A path and content (typed directly or uploaded), written into the sandbox filesystem. Personal and organization file paths are absolute; workspace file paths are relative to the repo checkout.
Values are write-only once saved: the list view shows name or path, size, and last-updated time, never the stored value. To rotate a secret, replace it; to remove it, delete it.
Screenshot: Secret editor dialog, adding an env var
The add/edit dialog for a secret, showing the name field, a write-only value field, and the save action.
Materialization status
Each scope reports whether its secrets have been written into the sandbox yet: pending, running, ready, or error. If a secret shows an error status, re-saving it triggers another materialization attempt.
Organization secrets
Only organization admins can add, replace, or delete organization secrets; everyone in the org still sees the effective set of names available to them. See Admin: Organizations for role details.
Screenshot: Settings > Org > Organization secrets
The Organization secrets page as seen by an admin, with manage controls enabled, versus the read-only view a non-admin member sees.
Workspace (per-repo) secrets
Settings → Repo → Environment holds variables and files scoped to one repository's cloud workspaces, useful for repo-specific credentials you don't want available everywhere. Switch the Repo scope to Local and you'll see an explanation instead of controls: there is no local secret store, by design, since local workspaces already have your shell.