Homepage · Docs · Getting started

Note

Ryph is under active and heavy development. Breaking changes are possible before v1; see Releases & versioning.

Ryph is a complete, batteries-included agent orchestrator for teams that's easy to deploy and put into action straight away.

Deploy an incident response bot

An alert fires on your IRM, and an automation within Ryph immediately spins up a secure sandbox for your responder bot within your infra. The sandbox ships with a warm build cache and dependencies pre-installed, so your bot can get to work right away.

The bot starts reading telemetry directly from your observability stack, securely through the Tool Proxy, and diagnoses the problem. It remembers details from past incidents that help it pinpoint the root cause.

It joins your teams existing incident chat, and reports what it finds. People in this chat can mention it to ask follow-up questions or steer it.

Once the root cause is clear, the bot builds a fix, runs your repo's checks, submits a hotfix pull request that opens with all CI checks already green, and sends the link to your chat. Ryph's forge safeguards prevent the bot from accidentally making a bad push, or even sidestepping a code review.

An engineer reviews the hotfix, merges and deploys. The bot is automatically notified of the PR being merged, and starts watching telemetry for the deploy landing.

Eventually, the alert resolves, the bot reports all green, and closes out.

Give your teammates a secure helper bot that can reason from code, and ship fixes

With the Chat integration, allow your teammates to ask a self-hosted agent right from where your team already communicates - Slack, Discord, Telegram, or Zulip. For each new agent run, Ryph provisions a secure sandbox, with dependencies already pre-installed.

The bot gets specific repos checked out, can reason from their code, and answer questions. If you want, give it access to specific tables and fields from your database through the Tool Proxy, so it can perform data analysis for non-technical teammates. For long-form reports, the bot creates an Artifact and posts the link back in the chat - all self-hosted on your own infra.

When asked to fix a visual glitch in the frontend, the bot can be steered by screenshots people post in the chat. It goes to fix the glitch, verifies it in its in-sandbox browser, ships a fix PR for an engineer to review, and reports back in the chat with a screenshot of the fixed UI. Ryph's forge safeguards prevent the bot from accidentally making a bad push, or even sidestepping a code review.

---

Ryph is the self-hosted platform that does all this and more: coding agents that run in secure containers, started by an alert, a task in the UI, a /ryph comment on a pull request, a mention in chat or a schedule, whose work leaves as a pull request, with every step on record.

Deploy it

Ryph ships as a single binary for trying it out on your laptop, in Docker Compose for teams, or as a Helm Chart for teams that require autoscaling with Kubernetes.

For smaller teams and sporadic agent use, Docker Compose is the quickest way to get started.

For heavier use, especially when also using Ryph Checks, the Kubernetes deployment mode unlocks automatic resource scaling. New agent sandboxes and check pods are placed within your cluster by k8s, and in combination with autoscaling solutions such as GKE Autopilot, the cluster automatically provisions and removes nodes according to short-term resource needs.

Read more about deployment options in our docs

Get started

• With your coding agent. Tell Claude Code, Codex or Cursor: read https://raw.githubusercontent.com/ryph-hq/ryph/main/docs/guides/setup-with-an-agent.md and set me up. It installs the binary, answers the setup questions with you, starts it, and hands you the two steps only you can do.
• By hand. docs/guides/quickstart.md: install, setup, first run, first automation.
• For a team. deploy/README.md compares the binary, Compose and the Helm chart, and says which to pick.

A response, end to end

ryph calls a handled alert a response: a run that stays open, bound to one conversation, while later alerts about the same thing join it as messages.

sequenceDiagram
    participant S as Alert source
    participant A as Automation
    participant R as Run (container)
    participant C as Incident chat
    participant E as Engineers
    participant F as Forge

    S->>A: alert webhook (signed)
    Note over A: verify · read status and key<br/>open a response, or join the open one
    A->>R: start the run: recipe + alert as untrusted data
    A->>C: opening line: the alert, the agent, the run link
    R->>C: findings, as the agent works
    E->>C: "@bot check the connection pool first"
    C->>R: the message lands in the run's inbox
    R->>F: patch (git bundle) → branch → pull request
    F-->>C: PR link, once it is open
    S->>A: resolved
    A->>R: joins the response as a message
    R->>C: closing line: outcome, pull requests, run link

Loading

• Automations take the webhook, verify it, and read what it says: Grafana, Alertmanager, Grafana IRM, PagerDuty, Sentry, incident.io, Datadog, Opsgenie, or your own mapping (@ryph/automations).
• Chat is where the response lives: a Slack thread, a Zulip topic or a Telegram group, and the people in it steer the run by mentioning the bot (@ryph/chat).
• The run is one container with one agent, holding only credentials minted for it; it reaches models and tools through ryph's proxies and never sees a real key (@ryph/runner, @ryph/model-proxy, @ryph/mcp-gateway).
• Memory gives it the runbooks and gotchas earlier runs left behind (@ryph/memory).
• The forge turns a patch into a branch and a pull request, after a person approves it in ryph or at once where a repo allows that (@ryph/forge).
• The guide tells the whole story on one stack and gives the checklist for yours: docs/guides/incident-response.md.

Fit it to your team

Alerting	Grafana, Alertmanager, Grafana IRM, PagerDuty, Sentry, incident.io, Datadog, Opsgenie, or a custom mapping
Chat	Slack, Zulip, Telegram
Forge	GitHub (as you, or as an App), GitLab, Radicle, or a directory on this machine
Models	Anthropic, OpenAI, a ChatGPT plan, or any OpenAI-compatible endpoint
Tools for agents	any MCP server, hosted by ryph or remote; Grafana, Sentry, Datadog and PagerDuty are in the catalogue

The checklist that walks a team through its own combination, with a coding agent doing the parts it can: fit it into your operational context.

What else it does

• Tasks from the UI, on one repo or a workspace of several.
• /ryph on a pull request, merge request or issue starts a run on it (forge).
• A mention in chat starts a run in that thread.
• Schedules: a cron expression as a trigger, same recipe.
• Previews of a run's dev server in your browser (previews).
• Checks a repo declares in .ryph/checks.yml, run on ryph and reported to the forge (checks).
• Skills and MCP servers for agents, with a policy per agent (skills, mcp-gateway).
• ryph mcp: the deployment as MCP tools for the agent on your machine (the binary's README).

How it works

docs/system-flow.md has the cast of players, the happy path in one picture, and the walk through every step with the doc that owns it. The workspace, one package per role:

Package	Role
packages/ryph	@ryph/cli, the shipped ryph binary: one process, embedded Postgres, the UI inside
packages/host	@ryph/host, the single-process composition root the binary hands off to
packages/orchestrator	@ryph/orchestrator, the control plane: agents, tasks, runs, patches, responses
packages/runner	@ryph/runner, the process inside a run's container
packages/model-proxy	@ryph/model-proxy, the model-access data plane; real keys never enter a container
packages/mcp-gateway	@ryph/mcp-gateway, the tool-access data plane
packages/pi-mcp	@ryph/pi-mcp, the pi extension that connects a run to the gateway
packages/forge	@ryph/forge, the boundary toward GitHub, GitLab, Radicle and local repos
packages/radicle	@ryph/radicle, the Radicle node and bridge
packages/automations	@ryph/automations, webhooks and schedules that start runs
packages/webhooks	@ryph/webhooks, the mailroom library every webhook arrives through
packages/chat	@ryph/chat, Telegram, Zulip and Slack
packages/app	@ryph/app, the web UI, a thin BFF
packages/auth	@ryph/auth, the token contract
packages/historian	@ryph/historian, the permanent record of every run
packages/memory	@ryph/memory, what agents remember across runs
packages/browser	@ryph/browser, the Chromium sidecar a run may drive
packages/web	@ryph/web, the agent's read-only web search and fetch
packages/previews	@ryph/previews, dev-server previews on hosted deployments
packages/tunnel	@ryph/tunnel, many connections over one WebSocket
packages/launcher	@ryph/launcher, the docker seam runs and hosted servers start through
packages/logger	@ryph/logger, the shared logger
packages/sealed	@ryph/sealed, the shared credential kit
packages/service	@ryph/service, what every service's main.ts shares
packages/db	@ryph/db, the database kit and its test harness
packages/shared	@ryph/shared, small things more than one package needs
packages/process	@ryph/process, running a program on node:child_process, in the shape Deno.Command had
packages/devstack	./dev, the local dev-stack controller
packages/playground	a seeded ryph for UI work, no containers needed
packages/fake-gitlab	an in-memory GitLab for tests and the playground

images/ builds one image per service plus the agent images. deploy/ holds Compose and the Helm chart.

Developing ryph

CONTRIBUTING.md: the toolchain, the commands, how the repo runs on itself, and how designs are written down.

MIT.