Manage secrets and variables

Store secrets and variables used by your workflows in Depot CI. You can limit availability of secrets and variables by repository, branch, workflow, and environment. You can also create variants of secrets and variables with different values depending on the availability you define.

Organization owners manage secrets and variables from the Depot CI settings in the dashboard or from the CLI.

How secrets are used in workflows

When a Depot CI job starts, secrets are decrypted on demand and dispatched to the sandbox in an isolated VM. The sandbox hydrates the environment with those secrets on a per-step basis as configured in your workflow YAML.

Within an organization, a secret scoped to a repository is available only to jobs running for that repository. When multiple secrets have the same name, Depot chooses the most specific matching variant for the job's repository, environment, branch, and workflow file. Secret values are masked in all log output.

For more information about secret encryption and access control, see Understanding security in Depot CI.

Import secrets and variables from GitHub

If you're migrating from GitHub Actions, you can import your existing GitHub secrets and variables into Depot CI with a single command:

depot ci migrate secrets-and-vars

By default, the command detects names in .github/workflows/ and .depot/workflows/. It skips secrets named GITHUB_TOKEN or DEPOT_TOKEN, and variables named DEPOT_TOKEN.

The command creates a local temporary branch with a one-shot workflow and prints a git push command. Push the branch within five minutes. The workflow imports the values into Depot CI and removes the temporary remote branch. See depot ci migrate secrets-and-vars in the CLI reference for details.

For Entire repositories, see Import secrets and variables from GitHub.

Manage secrets

You need to be an organization owner to manage secrets and variables. You can't view secret values after you create them. Variable values are plain text and visible in the dashboard and CLI output.

Use the dashboard to create secrets and variables and optionally limit availability by repository, branch, workflow, or environment. You can also add and remove secrets and variables using the Depot CLI.

Names must be non-empty and names matching to a specific repository can't contain a forward slash (/).

Add a secret

1. From the Depot CI workflows page, click the settings icon.
2. Click Secrets.
3. Click Create secret.
4. Enter a Name, optional Description, and Value for the secret.
5. Optional: Limit availability by defining when to use the secret. Learn more about limiting availability.
   1. Define a single attribute or any combination of repository, branch, workflow, and environment attributes.
   2. Enter a Variant name, or keep the auto-generated name.
6. Click Create secret.

Add a variable

1. From the Depot CI workflows page, click the settings icon.
2. Click Variables.
3. Click Create variable.
4. Enter a Name, optional Description, and Value for the variable.
5. Optional: Limit availability by defining when to use the variable. Learn more about limiting availability.
   1. Define a single attribute or any combination of repository, branch, workflow, and environment attributes.
   2. Enter a Variant name, or keep the auto-generated name.
6. Click Create variable.

Update secrets and variables

You can update a secret or variable's description, value, and availability from the dashboard.

You can't view secret values after you create a secret, so you can only enter a new value.

1. From the Depot CI workflows page, click the settings icon.
2. Click Secrets or Variables.
3. Find the secret or variable you want to edit.
4. Click the variant name or the details icon to open the details panel.
5. In the details panel, click the edit icon.
6. Update the fields and click Save changes.

Remove secrets and variables

1. From the Depot CI workflows page, click the settings icon.
2. Click Secrets or Variables.
3. Find the secret or variable you want to remove.
4. Click the variant name or the details icon to open the details panel.
5. In the details panel, click the trash icon and then click Delete to confirm.

Limit availability of secrets and variables

When you create or edit a secret or variable, you can limit its availability by defining the repository, branch, workflow, and environment to which it belongs. This is useful for security-sensitive credentials and configuration where you want to follow the principle of least privilege.

For example, a deployment key in an open source repository might be needed only by deployment workflows, production environments, or release branches. Limiting that secret to trusted contexts keeps it out of untrusted pull request jobs that could try to print secrets from a modified workflow.

Limit availability using one or more of the following attributes:

• Repository: Use when the repository matches (select from the available repos).
• Branch: Use when the branch name matches.
• Workflow: Use when the workflow file matches.
• Environment: Use when the job's GitHub environment name matches exactly. Provides compatibility with GitHub Environment Secrets.

Both branch and workflow attributes support glob patterns. For example, release/* or deploy-*.yaml.

Availability gets stricter when you add different kinds of attributes and broader when you add alternatives within the same kind of attribute. For example, a secret with the following attributes:

• Branch main
• Branch release/*
• Environment production

is accessible only when the branch matches main or release/* and the environment field in the workflow YAML matches production.

Using environment attributes

An environment attribute matches to the job's environment field in your workflow YAML. Use an environment attribute when a value should be available only to jobs that explicitly run in an environment such as staging or production.

For example, an environment attribute with the value production matches the deploy job in the following workflow snippet.

name: Deploy

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: depot-ubuntu-24.04
    environment: production
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/deploy.sh

You can also use the object form when you want to attach environment metadata:

jobs:
  deploy:
    runs-on: depot-ubuntu-24.04
    environment:
      name: production
      url: https://app.example.com

Depot uses the environment name for attribute matching.

Jobs without an environment field do not match environment attributes, even if they run on the same branch or in the same workflow file.

Secret and variable variants

Variants let one secret or variable name resolve to different values depending on the workflow availability you define (by repository, branch, workflow file, environment).

Use variants when the workflow should receive a different value depending on where it runs. For example, you can create:

• A default DATABASE_URL secret or variable for all repositories.
• A release DATABASE_URL secret or variable selected by a branch attribute match.
• A repository-specific DATABASE_URL secret or variable.
• A production DATABASE_URL secret or variable selected by an environment attribute match.

You can create, view, and manage all of these variants in the dashboard. You can also use filters to check which variant resolves for your workflow before running it.

Add a variant using the dashboard

1. From the Depot CI workflows page, click the settings icon.
2. Click Secrets or Variables.
3. Click the variant link or the details icon for the secret or variable you want to create a variant from. This opens the details panel.
4. In the details panel, click the plus icon.
5. Enter the new Value and optionally update the Description.
6. Under Limit availability, define a single attribute or any combination of repository, branch, workflow, and environment attributes.
7. Expand the Secret variants or Variable variants list to view all variants and any conflicts between them.
8. Click Create secret or Create variable.

How multiple variants resolve

Depot resolves matching variants before a workflow starts. A repository variant is invisible to all other repositories. Repository variants follow the repository, not its name. If you rename or transfer a GitHub repository, its secrets and variables keep applying, and a new repository created under the old name doesn't get them.

When multiple variants match a job, the variants resolve from least to most specific and with the following priority from highest to lowest: environment, repository, branch, workflow.

The following table summarizes how variants resolve:

Combining attribute types always increases specificity. A variant with both an environment and a repository attribute beats a variant with only one of them. So a variant with no repository attribute (matching any repo by default) and a defined environment attribute beats a variant with a repository attribute and no environment attribute. To resolve to a different value for a specific repo, create a variant that matches to both the repository and the environment.

Check variant resolution in the dashboard

Use Preview context to check which variant applies to a workflow run before running it.

1. From the Depot CI workflows page, click Secrets or Variables.
2. Click Preview context above the table.
3. Select Repository, Branch, Workflow, or Environment.
4. Search for a suggested value, or enter a custom value and press Enter.
5. Repeat for any other context values you want to specify.

The selected values appear as chips above the table. Click a chip to change its value, or click its × to remove it. Closing the picker keeps the selected context.

Expand a secret or variable to compare its variants. A matching variant that loses to a higher-priority variant remains visible with its name greyed out. Variants that conflict with the specified context are hidden. Click a row to view its availability rules and resolution explanation in the details pane. Specify more context when the available information cannot determine a winner.