Security

Design principles

Relayer serves decisions, not bytes. Your binaries live on your storage; devices verify checksums and code signatures exactly as before. A compromise of Relayer could withhold updates or point devices at different URLs - but your app's signature verification (Tauri pubkey, OS code signing, sha512 pinning) is what protects installs. Keep it on.

Anonymous by design. Devices are random UUIDs generated locally by your app. No end-user accounts, emails or PII ever reach Relayer. Push-mode device labels are opaque references you choose - Relayer stores and echoes them without ever interpreting them, so keep PII out of them and use your own reference IDs.

Fail-safe availability. If Relayer is unreachable, devices simply keep running their installed version and try again later. The designed failure mode of an update system is "no update today", never "broken app".

Controls

• API keys are stored as SHA-256 hashes, displayed once at mint, and revocable instantly. Key usage is tracked (last used).
• Webhooks are HMAC-SHA-256 verified with timing-safe comparison; secrets are rotatable per app.
• Audit log: append-only record of every publish, rollout change, pause, rollback, key mint/revoke and webhook delivery - actor, IP, user agent, timestamp. Mutations that cannot be audited do not happen.
• Rate limiting on every public surface (update checks, feeds, API, webhooks, sign-in) - fail-open, so a limiter outage can never brick a fleet.
• Transport: HTTPS everywhere, HSTS, strict security headers.
• Rollbacks are permanent - a withdrawn version cannot quietly return.

Data

Hosted on Vercel (compute), Supabase (Postgres) and Upstash (Redis). See the privacy policy for retention and subprocessor details.