Ryph runs in four ways. They share the same agents, gateways and web app, so what you set up in one carries over to the next.
Start on your machine
The quickest way to see Ryph work is the binary. One command installs it, and ryph up starts everything on your laptop: the web app, the gateways and an embedded Postgres. See On your machine.
It’s meant for trying Ryph out. Ryph on a laptop stops when the laptop sleeps, and nothing outside it can reach it.
Then run it somewhere that stays on
Most of what Ryph does happens when you aren’t watching. A long-running deployment on a server or a cluster gives you:
- Agents that keep working after you close your laptop.
- Webhooks that arrive. GitHub, GitLab, your incident tool and your chat reach Ryph, so an alert or a
/ryphcomment starts a run. - A team on one instance, sharing agents, memory and run history.
- Automations on a schedule, running whether or not anyone is signed in.
Compare the modes
| On your machine | Docker Compose | Networked Compose | Kubernetes | |
|---|---|---|---|---|
| Best for | Trying Ryph out | One server, for you or a small team | Trying the split services before Kubernetes | Larger teams and organisations |
| Setup | One command | One compose file: Ryph, a launcher and Postgres | One compose file, a dozen services and their secrets | A cluster, Postgres and object storage, then one helm install |
| Runs | Containers on your machine’s Docker | Containers on the server’s Docker | Containers on the machine’s Docker, started by a launcher | One pod per run, ideally in a gVisor sandbox |
| Isolation | Runs on a confined network. One process holds every key. | Runs on a confined network. One process holds every key; a launcher holds the Docker socket. | Runs confined behind a gate. Services share one flat network. | Network policies around every service and every run |
| Data | Embedded Postgres | Postgres in a container | Postgres with one database per service, and object storage | Your Postgres and object storage |
| Scale | Your laptop, while it’s on | One machine | One machine | Your cluster, with room for several deployments |
- On your machine
- Best for
- Trying Ryph out
- Setup
- One command
- Runs
- Containers on your machine’s Docker
- Isolation
- Runs on a confined network. One process holds every key.
- Data
- Embedded Postgres
- Scale
- Your laptop, while it’s on
- Docker Compose
- Best for
- One server, for you or a small team
- Setup
- One compose file: Ryph, a launcher and Postgres
- Runs
- Containers on the server’s Docker
- Isolation
- Runs on a confined network. One process holds every key; a launcher holds the Docker socket.
- Data
- Postgres in a container
- Scale
- One machine
- Networked Compose
- Best for
- Trying the split services before Kubernetes
- Setup
- One compose file, a dozen services and their secrets
- Runs
- Containers on the machine’s Docker, started by a launcher
- Isolation
- Runs confined behind a gate. Services share one flat network.
- Data
- Postgres with one database per service, and object storage
- Scale
- One machine
- Kubernetes
- Best for
- Larger teams and organisations
- Setup
- A cluster, Postgres and object storage, then one helm install
- Runs
- One pod per run, ideally in a gVisor sandbox
- Isolation
- Network policies around every service and every run
- Data
- Your Postgres and object storage
- Scale
- Your cluster, with room for several deployments
Which one to pick
- Trying Ryph: On your machine.
- One server for you or a small team, such as a NAS, a homelab box or a VPS: Docker Compose.
- Seeing the split services before you move to Kubernetes: Networked Compose.
- A team or an organisation running Ryph in production: Kubernetes.
Each mode’s files and full reference live in the Ryph repository, under deploy/.