How Graphide CI works

Graphide CI gives you the verdict your CI gives today, sooner. Your workflows stay on GitHub Actions; the jobs run on Graphide’s runners, and each change runs the tests it can reach.

A failing test always fails the job, exactly as it would on your own CI. Graphide CI changes how long you wait, never whether a job passes.

Three parts

• Our runners. Jobs run on machines we operate, with dependencies and build caches already on the runner when the job starts, and the tests a change reaches split across as many runners as it takes.
• The blast radius. Graphide traces your code into a graph of what calls what, down to which test reaches which function, and each change runs the tests that can reach it. When it cannot tell, it runs more, never less. Which tests run, and why.
• Always-on agents. Our agents watch every run and keep tuning runners, caches, jobs and tests, all on our end. The always-on agents.

Moving a repository

1. Connect GitHub: start your Graphide org’s free trial and install the Graphide GitHub App on your GitHub organization. Graphide CI needs a GitHub organization; its runners do not take jobs from a personal GitHub account.

2. On your dashboard, press Switch to Graphide CI on the repository’s row, or ask your coding agent to switch it. Nothing moves until one of you does.

3. Graphide opens one pull request that changes each x64 Linux job’s runs-on line, and nothing else:

   runs-on: graphide

   and merges it. From the next push, those jobs run on Graphide’s runners. If GitHub holds the pull request back (a required review or check), it stays open: once it is approved, press Merge PR on the dashboard, or ask your agent to merge it. Jobs Graphide cannot run (macOS, Windows, Arm, or runners of your own) keep running where they do today, and the pull request lists them.

To move a repository back, open it on the dashboard (click its name), go to CI settings, press Switch back to GitHub Actions under Danger zone, and type the repository’s name to confirm. It gives up Graphide CI’s speed-ups and test verdicts on that repository. Graphide opens a pull request that puts each job’s runs-on back as it was before the switch, and merges it; until it merges, your jobs keep running on Graphide’s runners. While the switch’s own pull request is still open, press Close the pull request there instead: nothing has moved yet. Reverting the switch’s pull request on GitHub works too.

When a row says “Stays on your own CI”

The row says why, and what would change it. Rows you can act on come first in each organization’s list, and rows that stay come last.

The row says	Do this
Needs a GitHub organization	Move the repository to a free GitHub organization, connect it to your Graphide org, then press Switch.
No CI to move (it has no GitHub Actions workflows)	Nothing, unless you want CI there: add a workflow under .github/workflows with a Linux job (runs-on: ubuntu-latest), and Switch shows within a few minutes.
None of its jobs can move, with a count of jobs on self-hosted or third-party runners, or with a runs-on Graphide cannot rewrite	If such a job can run on x64 Linux, set its runs-on to ubuntu-latest on the default branch: the row is checked again within five minutes and Switch shows.
None of its jobs can move, with a count of jobs on macOS, Windows or Arm	Nothing: Graphide CI runs x64 Linux jobs, so those stay where they run today.
A workflow file does not parse	Fix the file on the default branch; the row is checked again within five minutes.
Its workflows have no job with a runs-on of its own	Its jobs call a reusable workflow, which decides where they run: switch the repository that holds that workflow.
Needs a GitHub setting (the Default runner group blocks public repositories)	GitHub’s Default group keeps public repositories off outside runners. Open the organization’s Settings › Actions › Runner groups, click Default, tick Allow public repositories, then Save. The box shows only once you are inside the group.
The App needs more permissions	An owner accepts the Graphide App’s permission request under the organization’s Settings › GitHub Apps, then presses Switch again.

A row that says Set to run on Graphide CI has jobs that already ask for runs-on: graphide: there is nothing to switch.

None of these is a lock: whether to change a workflow or a GitHub setting is your choice, and the row says which change would move the repository.

For coding agents

An agent asked to “get me on Graphide CI” does it through Graphide’s MCP server, https://mcp.graphide.com (Streamable HTTP, OAuth sign-in), with the person doing only what GitHub makes them do themselves.

1. Add the server and sign in. Claude Code: claude mcp add --scope user --transport http graphide https://mcp.graphide.com, then claude mcp login graphide. Codex: codex mcp add graphide --url https://mcp.graphide.com. Other agents: /setup.md.
2. Call ci_status. With no installations, the GitHub App is not installed yet: call review_setup, give the person its install link (GitHub has them click Install themselves), then call ci_status again.
3. For each repository, ci_status gives its state, and for one that cannot switch a message in words for the person:
   • can_switch: true: ask the person whether to switch it.
   • state: opened with no merged_at: its switch pull request waits on GitHub; ci_switch offers the merge.
   • state: left: tell the person the message.
4. Call ci_switch with the repository. It answers an ask: put it to the person, and only on their yes call again with its confirm. The answer’s next says what to do or tell them.

No step needs anyone at Graphide, and nothing in an answer is a lock to get around: if a step needs the person, the answer says which link to give them, and the choice is theirs.

On the runner

• GitHub hands each job the secrets it needs, as it does on its own runners. We use a secret only to run that job, on a machine that is deleted when the job ends.
• GitHub decides whether the job passed, from the job’s own steps, as it does on any runner.
• Treat build logs as you would on any CI: if your build prints a secret, the log holds it.

CI security says where your jobs run, how they are kept apart, and what Graphide keeps from them.

Against GitHub-hosted runners

	Graphide CI	GitHub-hosted
Runs only the tests a change can reach	Yes	No
Agents tuning your CI around the clock	Yes	No
Caches warm before the job starts	Yes	No
Tests split across runners for you	Yes	No
A failing test fails the job	Yes	Yes