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.
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.
Operational shortcuts
Certification
Trust tiers affect scheduling
Public capacity, review state, and sovereign eligibility influence placement.
Open
OpenTypical use: Public workloads with standard delivery and billing controls.
Evidence posture: Node eligibility visible. Standard verification — not certified-tier trust.
Review
ReviewTypical use: Nodes that need more scrutiny before certified placement.
Evidence posture: Hardware and compliance signals under review before advancement.
Certified
CertifiedTypical use: High-trust workloads with explicit jurisdiction and compliance requirements.
Evidence posture: Country, trust level, and certification status are real scheduling inputs.