---
title: systemg
description: An agent-friendly general-purpose program orchestrator for busy people.
---
systemg runs your service graph from a single YAML file.
<CodeGroup>
```bash Install
curl --proto '=https' --tlsv1.2 -fsSL https://sh.sysg.dev/ | sh
```
```bash Verify
sysg --version
```
</CodeGroup>
<CardGroup cols={2}>
<Card title="Quickstart" href="/docs/quickstart">
Launch your first service graph in minutes.
</Card>
<Card title="Examples" href="/docs/examples">
Start from working examples for real-world service layouts.
</Card>
</CardGroup>
## What systemg does
Suppose you're building an API that needs PostgreSQL, Redis, and a background
worker. Instead of starting each service manually in different terminals, you
define them once in a YAML file. systemg starts everything in the right order,
restarts crashed services, and provides unified logging.
```yaml
version: "2"
services:
postgres:
command: "postgres -D /var/lib/postgresql/data"
redis:
command: "redis-cli ping"
api:
command: "python app.py"
depends_on: ["postgres", "redis"]
worker:
command: "celery worker -A tasks"
depends_on: ["redis"]
backup:
command: "pg_dump mydb > /backups/db-$(date +%Y%m%d).sql"
cron:
expression: "0 0 2 * * *"
timezone: "America/New_York"
hooks:
onstart:
command: "curl -X POST https://hooks.slack.com/services/T00/B00/XXX -H 'Content-Type: application/json' -d '{\"text\":\"Backup completed successfully\"}'"
onerr:
command: "curl -X POST https://hooks.slack.com/services/T00/B00/XXX -H 'Content-Type: application/json' -d '{\"text\":\"Backup failed!\"}'"
```
## Built for production
- Start services in dependency order.
- Restart failed processes with configurable backoff.
- Keep service logs isolated and predictable.
- Run everything from a single binary.