Skip to main content
Project secrets are shared across everyone working on a project: team credentials, service accounts, and project-specific configuration. Use them for secrets the whole team needs but that should not be organization-wide. Project secrets have middle precedence. They override organization secrets but can be overridden by user secrets. Teams set project defaults while individuals can still customize.

​
Common uses

Project secrets are the right default for credentials tied to one repository or workflow. Typical examples:
  • API keys for services used by one codebase
  • shared test credentials
  • project-specific registry access
  • configuration values that should travel with the project rather than the whole organization

​
Manage project secrets

Navigate to Project → Secrets. Project secrets page showing list of shared secrets with type and name columns From here you can create, edit, and delete secrets. Each secret can be an environment variable, file, or container registry credential.

​
When to use project secrets

  • Shared service accounts: Database credentials, API keys for project-specific services
  • Project configuration: Environment-specific settings the whole team needs
  • Container registry access: Private images for this project’s Dev Container
For personal credentials like your own Linear or GitHub token, use user secrets instead.

​
How project secrets affect environments and automations

Project secrets are available to environments launched from that project, including automation runs that create environments from the project. That makes them the best place for shared defaults a project-backed workflow depends on. If the same secret also exists at organization scope, the project secret takes precedence for this project.