Features
Your workflows, unchanged
The same YAML, the same actions, a check run on the pull request for every job. A conformance suite matches Apex Actions against GitHub’s documented behaviour, feature by feature.
Drop-in means drop-in
Install the GitHub App on an organisation or account, add your secrets to Apex, and turn off GitHub Actions on the repositories you move. The workflow files stay as they are — the triggers, the matrices, the reusable workflows, the expressions, the marketplace actions, the caches and the artifacts.
How much of it is covered
The conformance suite enumerates 44 features of GitHub Actions workflow syntax and expression language. 35 run the same way here. The other 9 are listed below, all of them: this page is generated from the same file the suite proves, so it cannot quietly become a list of the good news.
| Verdict | Features |
|---|---|
| Supported | 35 |
| Partial | 7 |
| Not supported | 2 |
Where it stops
Every row of the matrix that is not plainly supported, in full:
| Feature | Runs on Apex | Why |
|---|---|---|
Other webhook events (issues, release, create, …) | With a limit | The engine matches any event name and its activity types generically, so planning is correct. The control plane only ingests push, pull_request, workflow_dispatch, workflow_run and repository_dispatch today; the App does not subscribe to the rest, so they never arrive. |
permissions — read-all, write-all, per-scope mapping | With a limit | Resolved as on GitHub: a mapping is total, and a scope it does not name is none. It narrows GITHUB_TOKEN, which is minted per job for its own repository, and gates the OIDC token. The token can carry only what the Apex App holds: issues, statuses and deployments are not among them. |
permissions at job level | With a limit | Replaces the workflow's set outright; the two are never merged. Enforced as the workflow-level row says. |
Cross-run download-artifact inside a workflow | No | It does not use the artifact protocol at all, but the public GitHub REST API through octokit. Serving it needs a GitHub-API-shaped surface; apex artifact download covers the scriptable case. Tracked in the backlog. |
GitHub Packages (npm.pkg.github.com, ghcr.io) with the job's own GITHUB_TOKEN | No | GitHub Packages accepts a personal access token (classic) or GitHub Actions' own GITHUB_TOKEN, and nothing else. On Apex a job's GITHUB_TOKEN is a GitHub App installation token, and the registry refuses it for publishing and for installing, whatever permissions: packages asks for. Create a personal access token (classic) with write:packages to publish or read:packages to install, store it as a secret, and pass that instead, e.g. NODE_AUTH_TOKEN: ${{ secrets.PACKAGES_TOKEN }}. |
concurrency: and schedule: in local mode (apex run) | With a limit | A local run is one run with nothing to wait for: concurrency: groups are accepted and have no effect, and a schedule: trigger never fires on its own — apex run runs the workflow once, as a schedule would. |
actions/cache and artifacts in local mode (apex run) | With a limit | A local run serves both protocols itself: upload-artifact and download-artifact within the run, written to .apex/artifacts/, and actions/cache kept across runs in .apex/cache/ (10 GiB, least recently used first). Proved with the stock actions on Docker Desktop and on a native Linux Docker engine; rootless Docker is not yet proven. One cache scope per checkout, whatever the branch. |
| Environments — required reviewers, wait timers, branch and tag policies, deployment records | With a limit | Enforced by the control plane and exercised by its own tests rather than a plan golden, but set only through its API, which customer tokens cannot reach. GitHub's own environment rules are not read. A required reviewer is a GitHub user or an Apex Account role, never a GitHub team, and must also hold the role's deployments:write. |
github.actor, github.triggering_actor — who started or re-ran a run | With a limit | The person's own GitHub login, as on GitHub. What it no longer implies is write access to the repository: on GitHub whoever dispatches or re-runs holds write, and on Apex they hold the Account role that grants actions:write, which an Owner may give to someone with only read on GitHub. A workflow that treats the actor as "someone who can push here" — to skip a check, or to decide whether to publish — should check the permission itself. Deliberate (Apex decides access, not GitHub). |
How we know
Every row in the compatibility matrix names its conformance fixture or says none yet. A fixture runs a workflow and compares the result with GitHub’s documented behaviour, and a change to how Apex runs a workflow lands only with a fixture showing it still matches. A row with no fixture behind it is marked as such rather than counted as proof.
apex migrate scan answers the same question about your own repositories, before you move anything: what
runs, what runs with a limit, what does not — and, for every verdict, the fixture it comes from. The apex
CLI is on npm as @apex-actions/cli.
Same workflows. One subscription.
Every plan starts with a 10-day trial, without a card.