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

This creates a one-shot GitHub Actions workflow that reads secrets and variables from your GitHub repository and imports them into Depot CI. See depot ci migrate secrets-and-vars in the CLI reference for details.

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.

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

You can use the filter to confirm which variant resolves to your workflow before running it. With no filters applied, the dashboard displays variants for each secret sorted from least specific to most specific.

1. From the Depot CI workflows page, click Secrets or Variables.

2. Click the filter icon beside the search bar.

3. In the filter context panel, select Env, Repo, Branch, or Workflow to view defined attributes for each across your organization.

4. Click the attributes that match the workflow you want to check to filter the workflow view.

   When a variant is the definitive winner for a specific secret or variable, it moves to the top of the list and the other variants are greyed out.