How Clypy syncs without storing your clipboard history in the cloud
Clypy keeps devices, not a cloud archive, as the source of truth. Here is how direct sync, the live relay, peer catch-up, and offline delivery fit together.
By The Clypy team
Most sync products make the cloud the permanent middle of the system. Your devices upload data to a server-side archive, and every other device downloads from that archive whenever it returns.
Clypy deliberately works differently. Your paired devices hold the durable clipboard history. The relay can help two devices find each other across networks and forward encrypted changes while they are connected, but it does not keep a clipboard backlog for later delivery.
That choice is a privacy feature. It is also a real product tradeoff, so it deserves a plain explanation.
The short version
When you copy something, Clypy saves it locally and encrypts the change on the device that created it. Delivery then follows one of two paths:
Both paths carry the same end-to-end encrypted data. The receiving device, not the transport, decrypts it.
If another device is offline, the encrypted change waits in the sending device's local outbox. Delivery resumes when that device, or another paired device that already has the change, overlaps online with the device that missed it.
Clypy's servers help deliver live encrypted changes. They are not the permanent home of your clipboard history.
What “overlap online” means
Two devices overlap online when they are connected at the same time and share a working sync path. They might be on the same Wi-Fi network and connect directly, or they might meet through the relay from different networks.
Imagine you copy a link on your laptop while your phone is switched off:
The original laptop does not have to remain the only source forever. Once another paired device has received the change, that current peer can help a late device catch up later. What matters is that the late device eventually overlaps with at least one up-to-date peer.
If none of your current peers are online, synchronization waits. Local capture, search, collections, and other on-device features keep working in the meantime.
Why the relay does not keep a backlog
A conventional cloud backlog is convenient: close every device, return a week later, and download everything from the provider. But it also creates a long-lived central collection of clipboard data.
End-to-end encryption would keep that archive unreadable to the provider, but the archive would still reveal operational facts such as how much data exists, when it changed, and how long it has been retained. It would also become a durable target for deletion bugs, account mistakes, and future implementation errors.
Clypy uses the relay as a live transport instead. It forwards sealed messages to paired devices that are connected at that moment and does not write a clipboard-history database. Device-group decryption keys stay on your devices.
This reduces what Clypy has to protect and what you have to trust us to delete later.
Direct sync when devices are nearby
When paired devices can reach each other on the same network, Clypy sends encrypted changes directly between them. The relay is not involved in that transfer.
Direct sync is normally the fastest path, but it is not a separate security mode. A clip is encrypted before either the local-network or relay transport sees it. Changing the route does not change who can read the content.
When direct discovery is unavailable because the devices are on different networks, or because a network blocks peer discovery, the live relay provides the fallback path.
Catch-up is history comparison, not cloud restore
A returning device does not ask the server for a stored timeline. It compares its encrypted history with an available paired peer and requests only the changes it is missing.
This distinction matters:
| Catch-up from a peer | Restore from a backup |
|---|---|
| Happens automatically during normal sync | Starts only when you choose to restore |
| Requires an up-to-date paired device online | Requires an authenticated backup and its recovery key |
| Exchanges the missing encrypted changes | Rebuilds state from a point-in-time snapshot |
iCloud and Google Drive can hold encrypted Clypy backups, but they are recovery destinations, not live synchronization paths. They never become a readable cloud clipboard.
The honest tradeoff
This model deliberately chooses data minimization over server-backed anytime delivery.
The benefit is simple: there is no permanent Clypy-hosted clipboard archive waiting behind an account. The relay cannot read your clips, and it does not retain them for offline devices.
The cost is that a device which has fallen behind needs an up-to-date peer to come online. If every device containing a change is lost or erased before another peer receives it, the relay cannot recreate that change. An authenticated backup is the recovery path for device loss, not a hidden server copy.
That is different from many cloud clipboard products. We think it is the right default for data as sensitive and short-lived as the clipboard, and we want the constraint to be visible before you rely on it.
Read the technical architecture, or download Clypy and use unlimited local history without creating an account.