Privacy Policy

Local-network content is not stored

When you transfer files or exchange text between devices on the same network, no account is needed and Relayium does not store the content. The signaling service temporarily handles connection metadata such as IP addresses, room membership, device names, presence, capabilities, and WebRTC negotiation so the devices can connect directly.

What an account stores (only if you sign in)

Same-network (LAN) sessions need no account. To create a cross-network pairing code for a browser or CLI session, the code creator must sign in; the person joining with that code does not need an account. Creating a stored download link also requires signing in. If you sign in, we store the minimum needed to run an account:

• Your email address and a display name.
• Which sign-in method you used (Sign in with Apple, Google, an email magic link, or email + password). Magic-link tokens are stored only as a hash, never in clear text; if you set a password, we store only its bcrypt hash, never the password itself. If you use Sign in with Apple with Apple's private email relay, we only ever see that relay address.
• A login session, kept in a secure, httpOnly cookie.
• Devices you register, as a random device id and a device name (e.g. your platform name). For an authenticated app, browser installation or CLI, we also keep only its last valid server-observed public IP as an account-visible identification hint. A valid observation replaces the previous address and starts its own clock; requests without a valid IP do not extend it. The address is cleared after 30 days. A separate short-lived device-approval record shows the requesting IP while you decide whether to approve that login, and administrator changes carry the administrator IP in the security audit trail (kept for up to two years by default).

Stored transfer (download links)

When you use the optional stored download-link mode, your files are encrypted with AES-256-GCM on your own device before they leave it. That is true of every client that can create or open one of these links: a browser, the command-line tool, and our native macOS and iOS apps all encrypt and decrypt locally, and none of them uploads anything the server could read. The decryption key exists only in the URL fragment — it is never sent to the server. This means:

• The server stores only ciphertext. It cannot read your file contents, filenames, or keys.
• We record the ciphertext size and timestamps (upload time, expiry) for quota management and cleanup.
• Ciphertext is automatically deleted at expiry or on the first complete download (burn-after-read), whichever comes first.

Content we cannot read

Relayium servers never receive the following in plaintext and cannot decrypt them:

• The contents of your files.
• The names of your files.
• The bodies of your live text messages.
• Your encryption keys.

Cross-network relay (TURN)

Cross-network browser file and text sessions use a TURN server by design. TURN carries only end-to-end encrypted ciphertext and transport metadata. CLI pairing-code sessions (files, text and pair) use TURN whenever the server issues a relay for the code. For either kind of session, attribution depends on the relay: when a relay node Relayium operates reports billable usage, we attribute those relayed-byte totals and timestamps to the code creator's account for quotas and abuse prevention, without inspecting message or file plaintext. Relayium's coturn TURN servers can also contribute accepted usage when configured for billable accounting, subject to authentication, attribution and accounting acceptance: their legacy usage ingest is disabled, and their optional accounting ingest is off by default. If configured in shadow mode, that ingest records per-allocation measurements that are kept with the code creator's account but never written to the billing ledger, usage periods or any quota. In both configured billable and shadow modes, account-linked per-allocation records include relay and allocation identifiers, a username hash, receipt sequence and hash, cumulative and accepted byte counters, status and timestamps for attribution, reconciliation and duplicate prevention. These records remain while the account exists. Hard account purge deletes user-linked usage ledger rows and redacts the allocation records to replay-denial tombstones: relay and allocation identifiers remain, but account linkage, username hashes, traffic counters and timestamps are cleared. Live text requires both participants to be online; Relayium provides no offline delivery or server-side message history, though either endpoint may copy or retain what it receives.

Usage metering and quotas

Paid plans mean the service has to count how much of it each account uses. While you are signed in, we keep a running per-account record of the bytes you upload and download through Relayium, the size of the ciphertext your stored links are holding, and the billable relayed-byte totals that relays report for pairing codes you created. These counters outlive the transfer that produced them — we keep monthly per-account totals alongside the per-allocation accounting records described above — because they are what enforces the usage, storage and relay quotas included in your plan, and what our billing and account records rest on. A paid subscription is a fixed price for a plan, not a per-byte charge.

• What is recorded includes byte volumes, stored-object sizes, measurement times and the per-allocation accounting metadata described above, linked to your account.
• What is not: your file contents, file names, and message bodies stay encrypted and unreadable to us. Separately from account metering, we retain three first-party, identifier-free monthly aggregate action counts for cross-network pairing: successful code mints, the first admitted socket for a live code, and the first transition to two admitted peers. Each aggregate contains only UTC month, one of those three fixed stages, and a nonnegative count—never an identifier, event row, exact timestamp, or content metadata.
• Those three product-interaction totals are bounded, best-effort lower-bound action counts, not unique users, a cohort, or an exact conversion rate. Any displayed ratio divides same-month action totals and is not cohort conversion. Our apps and website carry no advertising or third-party analytics SDK, and neither the aggregate nor the account meters are used to track you across other apps or websites.
• You can see your account-linked usage totals at any time on your account page, in the app or on the web. The identifier-free aggregate appears only in the administrator overview; the database does not store it against your account and contains no field linking it to an account.

Cookies and local storage

We use one session cookie to keep you signed in. In your browser's local storage we keep a random device id so a device you registered can be recognized; up to 20 recent realtime transfer entries (file name, size, direction, peer name and time) when local history is enabled; and the decryption keys needed to copy links you created back from My Files in that same browser. None of this browser-local history or key material is synced to the server. The history panel can clear its entries or turn recording off, and signing out clears both transfer history and stored-link keys. Clearing this site's browser data also removes them, after which a lost download-link key cannot be recovered by us. We do not use advertising or tracking cookies.

The browser also keeps a separate, local relay-performance history to help choose a faster route for large files: at most 30 records. Only the past 24 hours are used; expired records are removed when this history is next opened or used. Each record contains a salted hash of the relay identifier, transport type, coarse network class, minute, quantized speed and volume, and round-trip time. It contains no file name, file content, peer identifier or IP address. These records are separate from the optional transfer-history panel; its switch and sign-out do not clear them. Clearing this site’s browser data removes them. Derived speed estimates and their upper bounds are shared through signaling with the other participant to agree on a relay; the stored records themselves are not uploaded.

Third-party services

A few third parties are involved only when you choose to use them:

• Google, if you sign in with Google — we receive your email and basic profile to create the account.
• Apple, if you use Sign in with Apple — we receive a stable identifier and the email (or Apple's private relay address) you choose to share.
• Stripe, our payment processor for subscriptions purchased on the web — see Payments.
• Apple, for subscriptions purchased through Apple's App Store — see Payments.
• An email delivery provider, to send account emails such as magic-link sign-in and verification.

Payments

You only share payment data if you buy a paid plan. We never receive or store your full card number.

• On the web, payments are handled by Stripe. Card details go to Stripe, not to us; we receive only a customer reference and the resulting subscription status.
• In a native app, subscriptions are bought through Apple's App Store rather than from us. Apple processes the payment under your Apple ID, and we never see your payment method. The app sends us Apple's signed record of the transaction, and we keep what it says about the purchase: which subscription product you bought, Apple's identifier for that subscription, and its status, billing period, and renewal or expiry dates. We also generate a random token that ties an App Store purchase to your Relayium account; the app hands that token to Apple with the purchase and it comes back to us in the signed transaction, which is how the two records are matched without adding any further personal identifier to the exchange.
• For your account we store only your current plan, subscription status, billing cycle, period dates, and your payment provider's reference for the subscription — never card data.

The Relayium apps for Android, macOS and iOS

Our native apps handle a little device-level data that the website does not, and the platforms do not handle the same data. Each item below says which platform it describes.

• The label this device carries in your account or announces to a peer. Android reads the manufacturer-provided Build.MODEL string (for example a marketed phone model) and uses it for sign-in and nearby/realtime discovery; it may therefore be more specific than just "Android". On macOS the app reads the computer name from your Mac's Sharing settings and uses it as that label — sent with an email-and-password sign-in so your account can tell your devices apart and you can sign one out, and announced to the other devices in the room when you pair over the same network. macOS often seeds that name from your full name, so renaming the Mac changes what is sent. On iOS the label is generic and is never a name you chose: the app reads the hardware model and sends the device family — "iPhone", "iPad" or "iPod touch" — and nothing else, in those same two places. No personal name reaches us from an iPhone or iPad this way.
• An installation identifier, on macOS only. It is 32 random bytes the app generates on that Mac and keeps in its keychain, sent when you sign in through your browser so that signing back in returns to the device entry this Mac already has instead of adding another. It is random and never derived from your hardware — no serial number, MAC address, or hostname — so it identifies an installation and nothing about the machine. The iOS app has no browser sign-in to continue, so it generates no such identifier: today it sends us no installation identifier and no identifier read from the device itself. The random device id in your account's device list is one we issue for your account, as described above, and is not derived from your phone.
• Local app data and what these apps do not do. On Android, Device Inbox keeps received files and messages, its local history, and the private keys needed to open them inside Relayium's app-private storage. Deleting a history entry removes that device's local entry; Android Settings › Apps › Relayium › Storage › Clear data, or uninstalling Relayium, removes all of those app-private copies and keys. A copy you explicitly saved elsewhere is separate. Relayium excludes this app-private Inbox data from Android cloud backup and device-to-device migration. On macOS and iOS, neither app registers a push token or receives push notifications: on macOS, a finished transfer or a new inbox delivery is announced by macOS on that Mac itself, and those banners deliberately carry no file names, links, or codes, while the iOS app has no push capability and registers nothing with Apple's push service. The iOS app asks for the camera for one purpose — reading the pairing QR code another device is showing, so you do not have to type its join code by hand — and that happens entirely on your device: the picture and the code in it are used on the spot to join that pairing, and nothing the camera sees is stored by the app or sent to us as camera data. The macOS app asks for no camera access at all, and neither Apple app has access to your photo library: when you pick photos to send on iOS, the system's own picker runs outside the app and hands it only the items you chose. None of the apps tracks you across other apps or websites, and none contains advertising or third-party analytics SDKs.

Data retention and deletion

Account data is kept while your account exists, subject to the shorter device-IP rule above. You can delete your account and its data at any time from your account settings, in the app or on the web. Deletion starts a 30-day grace period during which you can undo it by signing back in; after that, your live account and personal data are permanently removed. Aggregate usage counters we must keep for billing and abuse-prevention are anonymized so they are no longer linked to you. Encrypted database backups can still contain an older copy until their bounded backup rotation expires; we do not rewrite historical backups in place, and a restored backup is subject to the same deletion and retention cleanup before it is returned to service.

Your rights

You can access, correct, export, or delete your account data, and object to or restrict certain processing. Most of this you can do yourself in your account settings; for anything else, email support@relayium.com. We do not sell your personal data. Where the GDPR or similar laws apply, our basis for the little data we process is performing the service you asked for and our legitimate interest in keeping it secure and preventing abuse.

Children

Relayium is not directed to children. We do not knowingly collect personal data from anyone under 13, or under the minimum age of digital consent where you live. If you believe a child has given us data, contact support@relayium.com and we will delete it.

Changes to this policy

We may update this policy as the service evolves. When we do, we will change the "Last updated" date above.

Contact

Questions about privacy? Email support@relayium.com.