Migrating from GitHub-hosted runners

Before

Nothing has to change in a workflow for it to run on Apex. Two things are worth checking, and the second needs doing:

• Runner labels. runs-on: ubuntu-latest resolves to an Apex x64 runner sized as GitHub sizes it: 2 cores for a private repository, 4 for a public one. Pinned labels such as ubuntu-24.04 or ubuntu-22.04 are not recognised, and no Apex runner picks up a job that names one; use ubuntu-latest or an Apex size. [self-hosted, linux, arm64] resolves to an Apex arm64 runner. Sizes are listed in runner sizes.
• Secrets. Secret values have to be added to Apex. GitHub never gives a secret's value to an app, so Apex cannot read yours from GitHub. For each secret a workflow uses, open the repository in the Apex dashboard and add it under Secrets & variables. Workflows read it as secrets.NAME, exactly as before, and you can set them from the terminal as well, as secrets and variables describes. Set secrets on each repository: organisation-wide secrets are not yet available to customer organisations. secrets.GITHUB_TOKEN is provided for you. As on GitHub, it reaches only the job's own repository and follows permissions:, so a workflow that clones another private repository needs a token stored as a secret. It cannot read private npm packages from npm.pkg.github.com, so a workflow that installs them needs a token with read:packages stored as a secret. Non-secret values go under Variables and are read as vars.NAME.

During

Work through getting started — a plan, GitHub sign-in, the installation on the repositories you are moving, and the button that starts the trial. Installing the App is one of those steps rather than all of them: on its own it creates no account and runs nothing.

Leave GitHub-hosted runners enabled until you have seen the first Apex run on a pull request, then disable Actions on those repositories so each workflow runs once.

After

Checks and annotations continue to appear on the pull request, and the logs are on the run's page in the Apex dashboard. Each check run is named <workflow name> / <job name> — a reusable workflow's jobs <workflow name> / <calling job> / <called job> — so re-select any required status check in your branch protection rules. In addition, every run carries the verdict, the step timing and the flaky-test warnings described in your first run.

Rolling back

Uninstall the App and re-enable Actions. The next push runs on GitHub-hosted runners. No workflow file was changed, so there is nothing to revert.