---
title: Introduction
---
# systemg
An agent-friendly general process composer.
## 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!\"}'"
```
Run `sysg start` to attach in the foreground and stream every service with a
per-service prefix. Ctrl-C stops that project and returns the terminal. Add
`--daemonize` when you want the command to return immediately.
This example is a single loose bundle — services with no project. To run several
independent stacks under one resident supervisor, group them under a
`projects:` map; see [Projects](/how-it-works/projects).
## Built for production
systemg handles the complexity of process management so you don't have to. Services that depend on databases wait for them to start. Crashed processes restart automatically with configurable backoff. Each service gets isolated logging. Zero external dependencies—just a single binary.
## Next steps
[Install systemg](installation) and have your first service running in under a minute.