Pull requests that open green.
Write your checks once, in .ryph/checks.yml. Agents run them as they work and fix what fails, in a pod they can’t touch. When the pull request opens, the suite that already passed reports to it, so it’s green from the start and nothing runs twice.1
- lint deno lint
- test deno task test
- e2e deno task e2e
- lint queued
- test not asked
- e2e not asked
- Postgres not needed yet
Ada has changed the refund page. It commits, and asks Ryph to run just lint, to catch the quick mistakes first.
Agents work until it’s green
Checks are part of how an agent works, not a gate it meets at the end. By the time you review, the failures it could fix are already fixed.
Run, read, fix, repeat
An agent commits, asks Ryph to run the checks, and gets back each failure with the last lines of its output. It fixes the cause and asks again until everything passes.2
Only what it’s working on
While it iterates, an agent can run just the checks its change touches. Only a run of every check reports to your forge.
No weakening the test
Agents are told to fix the code rather than skip or soften a failing test. A failure that has nothing to do with the change gets said out loud in the patch.
Every patch is checked
Checks start the moment an agent submits a patch, before anyone approves it, and the run waits for the verdict before it ends.
- Checks are on by default for the binary and Docker Compose; on Kubernetes, an operator turns them on. Only Kubernetes enforces their network limits. A repo declares up to 32 checks, each with a timeout of 15 minutes unless it sets its own, up to an operator-set maximum of an hour by default. Checks get no secrets. A deployment runs four check pods at once by default, or two for the binary on Docker, shared fairly between repos.
- Agents are instructed to fix the cause rather than weaken or skip a failing test; this is guidance to the model, not something Ryph can enforce, so the patch still goes to review. Submitting a patch is never refused on account of its checks: a patch with failing or unfinished checks shows as failing on its pull request. A run waits up to 75 minutes at a time for a verdict.
A verdict the agent can’t fudge
The checks that judge a change run where the change can’t reach them, from a file the change can’t edit.
setup: - run: npm cichecks: - name: lint run: npm run lint - name: test run: npm test timeout: 20m - name: e2e run: npm run e2e services: [postgres]A pod the agent never touched
Checks clone the exact commit into a fresh pod, on your repo’s environment image. It holds no credentials, and only gets the network access the run had.3
The base branch decides
Ryph reads .ryph/checks.yml from the branch a change is going into. A pull request can’t edit the test that judges it.
Exit codes, not claims
A check passes when its command exits cleanly, as the platform saw it. Nothing the container says about itself counts.
Real services
A check can name services from .ryph/services.yml and get its own Postgres or Redis, started after setup.
- The checks file is read at the base branch, so a change to it takes effect once it merges. The image is the repo’s newest environment build from the default branch, or the base branch’s own build where that differs, and the agent image when neither exists. Platform faults are retried twice before a check counts as errored. Log redaction matches credential-shaped text and can miss unusual secrets.
Nothing runs twice
A suite is known by what it checks: the commit, the checks file, the environment, and the network access it had. Ask for the same again, and you join the suite that already ran, even one that’s finished. That’s why the pull request is green the moment it opens.4
Native GitHub checks
Each check shows on the pull request as ryph / name, from the Ryph app. Require it in a ruleset like any other CI, and re-run it from GitHub.
GitLab statuses and Radicle job runs
On GitLab, each check is a commit status in the merge request’s pipeline. On Radicle, it’s a job run on the commit, signed by your node.
Every log, searchable
Each suite has a page in Ryph with every check’s full output, find in log and a button to run it again.
Shared fairly
Check pods run side by side, one container per check. Repos take turns when the deployment is busy.1
- A suite is reused when the commit, the checks file, the environment image, the network access and the services all match. A cancelled suite, or one that hit a platform error, runs again instead. Suites run on only some of the checks are for iterating and are never reported to the forge.
One CI for agents and people
Your team’s pull requests get the same checks as your agents’ patches, so .ryph/checks.yml can be your repo’s CI. And the coding agent in your own terminal can run them before you push.
$ git commit -m "Retry failed webhook deliveries"
You and your coding agent finish a change on your laptop, and commit it.
Every pull request
Every push to a pull request, merge request or Radicle patch is checked on its latest commit. A newer push cancels the run before it.5
Trusted authors only
Checks run when the author and whoever pushed can command agents. Code from people without access doesn’t run on your infrastructure.
Your own session
Pairing with a coding agent on your laptop? Have it ask Ryph to run the checks before you push, and fix what fails together.6
Any harness
Ask from Ryph’s CLI, or give any coding agent Ryph’s check tools over MCP.
- A pull request is checked when its author, and whoever pushed if that’s someone else, has write access; on GitLab, Developer or above; on Radicle, a delegate or someone on the allowlist. Only the patch author’s latest revision counts on Radicle. Pull requests from forks by people without access, and from bots like Dependabot, get no checks yet, so a required check stays expected. Merge queues aren’t supported yet. GitHub’s re-run buttons work for a single check and for all of them. GitLab has no re-run button for Ryph’s checks, so they re-run from Ryph.
- From your own session, you ask with your own Ryph account, through Ryph’s CLI or over MCP, on a commit you’ve pushed or uploaded. A suite you ran is reused only when the pull request’s commit, checks file, environment and network access match it.
More of Ryph
- Incident response An agent joins the incident chat, investigates and ships the fix.
- Automations Recipes that run on a schedule or when a webhook fires.
- Forges and chat Summon an agent with /ryph on an issue, a pull request or a merge request.
- Artifacts Reports and overviews agents publish as pages your team can open.
- Memory What agents learn, shared and kept current with the code.
- Security Keys stay behind gateways, and work leaves as a patch.
- Environments Images built for your repo, and services for every run.
- Deploy One binary on a laptop, or your own cloud.
Try it on your own machine.
One binary with the web app and database built in.
Get started