[ Design Thread ] AeroCloud: provider-agnostic continuous sync with a client-side key

[axpnet]

I have written a lot about AeroCloud in the docs and on docs.aeroftp.app, but I have never opened a design thread for it, so here it is. This is a design conversation, not a roadmap commitment. I want to lay out honestly what AeroCloud is today, where I think it actually sits in the landscape, a real comparison with the tools that also sync to many providers, and where it can go, including what is plainly missing right now.

What AeroCloud is today

AeroCloud is the set-and-forget side of AeroFTP: you pick one local folder and one remote, and a background worker keeps them continuously in sync while the app is open. It is the "personal cloud folder" surface, the Dropbox mental model, built on the same sync engine that AeroSync exposes as ad-hoc power-user jobs. AeroCloud is the always-on preset, AeroSync is the raw engine as manual jobs, same core. One honest clarification up front, since it came up: this worker runs in-process, it is not an OS service, so it syncs while AeroFTP is open (including in the tray) and stops when you quit. The one part of AeroFTP that does run at the OS level at login is a separate feature, AeroMount, which mounts a remote as a live filesystem, not AeroCloud.

What is actually implemented today, verified against the code rather than the marketing:

• Continuous, real-time sync driven by a filesystem watcher (notify + debounce) plus a scheduler with interval and optional time windows. The watcher does the real-time work, the interval is a safety net.
• Provider-agnostic sync over roughly 30 transports and providers: FTP, FTPS, SFTP, WebDAV, S3, Azure, plus native providers like Google Drive, Dropbox, OneDrive, Box, pCloud, MEGA, Filen, Internxt, Jottacloud, Koofr, Backblaze B2 and more. The same generic engine runs regardless of the backend.
• Optional client-side end-to-end encryption via the AeroCrypt overlay. When a folder is bound to a crypt profile, the daemon encrypts with your key before upload, so the sync speaks plaintext locally while the wire and the backend only ever see ciphertext. It is wired fail-closed: a crypt-bound folder with a locked vault refuses to sync rather than leaking plaintext.
• Conflict handling that is not silent last-write-wins: strategies are Ask, Keep both (Dropbox-style conflict copies), Prefer local, Prefer remote, Prefer newer, with Ask as the default.
• File versioning before overwrite (a trash-can strategy with a default retention), selective sync of remote subtrees, exclude patterns and an .aeroignore file.
• Native file-manager integration: tray badge states, overlay badges for Linux file managers, and the Windows Cloud Filter API sync-root registration.

Reference material already exists and I would rather point to it than repeat it: the design doc and the current-state audit live in the internal roadmap, and the user-facing surface is documented at https://docs.aeroftp.app/features/aerocloud .

Where it positions

The category everyone competes in splits cleanly along two axes: how many backends you can sync to, and who holds the encryption key. The honest read is that the incumbents each win one axis and lose the other, and almost nobody offers real-time desktop sync on top of both.

quadrantChart
    title Continuous-sync landscape (two of the three axes)
    x-axis "Single proprietary cloud" --> "Provider agnostic, many backends"
    y-axis "Provider holds the key" --> "Client holds the key (zero knowledge)"
    quadrant-1 "Many backends, your key"
    quadrant-2 "Your key, one backend"
    quadrant-3 "One cloud, their key"
    quadrant-4 "Many backends, their key"
    Dropbox: [0.12, 0.15]
    OneDrive: [0.16, 0.18]
    Google Drive: [0.10, 0.22]
    Maestral: [0.14, 0.12]
    Nextcloud: [0.24, 0.74]
    Syncthing: [0.34, 0.70]
    Resilio: [0.30, 0.64]
    Restic: [0.80, 0.86]
    Kopia: [0.82, 0.83]
    rclone crypt: [0.90, 0.88]
    rclone plain: [0.90, 0.14]
    MultCloud: [0.78, 0.24]
    odrive: [0.68, 0.18]
    Air Explorer: [0.60, 0.28]
    AeroCloud: [0.92, 0.85]

Loading

The third axis, the one the chart cannot draw, is "real-time continuous sync in a desktop GUI". That is where the dot nearest to AeroCloud falls away: rclone crypt reaches many backends with your key, but it is a CLI and its bidirectional mode is not real-time (you run it on a schedule and it carries explicit data-loss cautions). So the whitespace AeroCloud aims at is narrow and real: continuous, real-time, GUI desktop sync to any of many backends, with an optional key the backend never sees.

Architecturally that is one pipeline:

flowchart LR
    A[Local folder] -->|watcher + scheduler| B[Sync engine, shared with AeroSync]
    B --> C{Folder bound to a crypt profile?}
    C -->|yes| D[Client-side AEAD with your key]
    C -->|no| E[Passthrough, plaintext]
    D --> F[(Any backend: SFTP / S3 / WebDAV / Drive / Dropbox / ...)]
    E --> F

Loading

The real comparison

Capabilities, verified against each project's own docs (sources at the bottom):

Tool	Sync trigger	Real-time continuous	Backend model	Client key E2E (zero knowledge)	Desktop GUI	Open source
AeroCloud	Daemon (in-app watcher) + scheduler	Yes (watcher)	Provider agnostic, ~30 backends	Optional, AeroCrypt overlay, your key	Yes	Yes, free desktop
Dropbox	Daemon	Yes	Dropbox cloud only	No (enterprise team folders only)	Yes	No
OneDrive	Daemon	Yes	Microsoft cloud only	No	Yes (no official Linux)	No
Google Drive	Daemon	Yes	Google cloud only	No (Workspace CSE only)	Yes (no official Linux)	No
Nextcloud	Daemon	Yes	Your own Nextcloud server	Optional, per-folder	Yes	Yes
Syncthing	Daemon	Yes	P2P device to device	In transit, plus untrusted-device at rest	Community/third-party GUI	Yes
Resilio Sync	Daemon	Yes	P2P device to device	Yes	Yes	No
rclone (bisync + crypt)	Scheduler or manual	No, scheduled only	Provider agnostic, 70+ backends	Yes, crypt backend	No, CLI	Yes
Restic	Scheduler or manual	No, scheduled snapshots	Provider agnostic, many backends	Yes, always on	No, CLI	Yes
Kopia	Scheduler or manual	No, scheduled snapshots	Provider agnostic, many backends	Yes, always on	Yes (KopiaUI)	Yes
MultCloud	Scheduler (cloud-side)	No, scheduled	Provider agnostic, many clouds	No, provider holds the key	Web app	No
odrive	Daemon (on-demand)	Yes, auto sync	Provider agnostic, many clouds	No by default (Encryptor add-on aside)	Yes	No
Air Explorer	Manual	No, manual or scheduled	Provider agnostic, many clouds	No, provider holds the key	Yes	No
Maestral	Daemon	Yes	Dropbox only	No	Yes	Yes, but archived in 2026

On encryption specifically, because the word "encrypted" hides a lot:

Tool	Who holds the key	Cipher note
Dropbox / OneDrive / Google Drive	The provider	AES at rest plus TLS in transit, but not zero knowledge on consumer plans; customer-key E2E is business or enterprise edition only
MultCloud / odrive / Air Explorer	The provider	Multi-cloud managers with no client-side key by default; each backend's own at-rest encryption plus TLS applies
Syncthing	You	TLS in transit; untrusted-device at rest uses XChaCha20-Poly1305 with AES-SIV, not plain AES-256
Resilio	You	AES-128 in counter mode, not AES-256
rclone crypt	You	NaCl SecretBox, provider agnostic
Restic	You	AES-256-CTR with Poly1305-AES MAC, always on
Kopia	You	AES-256-GCM or ChaCha20-Poly1305, always on
AeroCloud	You	Client-side AEAD via the AeroCrypt overlay, applied before upload, across any backend

The honest one-line summary: the tools that today encrypt with your key across arbitrary storage backends (rclone crypt, Restic, Kopia) are CLI or scheduled-backup tools that do not do real-time bidirectional sync. Everyone else is either single-cloud, or not zero knowledge, or P2P-only, or not a syncer. That intersection is what makes AeroCloud worth building rather than a fifth clone of Dropbox.

Where the incumbents are honestly better

I am not going to pretend otherwise. Dropbox, OneDrive and Google Drive have a decade of hardened conflict resolution, block-level delta sync, and reliability at scale that a younger engine has to earn, not claim. And on mobile the big three plus Resilio ship polished first-party apps with background sync, while the provider-agnostic and self-hosted camp is weak there. A desktop-native tool inherits that mobile gap unless it invests separately.

What is missing today

Being a design thread, this is the useful part. Current limits, from the code:

• Deletions are not propagated. Today a delete on one side does not remove the file on the other, it reappears from the surviving copy. For a Dropbox-style folder this is the biggest gap.
• One folder, one remote per install. There is a single config, no multiple sync pairs yet.
• Direction is fixed bidirectional. There is no upload-only or download-only or mirror mode for AeroCloud (that lives in AeroSync as ad-hoc jobs), even though a one-way backup folder is a common request.
• Versioning guards the local-overwrite side only, not the remote pre-overwrite version.
• Sync still runs a full comparison each cycle; the watcher already reports exactly what changed, but targeted incremental sync of only the changed paths is not wired yet.
• No LAN or P2P backend: AeroCloud always syncs to a remote provider, it does not yet sync two of your own machines directly.
• No headless operation: the sync worker and the file watcher live inside the app, so nothing syncs, or even detects changes, while AeroFTP is not running. The gap is reconciled by a full comparison at the next launch, not watched in real time. A true always-on folder would need an agent that runs at the OS level.

Where it can go

The expandability axes I am weighing, roughly in order of value:

1. Delete propagation with a safe tombstone model, gated behind versioning so a propagated delete is always recoverable.
2. Folder types: send-only and receive-only, so an Immich-style one-way backup folder is first class.
3. Multiple sync pairs, more than one AeroCloud folder at once.
4. Incremental sync driven by the watcher's change set instead of a full rescan each cycle.
5. Block-level delta sync, to approach Syncthing and the big three on large-file efficiency.
6. Encrypted sync folders as a first-class preset, so binding a folder to a crypt profile is a one-click "zero-knowledge backup to any provider" rather than a manual overlay.
7. A LAN or P2P backend, reusing the authenticated peer transport work from the AeroShare thread, so AeroCloud can also keep two of your own devices in sync directly, not only via a cloud.
8. A headless sync agent that runs at login independent of the GUI, so a folder keeps syncing when the app is closed. AeroFTP already has this plumbing in the sibling feature AeroMount, which mounts a remote as a live filesystem and already runs at login via an aeroftp-cli daemon; a headless AeroCloud agent could reuse that same daemon and autostart rather than reinventing it. This is where AeroCloud and AeroMount meet: different surfaces, live filesystem versus local copies, over a shared always-on agent.

Questions for the thread

• Which of the missing pieces matters most to you: delete propagation, one-way folders, or multiple folders?
• For encrypted sync, is the value mostly "zero-knowledge backup to a cheap S3 or WebDAV" or something else?
• Is a LAN or direct-device sync mode interesting, or do you reach for Syncthing there and want AeroCloud to stay cloud-focused?

Sources for the comparison: Dropbox security help, Microsoft OneDrive data-encryption docs, Google Workspace client-side encryption docs, Syncthing security and untrusted-device docs, Nextcloud end-to-end docs and desktop repo, rclone bisync and crypt docs, Resilio security brief, Maestral repository, Restic and Kopia documentation. All prices and edition gates are July 2026 snapshots and drift.

[EhudKirsh]

• You can add Restic, Kopia and a few others to the top-right quarter of the first chart, but to the left of Rclone, because they sync many backends, but not quite as many as Rclone.

• It's weird to see Cryptomator in the chart because it's "not a syncer" as you wrote. I don't think it belongs here.

• Please discuss the difference in efficiency between a daemon and a scheduler. My impression is that, because I have more cloud drives than what I like to call "general-purpose internet-connected devices" (PC and phone), and that syncing to cloud drives requires WAN, not just LAN, it makes sense to use Syncthing as a daemon between my devices, whereas Rclone, Kopia and AeroSync make sense to be schedulers. In fact, I don't really see a reason for cloud syncing to be a daemon.
  Why waste upload bandwidth with every small edit every few seconds? I prefer to cloud-sync once per hour more or less.

• For the same reasoning as the previous point, I like to keep bisync locally, namely for Syncthing over LAN, and keep cloud sync as
  one-way, because it's more efficient. I believe that it's very inefficient to use cloud drives to bisync devices that share the same LAN and can just use Syncthing instead. The main use of cloud drives should be for backups, especially when using transformative overlays, which make it infeasible to use cloud drives for any other purpose other than bisyncing devices which is inefficient as I just wrote.
  Perhaps we can have a thread in the future dedicated to the various uses of cloud drives.

• Please comment on whether you plan to add support for the overlays to AeroCloud.

• Which of the missing pieces matters most to you: delete propagation, one-way folders, or multiple folders?

Of these, delete propagation is the most important; otherwise it’s not a true sync.
One-way sync and multiple folders are both important, roughly equally.

• For encrypted sync, is the value mostly "zero-knowledge backup to a cheap S3 or WebDAV" or something else?

I don’t understand this question. What are the alternatives?

• No LAN or P2P backend: AeroCloud always syncs to a remote provider, it does not yet sync two of your own machines directly.
• Is a LAN or direct-device sync mode interesting, or do you reach for Syncthing there and want AeroCloud to stay cloud-focused?

Again, considering that this is nearly perfected at this point by Syncthing, this is the absolute lowest priority to-do item in my opinion for AeroFTP. I prefer the focus of AeroFTP to be mostly around cloud syncing because this is where the biggest gap in software currently is.

[axpnet]

Thanks Ehud, this is exactly the kind of feedback that sharpens the design. Point by point.

You can add Restic, Kopia and a few others to the top-right quarter of the first chart, but to the left of Rclone

Good call. I will add Restic and Kopia (and Duplicati/Borg as space allows) to the top-right, sitting to the left of rclone since they cover fewer backends.

It's weird to see Cryptomator in the chart because it's "not a syncer" as you wrote. I don't think it belongs here.

You are right, so I will drop it from the chart. I had only plotted it as a reference point for "client holds the key," but since it does not sync it does not belong on a syncer comparison.

Please discuss the difference in efficiency between a daemon and a scheduler. [...] Why waste upload bandwidth with every small edit every few seconds? I prefer to cloud-sync once per hour more or less.

I agree with your framing, and I want to be explicit that AeroCloud does not force a daemon. It already runs both a filesystem watcher and an interval scheduler, and the interval is yours to set (once per hour is a perfectly good choice). Real-time is opt-in, not mandatory. To address the "waste upload bandwidth on every small edit" concern, I am seriously evaluating debounce and coalescing so that even watcher mode would batch a burst of edits into a single transfer instead of uploading every few seconds. So: daemon behaviour over LAN if you want it, scheduler behaviour to the cloud, same engine.

I like to keep bisync locally, namely for Syncthing over LAN, and keep cloud sync as one-way, because it's more efficient. [...] Perhaps we can have a thread in the future dedicated to the various uses of cloud drives.

I think your model is the right default and I will make it easy to express: bidirectional over LAN, one-way (send-only) to the cloud, with the cloud copy treated as a backup. One-way folders are on the list precisely for this. A dedicated thread on the uses of cloud drives sounds worth doing and I will open one.

Please comment on whether you plan to add support for the overlays to AeroCloud.

Yes. The AeroCrypt overlay is already wired in (fail-closed if the vault is locked), and I plan to bring the full overlay stack to AeroCloud, since your point that overlays make cloud drives backup-only is exactly the workflow I want to support well.

Of these, delete propagation is the most important; otherwise it's not a true sync. One-way sync and multiple folders are both important, roughly equally.

Received. Delete propagation first (agreed, it is the line between sync and copy), then one-way folders and multiple folders equally, then LAN and P2P last. That maps cleanly onto my build order.

For encrypted sync, is the value mostly "zero-knowledge backup to a cheap S3 or WebDAV" or something else?

I don't understand this question. What are the alternatives?

My fault, let me rephrase. I was asking what the client-side key is for, in your usage. The alternatives I had in mind: (a) zero-knowledge backup to a cheap dumb store like S3 or WebDAV; (b) protecting data on mainstream clouds such as Dropbox or Google Drive from the provider itself; (c) safely syncing across devices you do not fully trust; (d) sharing an encrypted folder with someone else. Which of these is the real driver for you, or is it something else?

[EhudKirsh]

By far, my primary interest in AeroFTP is one-way cloud backups, as an improved replacement for Rclone and Kopia.
So the integration of AeroProfiles, AeroSync and the 4 overlays. AeroFile is also useful now for compressing and extracting.
AeroFile, AeroImage and AeroShare have the potential for additional aspects which we discussed, which might become useful for me.
And again, there are more ideas that I’ve yet to discuss, which I hope you’ll be open to coding when the time comes.

So to answer your question directly, of the 4 interests you just listed, (a) and (b) interest me, not so much (c) and (d).

[axpnet]

@EhudKirsh as promised, I opened the dedicated thread on the uses of cloud drives, framed as a poll so we get a quick read on the community first, then discuss in depth: #407. Your daemon-vs-scheduler and one-way-cloud points are the seed of it.