eos

Service Supervisor

v0.0.11 · July 2026

Your VPS does not need PM2 or Docker to keep a process running.

eos is a single Go binary. It starts your services, watches their memory, and restarts them when they crash. One YAML file per service. No runtime to install.

Features

Single Binary

Go binaries carry their own dependencies. Drop eos onto any Linux server and it runs.

Proactive Memory Limits

The OOM killer gives no warning and leaves no clean exit. Set memory_limit_mb and eos watches the service RSS, restarting it before the kernel has to.

Safe Restarts

A service that keeps crashing restarts with increasing delays between attempts. It will not burn through your resources at full speed while you sleep.

JSON API

eos api run my-service | jq .pgid. Every operation has a JSON variant. Script your deploys and health checks without grepping log output.

Live Config Reload

Change a port, a command, a memory limit in service.yaml. It takes effect on the next status check without touching the daemon or registering the service again.

Extensible Log Routing

Log sink plugins forward stdout and stderr to Loki, an SSE stream, or Logbench. Any binary that speaks the protocol works. Build your own and ship it alongside your service.

service.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.

Add log_sinks to route structured logs to external systems. eos spawns each sink as a child process and manages its lifecycle alongside the service.

name: "cms"
command: "/home/user/start.sh"
port: 1337
runtime:
  type: "nodejs"
  path: "/usr/bin"
env_file: "/opt/cms/.env"
memory_limit_mb: 200
log_sinks:
  - type: loki
    mode: push
    address: "http://loki:3100"

Log Sink Plugins

Official plugins for routing service logs to external systems. Each is a standalone binary that eos manages alongside your service.

eos-sink-loki

Pushes log lines to Grafana Loki. Maps stderr to level=error, stdout to level=info.

eos-sink-sse

Broadcasts each log line as a Server-Sent Event over HTTP. Tail logs live in a browser or custom dashboard.

eos-sink-logbench

Ships logs to Logbench for local dev log inspection.

Install a plugin

curl -sSL https://codeberg.org/Elysium_Labs/eos-plugins/raw/branch/main/install.sh \
  | sudo bash -s -- eos-sink-loki

All plugins on Codeberg

Install

curl

curl -sSL https://codeberg.org/Elysium_Labs/eos/raw/branch/main/install.sh \
  -o install.sh
sudo bash install.sh

wget

wget \
  https://codeberg.org/Elysium_Labs/eos/raw/branch/main/install.sh
sudo bash install.sh

How does eos compare?

Same job. Different tradeoffs. Runtime requirements, memory cost, and operational surface area vary significantly.

DockerGo / OCI~65 MB RAMContainer platform

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.

supervisordPython~21 MB RAMProcess supervisor

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.

PM2Node.js~55 MB RAMApplication process manager

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.

eosGo~16 MB RAMService supervisor

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 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.

GitHub Actions

Deploy to your VPS from CI with the official eos deploy action, available on the GitHub Marketplace.

- name: Deploy with eos
  uses: Elysium-Labs-EU/eos-deploy-action@v0
  with:
    host: ${{ secrets.VPS_HOST }}
    username: ${{ secrets.VPS_USER }}
    key: ${{ secrets.VPS_SSH_KEY }}
    service_yaml: /opt/myapp/service.yaml

GitHub Marketplace · Source

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]'