Environments
Scoped sets of secrets that your apps load and your agents use through placeholders
An environment is a scoped set of credentials and config inside a project. Each project can have multiple environments, organized by deployment stage, service, or purpose.
Your apps load an environment's secrets at runtime, and your coding agents use them through agent profiles, without seeing the values.
Organizing environments
Stashbase does not enforce a fixed structure. Group secrets by deployment stage, service, or purpose, for example production, github, or database. In a monorepo, you can create environments for each service.
Access control
Workspace owners, admins, and the project creator can manage who has access to an environment. Grant access per environment or for all environments in a project, to individual users or to teams.
| Role | Secrets | Webhooks and sync | Environment accounts it can create |
|---|---|---|---|
| Viewer | View | No access | secrets.read |
| Editor | View and edit | Read-only | secrets.read, secrets.write, webhooks.read |
| Admin | View, edit, and delete | Full access | Any permission |
Environment accounts
An environment account gives an app access to one environment, for example a production server loading its secrets at startup. Each account has one API key, generated automatically, and can have an expiration date.
Create one in the dashboard under the environment's Accounts tab. Every account can read the environment. Add secrets.read, secrets.write, or other permissions as the app needs, up to what you have yourself.
Use the key with the SDKs to load secrets into your app. Do not give it to coding agents: run them with stashbase agent run instead. See environment account access for the full scope.