Device Inbox
Send a file from any browser to a folder on your own Mac, PC, NAS or server. It is encrypted before it leaves the browser, it waits in a queue while the device is offline, and it is only ever called saved once that device says it wrote the file to disk.
How it works
- On the machine that should receive: sign in, choose the folder it may write to, and switch receiving on there. Nothing arrives until that has been done on that machine.
- In any browser: sign in to the same account and pick the device on this page. Your browser encrypts the files and seals the content key to that device before anything is uploaded.
- Relayium stores ciphertext and routing state. It cannot read the file, its name or the folder it is bound for, and it holds no key that could open it.
- The device collects the task, decrypts and verifies it locally, and writes it into the folder you chose — without asking you again, and without ever overwriting a file that is already there.
- Uploaded is not saved: while the target is offline, downloading or verifying, the transfer is still on its way. Saved appears only after that device has decrypted the file, checked it against its manifest and committed it durably to the folder.
Your platform
- Linux server — available now — An always-on VPS, NAS or home server. Sign in once, download the short installer and read it before it gets root: it creates /srv/relayium-inbox, makes a dedicated low-privilege account, enrols the receive key and installs a hardened systemd system unit that starts now and after every reboot. Files land in /srv/relayium-inbox, nothing existing is overwritten, and systemctl status, journalctl, inbox pause/resume and inbox disable control it.
- Linux desktop — available now — Your own workstation receiving into your own home directory, via the CLI and a systemd --user service. Deliberately not the unattended server deployment: a user service stops when you log out unless you enable lingering, which needs root once.
- macOS — available now — The Mac app is published: install it from the Apps page, sign in to the same account, choose a receive folder and set Receiving to Ask every time or Automatic. It receives while it is running, including with its window closed, and Open at Login brings it back after you log in again. It is not a system daemon — quit it and it stops receiving, which is what the launchd command-line receiver below is for on a Mac you run unattended or administer over SSH.
- Windows — no native app — Relayium publishes no Windows app: no tray receiver, no Windows service and no startup entry, and none is offered. What is verified today is the command-line receiver in the foreground: it receives while the terminal window stays open and ends when you close it. For a receiver that survives a logout and a reboot, use the Linux server deployment above.
- iPhone — no native app — Relayium publishes no iPhone or iPad app, so there is nothing to install here. What works today: an iPhone signs in to relayium.com in Safari and sends from this page to a Mac, PC or server of yours that has Device Inbox switched on. iPhone is a sender here and not a receiver, so nothing is delivered onto the phone.
- Android — available now — The Android app receives too, since the 0.2.0 public preview: install the APK from the Apps page, sign in to the same account, open the Inbox screen and set Receiving to Ask or Automatic. It is off until you turn it on, and it receives on whichever screen you are on — but only while the app is open, because there is no foreground service and no background delivery. Deliveries land inside Relayium's own storage on the phone rather than a folder you pick; from the Inbox screen an entry can be opened, shared, or saved out to your own location. Clearing the app's data or uninstalling it deletes those copies. A phone can still be a sender instead: sign in at relayium.com in its browser and send from this page.
What it needs, and what it never does
An account on both ends, and receiving switched on at the device
Device Inbox is the one part of Relayium that writes to your own disk, so it is tied to an account rather than to a link anyone could hold. A device only accepts work from the account it is signed in to, and receiving stays off until someone with access to that machine turns it on there, choosing where deliveries land on the platforms that offer that choice. If the device is asleep or offline you can still send: the encrypted task waits in the queue and is delivered when it comes back.
A share link is a different permission
Relayium's public download links stay exactly what they were: whoever holds the full link can download that one file by hand. A link can never make one of your devices write to disk. The two permissions are deliberately separate, and holding a link gives no access to any device inbox.
Boundaries that do not move
Relayium never holds a key that can open your files, and file names and folder paths travel inside the encrypted manifest it never receives. An existing file is never overwritten, merged or deleted — a name collision gets a safe new name. Nothing received is opened, executed or unpacked, and received files are not made executable. A partly downloaded file is never presented as a complete one. You can pause receiving, revoke a device or delete queued work at any time.
Frequently asked questions
Do I need an account?
Yes, on both ends, and it has to be the same account. This is the only part of Relayium that writes to a disk you own, so it is tied to an account rather than to a link. There is no way to make someone else's device receive from you.
What happens if the target device is offline?
You can still send. The encrypted task waits in the queue at Relayium and is delivered when the device comes back online. An offline device is a valid target, not a refusal.
Does 'uploaded' mean the file is on my machine?
No, and Relayium never merges the two. While the target is offline, downloading or verifying, the transfer is shown as still on its way. Saved appears only after that device has decrypted the file, verified it against its manifest and committed it durably to the folder you chose.
Can someone with a share link write to my device?
No. A public download link lets whoever holds it download that one file by hand, and nothing more. Automatic receiving only accepts work from your own account, and only after someone at the device switched it on.
Which platforms can receive today?
Linux servers, through the published installer and a low-privilege systemd system service, and Linux desktops through the CLI and a systemd --user service. macOS can receive in the published Mac app, or through the same command-line receiver under launchd on a Mac you run unattended. Windows can run the receiver in the foreground only. iPhone and Android are senders here: Relayium publishes no app for either, and none is offered.
Can Relayium read my files or their names?
No. Your browser encrypts the files and seals the content key to the target device before anything is uploaded. File names and folder paths are inside the encrypted manifest. The server keeps ciphertext, sizes, timestamps and routing state, and holds no key that could open any of it.
Relayium home · Guides · Apps · Pricing · CLI · Device Inbox · Privacy · Terms · Security · Releases