Migrating

Secrets and variables

Where a workflow's secrets and variables come from on Apex, how to add them from the dashboard or the terminal, and what the job's own token can and cannot reach.

A workflow reads secrets and variables exactly as it does on GitHub: ${{ secrets.NAME }} and ${{ vars.NAME }}. What changes is where the values live. GitHub never gives a secret's value to an app, so Apex cannot copy yours. Each secret a workflow uses is added to Apex once.

Where they live

Per repository. Add a secret or a variable to each repository that uses it. Organisation-wide secrets are not yet available to customer organisations.
Write-only. Once a secret is saved, nobody can read it back, you included. Its name is listed and its value is never shown. Replacing it means writing a new value.
Trusted runs only. A pull request from a fork receives no secrets, as on GitHub.

Non-secret settings go under Variables. Unlike secrets, variables can be read back, so never store a credential in one.

From the dashboard

Open the repository in the Apex dashboard and add each value under Secrets or Variables. Adding a secret needs admin rights on that repository on GitHub.

From the terminal

The apex CLI sets them too, which helps when one value belongs on many repositories:

apex login                                     # opens your browser to approve the CLI
apex secret set NPM_TOKEN --repo acme/web --repo acme/api < token.txt
apex secret list --repo acme/web               # names only
apex variable set NODE_VERSION --value 24 --repo acme/web

A secret's value is read from standard input, from --from-file, or from a prompt that does not echo. It is never accepted as a command-line argument. Arguments are visible to other processes and are saved in shell history.

There are two ways for the CLI to authenticate:

apex login for a person at a terminal. It opens the dashboard, you approve, and the CLI keeps a token in a file only you can read.
A token from Settings → API tokens for scripts and CI. Export it as APEX_TOKEN.

If APEX_TOKEN is set, the CLI uses it. Otherwise it uses the token apex login saved.

Either way the token reaches only repository secrets and variables, and on each repository it can do exactly what GitHub says you may do there. Every token expires, and revoking one on the dashboard takes effect immediately.

The job's own token

Every job receives secrets.GITHUB_TOKEN without anything being added. It is the Apex app's token for the repository's installation, so it can do what the app is permitted to do.

It cannot install private npm packages from npm.pkg.github.com. GitHub Packages refuses app tokens there. A workflow that installs private packages needs a token with read:packages, stored as a secret:

- uses: actions/setup-node@v4
  with:
    node-version: 24
    registry-url: https://npm.pkg.github.com
    scope: '@your-org'
- run: npm ci
  env:
    NODE_AUTH_TOKEN: ${{ secrets.PACKAGES_TOKEN }}