GitHub Get started

Your Open-Source Code Factory.

Everything between a request and a merged fix, on your own infrastructure: warm sandboxes, checks that run before anything leaves, and pull requests that arrive green.

Get started View on GitHub

Respond to incidents together

When an alert fires, an agent joins your team’s incident chat. It digs through your telemetry and code, reports what it finds, and ships the fix while you steer.

Payments on-call Telegram group with @ryph
IRM
Response
Responder
Chat
GitHub
MCP gateway
Telemetry
Response
None
Run
None
Patch
None yet
Alert
Quiet
  • Any IRM that can send a webhook1
  • Queries your metrics, logs and traces
  • Takes direction when you mention it
  • Ships fixes mid-incident
  • Takes on work from chat, too2
More on incident response
  1. The sender needs to support HMAC-SHA256 signing, Standard Webhooks signing or a shared secret header. Incident chat runs in a linked Telegram group, Zulip topic, Slack channel or Discord thread. Later alerts about the same alert group or incident join its open response; alerts without a key, and Telegram rooms, share one response per automation. The default rate limit is one alert per minute, and alerts over it are refused rather than joined. Resolved alerts are recognized from every built-in sender except Sentry issue alerts, which don’t send one.
  2. Command rooms are set up by an admin, with an hourly limit on new runs. In a public channel, agents can only be asked to work on public repos. Slack and Zulip rooms can limit commands to a user group, and Discord rooms to a role; in a Telegram group, everyone can command. Runs started from chat, a /ryph comment or an incident stay open for follow-ups until they go idle; runs started from the web app end when the agent does.

Automations for the work nobody (wants to) get to.

Give an agent a recipe and a trigger. It sweeps for stale docs every Monday, upgrades dependencies every night, and picks up failures from CI or Sentry the moment they happen.

Stale docs sweep Mondays at 9:00
Scheduled
Dependency upgrades Every night at 3:00
Scheduled
Flaky test fixer Webhook from CI
Listening
Error triage Webhook from Sentry
Listening
  • Cron schedules, in your timezone
  • Webhooks from your IRM, Sentry or CI
  • The same saved recipe on every fire3
  • Authenticated, rate-limited and on record
More on automations
  1. Payloads and chat messages cannot change a run’s granted permissions. They are framed as untrusted context for the model, which is a prompt-injection mitigation, not a guarantee that the model will ignore malicious instructions. Each fire uses the current recipe and agent blueprint.

Summon agents from your forge

Comment /ryph on an issue or pull request on GitHub or GitLab, or a Radicle issue or patch, to have an agent fix it, review it, or address the review.

acme/shop Issues and pull requests
Lee #88

Customers can't tell why a refund was issued. The order page shows the amount but not the reason.

GitHub acme/shop
Forge GitHub App
Ada waiting
Issue #88
Open
PR #91
None yet
Issue #85
Open
  • /ryph on any issue or pull request4
  • Reads the whole thread first
  • Pushes fixes onto the pull request5
  • Keeps up with the base branch
  • Labels, closes and reviews on request
  • Changes across several repos6
More on Forges and chat
  1. The commenter needs write access and a linked Ryph account, and in a workspace, write access to every repo in it. Commands from anyone else get no reply. On GitLab, write access means Developer or above. On Radicle, repo delegates or an admin-kept allowlist can command agents.
  2. The forge gateway makes the push, fast-forward only, after checking that the pull request is still open and its branch is neither the default branch nor on a fork. Pull requests from forks aren’t supported yet. Repos that require approval hold the push until someone approves it.
  3. Pull requests follow each repo’s submission policy. A run addressing an existing pull request updates that branch; other changed repos get their own pull requests. Related changes are counted without exposing private sibling repo names or links.

Agents that keep learning

Every run learns something, and every run after it starts with the best of it. Ryph folds what hundreds of runs propose into one shared memory, and keeps it current with your code.

Run 71
Run 72
Run 74
Inbox 3 proposals
  • Frontend tests run with vitest Run 71 promoted, retires jest
  • Use vitest for the web app's tests Run 72 same claim, confirms it
  • Always skip the e2e suite Run 74 instruction-shaped, held back
Agent memory
  • Frontend tests run with jest confirmed 14×
  • Frontend tests run with vitest confirmed 3× package.json at a1c3f09
Run 90 “how do I run the web tests?”
Run 95 checked it

Three runs on the web app propose what they learned, each in its own words. None of it touches the canon yet.

  • Every run adds to it7
  • Duplicates become votes
  • Contradictions get settled
  • Sets aside what the code moved past8
  • Learns from your runbooks and docs9
More on memory
  1. Semantic search uses a bundled embedding model, on by default in every deployment; rephrased duplicates and contradictions need a configured consolidation model. Without those, memory uses text search and exact deduplication. Even with a model, a rephrased duplicate is found only when it shares words with an existing memory. Admins can also create and edit the canon directly.
  2. Runs check the commit and file evidence of memories in their brief when they clone. This is a best-effort check, not a continuous watch of every memory. Evidence is optional, so a claim without it is never flagged. A flagged memory leaves briefs, so it is checked again only when a run finds it through search or a person reviews it. Confirmations restore trust. Pinned memories are never flagged, and neither they nor preferences decay like ordinary facts.
  3. Ingesting documents and the health page are for admins. Extracting claims from a document needs a consolidation model; without one, ingestion records a single pointer to it. Extracted claims go through consolidation like any proposal, so ordinary claims reach the canon without a person, and only preferences and instruction-shaped claims are held. Re-ingesting is manual; without a model, it retires every unpinned claim from the old version. URL sources must be public, and repo files are read from public GitHub and GitLab repos. Secret screening matches known credential patterns and can miss unusual ones.

Built for agents you can’t fully trust

Ryph assumes any agent can be manipulated, and limits what a manipulated one can do. Credentials stay behind gateways, and Git changes come back as patches.10

Model provider Anthropic, OpenAI or compatible
Model proxy real keys sealed here
Agent run-scoped keys only
MCP gateway allowlisted tools
Your tools Grafana, Linear, Sentry
Egress proxy run’s host allowlist
Allowed hosts package registries, more
Other hosts refused by the proxy
Forge gateway holds the GitHub App
Pull request opened by Ryph

The agent calls the model with a key that only works for this run.

  • No real credentials in the sandbox
  • Tools on an allowlist, per agent
  • Internet access on an allowlist11
  • Patches, never pushes12
  • Every tool call on record13
  • Finished work outlasts a forge outage14
More on security
  1. The credential and patch boundary shown here applies to every repo, including one on your own machine: runs clone through the forge gateway and get no Git credential.
  2. The proxy allows hostnames, not individual URLs, on ports 80 and 443. Kubernetes enforces the route with NetworkPolicy, and confined Docker with an internal network. Allowlisted Docker keeps a direct route. Deployments can explicitly select open internet access. The built-in web search and fetch tools don’t go through the proxy: fetch reads any public HTTPS page and returns it as untrusted text. An agent’s tool policy or a deployment setting can turn them off.
  3. Patch-only describes Git delivery through the forge gateway. Allowed tools can also post comments, change issues, send chat messages or fetch web pages, and allowed internet hosts remain reachable.
  4. Usage and tool-call recording are best effort. Transcripts stream through a bounded retry buffer; outages, rejected batches or overflow can leave gaps, which the emitter reports when it can.
  5. New clones still require a successful upstream refresh, and runs that already cloned need the forge to fetch, update from the base branch or use forge tools. Patch intake can avoid the forge while its base remains cached; a lost cache must be fetched again before acceptance. Retryable submissions back off for up to eight attempts, about an hour by default, then wait for a manual retry.

An environment that knows your repo

Runs start from an image baked for your repo, with dependencies installed and the build warm, and get their own databases and services.15

acme/web main
  • .nvmrc 22
  • .ryph/Dockerfile
  • .ryph/setup.yml
  • .ryph/services.yml
Environment build nothing to build
Universal image default
  • Machine Rust, Node, Python, Go…
  • Dependencies each run
  • Build cold
Run 7f3a installing Node 22
Run 91c2 working, own Postgres
Run b04e previous image

With no setup, a run starts on the universal image. The Node version acme/web pins in .nvmrc installs on first use.

  • A universal image for any stack
  • Your repo’s image, rebuilt as it changes
  • Branches bring their own image
  • An agent can set it up for you
  • Postgres, Redis and more for every run16
More on environments
  1. Environment builds are on by default for the binary and Docker Compose; on Kubernetes, an operator enables them. Without an environment image, pinned toolchains install on every run and need their download hosts on the internet allowlist. A .ryph/Dockerfile needs a glibc base with bash, git and ssh-keygen. The setup agent’s loop ends when the image builds, not when your checks pass. Machine sizes are fully applied on Kubernetes; Docker applies CPU and memory.
  2. Service containers must be enabled by the operator, which allows the whole catalogue; other images must match an operator-set allowlist. They need a connected repo. On Docker, a run’s services sit on a separate network but aren’t firewalled from other runs. Readiness currently checks TCP connectivity; a service such as MySQL may need an additional application-level check in repo setup.

On your laptop or in your cloud

Start with one binary on your own machine. When your team needs more, run it on Kubernetes or your own server.17

Your laptop

One binary, and three questions.

  • The web app and Postgres are built in.18
  • Runs in Docker.
  • Or run the multi-service deployment with Docker Compose, with smoke checks across the services.

Your cloud

The same platform, on the infrastructure you already run.

  • Kubernetes: a Helm chart for any cluster that enforces network policies, with a gVisor sandbox for every run where the cluster offers one.19
  • Any server with Docker: the binary, or the Compose deployment.
More on deploying Ryph
  1. The binary’s embedded Postgres can’t yet be migrated to a Kubernetes deployment, so moving means setting up agents and settings again.
  2. The binary includes the web app, embedded Postgres and local platform services. Git, a container runtime and agent images are separate prerequisites. The forge gateway for GitHub, GitLab and Radicle runs inside the binary. Setup asks three questions, with follow-up choices including internet access, and a fourth about mail when the instance is multi-user.
  3. The Helm chart needs Kubernetes 1.29 or later, and NetworkPolicy needs a network plugin that enforces it. The Helm chart needs your own Postgres and object storage; it brings them only for laptop clusters.

Also in Ryph

Agents as blueprints

Save an agent’s model, tools and instructions, and edit them any time. Every run keeps a snapshot of what it started with.

Any model endpoint

Use Anthropic and OpenAI, or register any OpenAI-compatible endpoint, hosted or self-hosted, with its models and prices.

Hosted MCP servers

Pick Grafana from the catalogue, paste a URL and a token, and Ryph runs the server for you.

Submission policies

Per repo, open pull requests from successful runs automatically, or hold patches until someone approves them.

Usage and cost

Model cost by agent, model, provider key and day, the most expensive tasks, and a live cost for every run. Figures are list-price estimates.

Kill switches

Archive a provider key or MCP server, and runs using it lose access on their next call. Rotate a credential in place without restarting anything.

Ryph is open source.

Read the code, run it on your own hardware, and change whatever you need.

View on GitHub