Variables and secrets

Variables and secrets let you define reusable values once in codev and pass them into CI/CD workflows without hard-coding them in project files.

Use variables for non-sensitive configuration such as pool names, registry URLs, feature flags, or target branches. Use secrets for credentials such as tokens, API keys, or passwords.

How scoping works

Each value belongs to one of two scopes:

When a workflow runs for an environment, codev resolves the project values first, then applies the environment values on top. If the same key exists at both scopes, the environment value wins.

In the matrix:

• The Project column is the default for every environment.
• An environment cell with its own value is an override.
• An environment cell marked inherited uses the project value.
• A blank cell means no value is available at that scope.

Creating values

Open CI/CD > Variables and click Add variable.

Variable names must use uppercase letters, numbers, and underscores, and must start with a letter. Examples:

POOL_NAME
NPM_REGISTRY
NPM_TOKEN
API_ENDPOINT

New values are created at the project scope. After creating a row, click an environment cell to set an environment-specific override.

Turn on Secret when the value is sensitive. Secrets are encrypted at rest, shown as masked values in the UI, and never returned to the browser after they are saved.

Editing and removing values

Click any cell in the matrix to edit it.

• Editing the Project cell changes the default used by every environment that inherits it.
• Editing an environment cell creates or updates that environment's override.
• Remove override deletes only the environment value, so that environment falls back to the project value.
• Delete on the project cell removes the project value.
• The row delete action removes that key from the project and all environment overrides.

Managing values from the command line

The same store is available through the sfp server variable commands, so you can seed a new project or manage values from a pipeline instead of the app. Every command targets a repository — pass --repository owner/repo, or set the GITHUB_REPOSITORY environment variable when running inside CI.

# Set a project default
sfp server variable set --repository owner/repo --key POOL_NAME --value scratch_pool

# Override it for a single environment
sfp server variable set --repository owner/repo --key POOL_NAME --value dev_pool --environment dev

# Store a secret — pipe it from a file or another command so the
# plaintext never lands in your shell history
sfp server variable set --repository owner/repo --key NPM_TOKEN --secret < token.txt

# List a scope (secret values stay masked)
sfp server variable list --repository owner/repo
sfp server variable list --repository owner/repo --environment dev

# Read or delete a single value
sfp server variable get    --repository owner/repo --key POOL_NAME
sfp server variable delete --repository owner/repo --key POOL_NAME --environment dev

All commands accept --json for scripting and follow the standard sfp output conventions.

How workflows receive values

When codev starts a workflow, it resolves the variables and secrets for the repository and target environment. The resolved values are exposed to commands and scripts as environment variables.

The key is not renamed other than the prefix. A variable named POOL_NAME always becomes SFP_VAR_POOL_NAME; a secret named POOL_NAME becomes SFP_SECRET_POOL_NAME.

Bash script example

#!/usr/bin/env bash
set -euo pipefail

echo "Using pool: ${SFP_VAR_POOL_NAME}"

npm config set registry "${SFP_VAR_NPM_REGISTRY}"
npm config set //registry.npmjs.org/:_authToken "${SFP_SECRET_NPM_TOKEN}"

Node.js script example

const poolName = process.env.SFP_VAR_POOL_NAME
const token = process.env.SFP_SECRET_NPM_TOKEN

if (!poolName) throw new Error("POOL_NAME is not configured")
if (!token) throw new Error("NPM_TOKEN is not configured")

console.log(`Using pool ${poolName}`)

Using values in string replacements

Variables and secrets can also be referenced from supported string replacement values using GitHub-style tokens:

${{ vars.POOL_NAME }}
${{ secrets.NPM_TOKEN }}

Use this when a value needs to be inserted into metadata during build, validation, install, or deployment instead of read by a shell script.

For example, a package replacement file can keep the placeholder in source and resolve the environment-specific value at runtime:

replacements:
  - name: "API endpoint"
    pattern: "%%API_ENDPOINT%%"
    glob: "**/*.cls"
    environments:
      default: "${{ vars.API_ENDPOINT }}"
      prod: "${{ vars.PROD_API_ENDPOINT }}"

  - name: "API token"
    pattern: "%%API_TOKEN%%"
    glob: "**/*.cls"
    environments:
      default: "${{ secrets.API_TOKEN }}"

Use environment variables such as SFP_VAR_POOL_NAME inside scripts. Use ${{ vars.POOL_NAME }} and ${{ secrets.NPM_TOKEN }} inside supported string replacement values.

See sfp: String Replacements for the full replacement file format.

Security behavior

Troubleshooting