Secrets and Variables

Use Actions secrets for credentials and other sensitive values. Use Actions variables for non-sensitive configuration that administrators may inspect later.

Repository credentials

Open a repository and go to Settings > Actions > Secrets or Settings > Actions > Variables. Repository credentials apply only to that repository and take precedence over organization credentials with the same name.

Repository credential names must:

• begin with an uppercase letter;
• contain only uppercase letters, digits, and underscores;
• be at most 256 characters;
• not begin with GITHUB_.

For example, use NPM_TOKEN, DEPLOY_ENV, or SIGNING_KEY.

Organization credentials

Organization administrators can create shared secrets and variables from the organization's Settings > Actions pages.

Organization access can be set to:

• All repositories; or
• Private repositories.

The dashboard currently displays Selected repositories, but creating a credential with that access mode is not supported. Choose all or private repositories.

Use values in a workflow

Reference values through their GitHub Actions-compatible contexts and map them into the environment only where needed:

jobs:
  publish:
    runs-on: ubuntu-latest
    env:
      DEPLOY_ENV: ${{ vars.DEPLOY_ENV }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm publish

Avoid placing secret values in workflow YAML, command arguments that will be printed, artifact names, or generated files that are uploaded.

Precedence

When the same name is available from several sources, Trylle applies this order from lowest to highest priority:

1. Organization credential.
2. Repository credential.
3. Runtime GITHUB_TOKEN for the reserved token name.

Repository variables and secrets retain their explicit type when they are passed to the runner.

Manage repository credentials from the CLI

List metadata without exposing secret values:

try actions variable list -R OWNER/NAME
try actions secret list -R OWNER/NAME

Set a non-sensitive variable directly:

try actions variable set DEPLOY_ENV production -R OWNER/NAME

Keep a secret value out of shell history by placing it in an existing environment variable and referring to that variable in the command:

try actions secret set NPM_TOKEN "$SECRET_VALUE" -R OWNER/NAME
unset SECRET_VALUE

Re-list the credential metadata after a change. Saved secret values remain hidden.

Organization credential limitations

For example, SIGNING_KEY and DEPLOY_TOKEN receive secret-context and log-masking treatment. A sensitive organization value named only SIGNING_CERT may be treated as a variable, while a non-sensitive organization variable named TOKEN_FORMAT may be treated as a secret.

Organization variables are injected into the runner, but they are not available during the earlier runner-selection phase. If runs-on depends on a variable, define that variable at repository scope:

jobs:
  build:
    runs-on: ${{ vars.RUNNER_LABEL }}
    steps:
      - run: uname -a

Runtime token and API URL

Each job receives a repository-bound GITHUB_TOKEN. Compatible tools should use it with GITHUB_API_URL or the github.api_url expression, both of which point to Trylle's GitHub-compatible API.

jobs:
  inspect:
    runs-on: ubuntu-latest
    steps:
      - run: >-
          curl --fail-with-body
          --header "Authorization: Bearer $TRYLLE_TOKEN"
          "$GITHUB_API_URL/repos/$GITHUB_REPOSITORY"
        env:
          TRYLLE_TOKEN: ${{ secrets.GITHUB_TOKEN }}

The runtime token overrides any organization or repository value of the same name.

Job bot permissions

A workflow job can select an installed Trylle bot using a static bot slug. The permissions block limits that bot's installed scopes for the job:

jobs:
  release:
    bot: release-bot
    permissions:
      contents: write
    runs-on: ubuntu-latest
    steps:
      - run: ./scripts/publish-release.sh

Bot selection cannot come from an expression or matrix. Jobs without bot act as the event actor, and permissions does not provide general GitHub-style least-privilege semantics for those jobs. See GitHub Actions compatibility.