Secrets

Copia Actions supports secrets for sensitive information like API keys, tokens, and passwords.

Secrets

Secrets store sensitive information that should not be exposed in logs or workflow files. Common uses include API keys, database passwords, registry credentials, and access tokens.

Secrets are encrypted at rest and are masked in job logs — if a secret value appears in the log output, it is replaced with ***.

Creating Secrets

1

Organization level

Go to your organization on Copia, then Settings > Actions > Secrets. These secrets are available to all repositories in the organization. Your account must have Owner permissions in order to view or modify Org-level secrets.

2

Repository level

Go to your repository, then Settings > Actions > Secrets. These secrets are available only to workflows in that repository. Your account must have Admin permissions for the repository in order to view or modify repo-level Secrets.

Naming Rules

Secret names follow the same rules as variable names:

• Only alphanumeric characters and underscores. No spaces.

• Must not start with a number.

• Must not start with COPIA_, GITHUB_, GITEA_, or CI.

• Case-insensitive.

• Must be unique at the level where they are created.

Using Secrets in Workflows

workflow example

steps:
  - name: Deploy with API key
    run: ./deploy.sh
    env:
      API_KEY: ${{ secrets.DEPLOY_API_KEY }}

Security note: Never echo or print secrets directly in your workflow steps. While Copia masks known secret values in logs, derived values (such as substrings or encoded forms of a secret) may not be masked.

Precedence

If a secret with the same name exists at both the organization and repository level, the repository-level secret takes precedence.

Best Practices

• Use secrets for anything sensitive. API keys, tokens, passwords, and certificates should always be stored as secrets, not variables. Never hard-code sensitive values in workflow files.

• Use variables for environment-specific configuration. Values like deployment targets, feature flags, and non-sensitive URLs are good candidates for variables.

• Prefer repository-level scope when possible. This limits exposure and makes it clear which repositories depend on which configuration values.

• Rotate secrets regularly. If a secret may have been exposed (for example, through a misconfigured workflow step), replace it immediately.

• Name consistently. Use a clear naming convention like DEPLOY_API_KEY, STAGING_DB_URL, or REGISTRY_PASSWORD so that the purpose is obvious.