Skip to content

Operators

Turn any GPU into a compute node. Open source.

The node agent is open source (Apache 2.0). Install it, start earning from verified inference completions.

Install paths

3

Windows, macOS, and Linux installers served publicly.

Execution pools

2

Public and sovereign execution stay separated.

Payout basis

Receipt-backed

Tied to completed work and verified receipts.

Policy posture

Declared + observed

Declared country and trust state both matter.

Requirements

Runtime readiness matters more than being online

Docker readiness, service continuity, and policy signals before a node is usable.

Runtime and drivers

Docker and vendor GPU drivers required for GPU processing. CPU-only nodes handle lighter spatial tasks.

Service lifecycle

Installers register a service so the node survives reboots.

Policy identity

Declared country for jurisdiction-restricted processing. Trust certification is separate from online status.

Node setup

Operators can launch Ryvion Node directly from the public control plane. The hub serves signed platform binaries, and the service layer is installed automatically for Windows, macOS, and Linux.

Windows

PowerShell as Administrator. Docker Desktop installed and running for container workloads.

Install command

iex ((New-Object System.Net.WebClient).DownloadString('https://ryvion-hub.fly.dev/install.ps1'))
  • Installs signed binary, writes config to %USERPROFILE%\.ryvion, registers RyvionNode service.
  • Service exposes local API on http://127.0.0.1:45890 for the desktop app.
  • GPU workloads require Docker Desktop and vendor drivers.

macOS

Terminal on macOS 13+. Docker Desktop for container workloads. Apple Silicon auto-selects arm64.

Install command

curl -sSL 'https://ryvion-hub.fly.dev/install.sh?platform=macos' | bash
  • Binary in /usr/local/bin, launch agent at ~/Library/LaunchAgents/com.ryvion.node.plist.
  • Launch agent exposes local API on http://127.0.0.1:45890 for the desktop app.
  • Without containers the node can still run, but eligibility is narrower.

Linux

Regular user on Ubuntu or systemd-based distro. Docker Engine installed and reachable.

Install command

curl -sSL https://ryvion-hub.fly.dev/install.sh | bash
  • Signed binary to ~/.ryvion, systemd service named ryvion-node.
  • Systemd service exposes local API on http://127.0.0.1:45890 for the desktop app.
  • On GPU hosts, install vendor drivers first for Docker accelerator access.

Runtime variables

Most operators only need the default hub URL. Set a bind token when onboarding through an operator invite flow, and set a declared country when you want the node considered for country-restricted policy paths.

RYV_HUB_URL=https://ryvion-hub.fly.dev
RYV_UI_PORT=45890
RYV_BIND_TOKEN=<optional-operator-bind-token>
RYV_DECLARED_COUNTRY=CA
RYV_LOG_LEVEL=info
RYV_WORK_DIR=<optional-work-directory override>

Operator checks

Service is running and node appears in dashboard after first heartbeat.

Local API responds on http://127.0.0.1:45890/healthz before opening the desktop app.

Docker Desktop or Engine running on hosts for container workloads.

Set RYV_DECLARED_COUNTRY for certified country-restricted routing.

Desktop operator app

Manage node runtime, diagnostics, and payouts from a local control surface

The desktop operator app sits on top of the local node API. It does not replace the runtime service; it makes machine posture, job activity, payout onboarding, and diagnostics visible on Windows, macOS, and Linux through a public versioned release surface.

Latest stable release

v0.1.10

Ryvion Operator v0.1.10

Platforms

macOS, Windows, Linux

Platform availability is read from the latest complete public release, so the website reflects what operators can actually download safely.

Workflow

Local-first

The app talks to the local node service for health, jobs, and diagnostics, then connects to the cloud operator surface for stats and payout onboarding.

Release notes

Public

Release assets and notes are published in the operator app repository so installs are auditable and versioned separately from the node runtime.

Windows

Ryvion.Operator_0.1.10_x64-setup.exe

2.8 MB · Checksums and signatures stay on the public release surface.

Ryvion.Operator_0.1.10_x64_en-US.msi

4.1 MB · Checksums and signatures stay on the public release surface.

macOS

Ryvion.Operator_0.1.10_aarch64.dmg

4.7 MB · Checksums and signatures stay on the public release surface.

Ryvion.Operator_aarch64.app.tar.gz

4.4 MB · Checksums and signatures stay on the public release surface.

Linux

Ryvion.Operator-0.1.10-1.x86_64.rpm

5.5 MB · Checksums and signatures stay on the public release surface.

Ryvion.Operator_0.1.10_amd64.AppImage

79.1 MB · Checksums and signatures stay on the public release surface.

Ryvion.Operator_0.1.10_amd64.deb

5.5 MB · Checksums and signatures stay on the public release surface.

Troubleshooting

Verify the local API before opening the desktop app

Desktop reads machine posture from local runtime, not cloud hub.

Desktop recovery

Desktop probes the installed service and prefers the local API endpoint over stale settings.

If runtime is installed but unavailable, the app triggers a service restart.

If the service is legacy or API was never enabled, the installer opens in repair mode.

What to confirm first

Runtime service is loaded for the current user session (macOS) or active under systemd / Windows Service Manager.

Node binary supports -ui-port and service definition passes it.

Local health check responds on http://127.0.0.1:45890/healthz before cloud linking.

Windows

Check service

sc query RyvionNode

Restart service

Start-Service RyvionNode

Verify local API

Invoke-WebRequest http://127.0.0.1:45890/healthz -UseBasicParsing

macOS

Check service

launchctl list | grep com.ryvion.node

Restart service

launchctl kickstart -k gui/$(id -u)/com.ryvion.node

Verify local API

curl -fsS http://127.0.0.1:45890/healthz

Linux

Check service

systemctl status ryvion-node

Restart service

sudo systemctl restart ryvion-node

Verify local API

curl -fsS http://127.0.0.1:45890/healthz

Payouts

Receipt-backed operator economics

Tied to completed work, assignable capacity, and trust posture.

Earnings driven by completed processing jobs and verified receipts, not uptime alone.

Certified workloads depend on node capability, Docker readiness, and policy eligibility.

Public and certified pools are separate categories with different trust requirements.

Certification

Trust tiers affect scheduling

Public capacity, review state, and sovereign eligibility influence placement.

Open

Open

Typical use: Public workloads with standard delivery and billing controls.

Evidence posture: Node eligibility visible. Standard verification — not certified-tier trust.

Review

Review

Typical use: Nodes that need more scrutiny before certified placement.

Evidence posture: Hardware and compliance signals under review before advancement.

Certified

Certified

Typical use: High-trust workloads with explicit jurisdiction and compliance requirements.

Evidence posture: Country, trust level, and certification status are real scheduling inputs.