Features
Run it before you push
The same engine that plans your CI runs on your laptop and inside your editor. Check a workflow as you type it, run the whole job locally, and make the first push the one that goes green.
The fourteen-commit afternoon
Everybody has had this afternoon. A one-line change to a workflow, pushed to find out whether it works.
It does not. You move a quote. Push. You indent a with:. Push. Somewhere around the eighth attempt the
commit messages stop being sentences — ci, ci again, fix ci, please — and the branch history is
a transcript of a conversation with a machine that would only answer once every ninety seconds.
The loop is slow for one reason: the only thing that could tell you the answer was somewhere else.
Now it is on your machine
apex validate reads your workflow with the same engine that plans your runs — not a lookalike, not
a JSON schema that drifted two releases ago — and points at the line and column.
$ apex validate
.github/workflows/ci.yml:24:9 error unknown context 'sercets' (jobs.test.steps[2].env.TOKEN)
.github/workflows/ci.yml:31:5 error 'max-paralell' is not a key of strategy (jobs.test.strategy)
2 diagnostics
Two seconds, no commit, no push, no waiting for a queue to tell you that you typed sercets.
And inside your editor, as you type
apex lsp is a language server. Point an editor at it and workflow files finally get what your code has
had for a decade: completion for contexts and expressions, hover on any ${{ }}, an outline of every job
and the steps inside it, and the error under the squiggle before you save.
-- Neovim
vim.lsp.start({ cmd = { 'apex', 'lsp' } })
VS Code and Helix are one line each — apex lsp --help prints all three. It needs no control plane, no
account and no network: the engine parses the buffer in front of you, on your machine, offline on a
plane if that is where you are.
Then run the whole job
apex run executes the job the way a runner does — the same containers, the same marketplace actions,
the same expression evaluation — against whichever event you want to pretend happened.
apex run --job test --event pull_request --secret NPM_TOKEN
Secrets are named, never carried, exactly as they are everywhere else on the platform:
you supply the value, the command supplies the rest. Pass --changed-file to see which path filters
would fire, --event workflow_dispatch --input version=1.2.0 to rehearse a dispatch, and --json when
you want the plan the engine made rather than the run it would make.
What actually changes
You stop pushing in order to find out. The workflow is right in the editor, proven on the laptop, and the first push is the one that goes green. It is the difference between debugging your CI and simply writing it — and it is the reason people who try Apex on a Friday afternoon do not switch back on Monday.
Same workflows. One subscription.
Every plan starts with a 10-day trial, without a card.