CloudRoam

Relay.

Scheduled mirroring between your clouds — that keeps running while your computer sleeps, and can stay sealed even from us.

One rule governs everything here: the server can only unlock what it holds a key for. Encrypting is not the same power as decrypting — and that gap is where private, unattended backup actually lives.
The model

The server is a blind courier

Relay moves files from one cloud to another on a schedule. To do that with your machine off, it must hold your cloud logins (OneDrive, S3) — there's no way around that; something has to sign in. What it does not need to hold is the key that makes the files readable. Those are two different keys, and keeping them separate is the whole game.

OneDrive
Relay
S3
carries sealed envelopes · holds logins, not the reading key
Four ways to run it

Pick your protection

Each mode is the same pipeline — OneDrive → Relay → S3 — differing only in where the content key lives. That single choice decides whether the server can read your data, and whether it can run while you're away.

A

Open Mirror

No content encryption — a straight copy.
Available now
OneDrive
Relay
S3
no content key anywhere · files land as-is
reads plaintextServer can read your data
computer offRuns fully unattended
Simplest and fastest. Protection at rest is only whatever S3's own encryption gives you. Good for non-sensitive data, staging, or public assets.
B

Managed Vault

Encrypted at rest with a key the server holds.
Proposed
OneDrive
Relay
S3
symmetric key stored server-side · encrypts on write
reads plaintextServer can read your data
computer offRuns fully unattended
Defends against a stolen S3 credential — a thief with your bucket key gets ciphertext. Unattended and convenient.
Not zero-knowledge. Because the server holds the key, a server breach or a legal order can expose everything. Encryption you have to trust the host for.
C

Sealed Vault

The server gets only your public key — it can lock, never open.
Available now · recommended
OneDrive
Relay
S3
public key only · your private key stays on your device
sealed at restServer can read your data
computer offRuns fully unattended
The trick most people miss: with public-key (hybrid) encryption, Relay is given only your public key. It can seal every new file forever — and cannot open a single one. Only your private key, which never leaves your device, restores them. A stolen cloud credential yields sealed junk. This is the honest maximum for unattended and private.
One caveat, stated plainly. OneDrive hands Relay plaintext, so the server briefly holds each file in memory while re-sealing it. Sealed at rest in S3 — not "never touched." For that, see D.
D

Private Vault

End-to-end — the server never sees plaintext, ever.
Proposed · needs an agent
OneDrive
Your agent
S3
encryption happens on a device you control
never sees plaintextCloudRoam server can read your data
needs your agent onRuns unattended
The strongest guarantee: the CloudRoam server is cut out of the plaintext path entirely. But something you trust has to do the encrypting — so with your laptop off, it runs on a small always-on agent you own (a NAS, a Raspberry Pi, a private VPS running the CloudRoam agent). That just moves "always-on" from our server to your box — which, for some, is exactly the point.
At a glance

The trade-off, in one table

ModeContent keyServer can readComputer offBest for
A Open MirrornoneYesYesNon-sensitive data, speed
B Managed Vaultsymmetric, on serverYesYesGuarding against stolen bucket keys
C Sealed Vaultpublic key onlyNo*YesUnattended + private (recommended)
D Private Vaultyour device / agentNoYour agentMaximum secrecy, ransomware recovery

* Sealed at rest in S3; the server transiently holds plaintext in memory during the copy. Mode D removes even that.

Who's awake

Two ways a job can run

Separate from how it's encrypted is when it runs and whose key is present. Relay supports both, and the scheduler lets you choose per job.

Server-only · unattended

Runs on a timer with everything of yours switched off. Available for Modes A, B, and C — because none of them need your private key to write.

  • 1 Schedule fires on the server (e.g. every night at 02:00).
  • 2 Relay signs into OneDrive + S3 with stored cloud logins.
  • 3 Copies (A), or seals with the stored/public key (B/C), to S3.
No private key involved. In Mode C the server holds only a public key — write-only power.

Signed-in · background

For secured work that needs your real key while you're around: sign in, kick it off, and let it keep running in the background — even after you close the tab — for the life of your session.

  • 1 You sign in; your browser derives the vault key locally.
  • 2 It hands Relay a session-scoped key held only in memory.
  • 3 The job runs server-side in the background using that key.
  • 4 On sign-out or expiry, the key is wiped — no new secured work starts until you're back.
The key is never written to disk. It lives in RAM for your session and vanishes with it — a middle ground between "trust the host" and "run your own box".
In the scheduler

You choose, per job

Inside Cloud Transfer → Schedules, every recurring mirror gets two new choices: how it's protected, and who needs to be awake for it to run.

Build order

What's here, what's next

Shipped

Open Mirror (A) + scheduler

Scheduled, unattended OneDrive → S3 mirroring runs with your computer off.

Shipped

Sealed Vault (C) — end to end

Browser-generated key pair; only the public key reaches the server, the private key downloads as your recovery kit. Files land .crseal and only you can open them, with the offline unseal tool.

Shipped

Scheduler choices: Protection + Run mode

The two selectors above, live in Cloud Transfer → Schedules — plus a "Seal at destination" option on one-off transfers.

Shipped

"Only when I'm signed in" run mode

A presence heartbeat gates these schedules — they run only while you're actually in the app, never unattended.

Later

Managed Vault (B) + Private Vault (D) agent

Optional server-held-key encryption, and a small always-on agent for true end-to-end when you want the server fully out of the plaintext path.