A system-wide successor to process-compose. Instead of running
per-project, outrider is a persistent per-user daemon that owns the desired state of
all your services, with a TUI dashboard for managing them. Pair it with
portless and your services get
hostnames like https://myapp.localhost instead of ports you have to memorise.
Point it at an existing process-compose.yaml and it imports the whole stack.
It just runs, no edits needed.
curl -fsSL https://raw.githubusercontent.com/andrealeone/outrider/master/scripts/install.sh | bash
outrider on # start the daemon, enable it at boot
outrider # open the dashboard
outrider off # stop everything, disable boot startThat's the entire CLI: three commands. Everything else, importing stacks, adding, editing and deleting services, viewing logs, managing routes, scaling, is done from the dashboard or over the JSON socket API.
The curl one-liner above grabs the binary for your OS and CPU from the
latest release
and drops it at ~/.local/bin/outrider, no package registry needed. For
version pinning, building from source, and uninstalling, see
docs/install.md.
Run outrider on, then outrider, and you're done with the terminal: the
dashboard takes it from there, whether you're importing a
process-compose.yaml, adding a standalone service, or routing one to a
hostname. docs/usage.md walks through the dashboard
day-to-day, and docs/guides/ has end-to-end guides for
importing a stack, adding a routed service, and syncing services at scale.
outrider is a new project, heavily inspired by process-compose but built around a different model. process-compose runs per-directory and speaks HTTP; outrider runs as a persistent daemon that owns your services' desired state across your whole development environment. In practice that gets you hostname-based routing instead of port juggling, one dashboard for every project, and a state that survives reboots instead of dying with your terminal session. For the full comparison, see the feature parity document.
Documentation lives in docs/: installation, usage, the CLI and socket reference, architecture notes per component, the config schema with its process-compose compatibility report, guides, and runnable demos.
- Service tags: group services and start/stop a whole tag at once
- Standalone services: registry-native services with no backing file
- Stacks and import: run existing
process-compose.yamlfiles unedited - Portless routing: hostnames instead of memorised ports
- The dashboard: the Ink TUI that manages everything
- Autostart and boot: desired state that survives reboots
bun test # unit + integration suites
bun run check # typecheck, lint, format
bun scripts/generate-manifest.ts # after adding a CLI command file