Secrets Management

Overview

Secrets Management is a secure key-value store for environment variables, API keys, database connection strings, tokens, and any other sensitive configuration values your pipelines and services need. Values are masked by default in the UI — only the key name is visible until you click Reveal. Secrets are namespaced by environment (dev, staging, prod) so the same key name can hold different values per environment without duplication.

Adding Secrets

1. Navigate to Secrets Management in the DevOps sidebar.
2. Select the target environment from the environment tabs at the top (Development, Staging, Production).
3. Click + Add Secret.
4. Enter the Key name. Use UPPER_SNAKE_CASE by convention (e.g. DATABASE_URL, STRIPE_SECRET_KEY).
5. Enter the Value. The input is a password field by default — the value is not visible as you type.
6. Optionally enter a Description for the secret (visible in the key list — keep it informative but non-sensitive).
7. Click Save. The secret is stored and the value is immediately masked.

Environments

Secrets are organised into three environments that map to typical software deployment stages. Each environment is isolated — secrets in Production are not visible or accessible from the Development environment view.

Promoting a Secret Across Environments

Click the Copy to Environment option on a secret's context menu to create the same key in another environment. The value must be re-entered — values are never automatically copied to other environments to prevent accidentally promoting development credentials to production.

Injecting into Pipelines

Reference secrets from Secrets Management inside CI/CD Pipeline step commands and environment variable values using the interpolation syntax:

• In environment variable values: set the value to ${{secrets.DATABASE_URL}} — the pipeline runner substitutes the resolved secret value at runtime.
• In step commands: use ${{secrets.MY_KEY}} inside the command string (e.g. curl -H "Authorization: Bearer ${{secrets.API_TOKEN}}" https://api.example.com).

The resolved values are never written to log output — if a step command echoes a resolved secret, it is automatically redacted with *** in the step log.

Access Audit Log

Every access to a secret value — reveal, copy, or pipeline injection — is recorded in the Audit Log tab. Each entry shows:

• Timestamp
• User who accessed the secret
• Secret key name and environment
• Action type: Reveal, Copy, Pipeline Inject, Update Value, Delete
• Pipeline run ID (for injection events)

The audit log is read-only and cannot be edited or deleted. Entries are retained for 90 days. Export the log as CSV from the toolbar for external compliance reporting.

Best Practices

• Never hardcode secrets in pipeline step commands. Always use ${{secrets.KEY_NAME}} references so the raw value is not visible in the pipeline definition YAML or JSON.
• Rotate secrets regularly. Update the value in Secrets Management and all pipeline runs immediately use the new value — no pipeline edits required.
• Use separate credentials per environment. A compromised staging key should not grant access to production systems. Always use distinct accounts/keys per environment.
• Review the audit log monthly. Unexplained reveal or copy events may indicate unauthorized access to Secrets Management.
• Delete secrets you no longer use. Stale secrets that are never rotated and never deleted are a long-term security risk. Review and prune the secret list quarterly.
• Prefer short-lived tokens over long-lived API keys. Where the service supports OAuth tokens, prefer tokens with expiry over permanent API keys.

FAQ