eos
Service Supervisor
v0.0.11-rc.3 · Apr 2025Run and manage background services on your VPS without the overhead. Register services, start them, and keep them running as a single Go binary.
No Node.js runtime. No Python environment. Copy the binary, write a YAML config, and your services are managed.
Features
Single Binary
No runtime dependencies. Copy eos to your server and installation is done.
YAML Config
One service.yaml per service. Human-readable and version control friendly.
Exponential Backoff Restart
Failed services restart automatically, with increasing delays between attempts to avoid restart loops.
Memory Limits
Set memory_limit_mb in service.yaml. eos restarts services automatically when they approach the limit.
Structured Logs
Separate stdout and stderr log files per service, written to disk. Tail them live or review history.
JSON API
The eos api subcommand outputs JSON for every operation. Pipe to jq, use in scripts, or integrate with CI.
How does eos compare?
Same job. Different tradeoffs. Runtime requirements, memory cost, and operational surface area vary significantly.
Bundles your app, runtime, and OS deps into a portable image. A daemon manages container lifecycles, networking, and volumes.
Good for: You need isolation, dev/prod parity, or Kubernetes.
Less ideal for: You're running known binaries on a VPS. Image layers add weight you don't need.
Battle-tested Unix process supervisor (since 2006). INI config, XML-RPC API, Python runtime required.
Good for: Python is already in your stack and you want something mature.
Less ideal for: You don't need Python. No JSON output, INI config doesn't version well.
Built for Node.js, extended to any runtime. Adds cluster mode, zero-downtime reloads, and optional cloud monitoring.
Good for: Your stack is Node.js-heavy and you want cluster mode or zero-downtime reloads.
Less ideal for: Your services aren't Node.js. You pull in the Node runtime for work that doesn't need it.
Keeps processes alive, surfaces what went wrong, and exposes machine-readable endpoints. One binary, one YAML file per service.
Good for: Resource-constrained VPS. Mixed runtimes. Process management without a runtime tax.
Less ideal for: You need filesystem isolation, a plugin ecosystem, or container orchestration.
Memory measured as VmRSS via /proc on Debian GNU/Linux 12 (bookworm), aarch64. One dummy service running. Docker 20.10.24, supervisord 4.2.5, PM2 6.0.14, eos v0.0.10.
Install
curl
curl -sSL https://raw.githubusercontent.com/Elysium-Labs-EU/eos/main/install.sh -o install.sh
sudo bash install.shwget
wget https://raw.githubusercontent.com/Elysium-Labs-EU/eos/main/install.sh
sudo bash install.shservice.yaml
Each service is described by a single service.yaml file, checked in alongside your code.
eos reads this file live on every status check, so config changes are reflected immediately without re-registering the service.
Set memory_limit_mb and eos will automatically restart the service as it approaches the limit, before the OS has to intervene.
name: "cms"
command: "/home/user/start.sh"
port: 1337
runtime:
type: "nodejs"
path: "/usr/bin"
memory_limit_mb: 200
Quick reference
# Register a service
eos add ./service.yaml
# Start it
eos run my-service
# Check status
eos status
# View logs
eos logs my-service
# JSON output for scripts
eos api run my-service | jq .pgid
eos api logs my-service | jq '.lines[-1]'