Features
Jobs start in seconds
A push produces a running job in seconds, not a queue position. Capacity follows your queue, so a busy afternoon is not a slow one.
Time to first job
The slowest part of most CI runs is not the tests. It is the wait before anything starts: the queue position, the runner that has to be provisioned, the image that has to be pulled. Apex Actions keeps capacity ahead of your queue, so a push turns into a running job in seconds — on a Monday morning and at the end of a release day alike.
Bigger machines when you want them
A larger runner is a label, not an add-on. Change one line in a job — runs-on: pristine-4core — and it
runs on a machine with more cores and more memory. That is included in every plan, and there is no
per-minute surcharge for the bigger size.
jobs:
test:
runs-on: pristine-4core # the only line that changed
steps:
- uses: actions/checkout@v4
- run: pnpm test
The parts of a run that are slow are named
Every step in every job carries a timing, and each run is compared against its own history for that workflow and that matrix leg. When a step is slower than it usually is, the run says so — you do not read a log looking for the gap.
Same workflows. Half the bill.
Every plan starts with a 10-day trial, without a card.