Replace Dropbox

What you are actually giving up#

Dropbox's real product is not sync. It is the fact that a second copy of your work exists in a building you do not own, maintained by people whose job it is, and that you can get a file back from a week ago without thinking about it. Syncthing gives you none of that. Its own FAQ says it is not a good backup application, because every change reaches every device, and deletions are changes. The failure mode is not subtle: a wrong rm -rf or a ransomware run on one laptop reaches the NAS in seconds.

You are also giving up:

• Online-only files. Dropbox lets a 2 TB account live on a 256 GB laptop. Syncthing has no equivalent: every peer holds a complete copy of every folder it shares. Seafile has a virtual drive client that comes closer.
• Sharing with people who have no account. Password-protected links, expiry dates, upload requests, "view only". Seafile and Nextcloud both do share links, but they are links to your server, which now has to be up, reachable and holding a valid certificate.
• Version history you did not configure. Dropbox keeps previous versions for a period tied to your plan. Self-hosted, history is a setting you chose, or it does not exist.
• Someone else's uptime. When your sync stops working at 11pm before a deadline, the on-call engineer is you.

Get your data out first#

Dropbox has no "download my whole account" button. Zipping folders in the web UI runs into size and file-count limits and gives you nothing to verify against. Use rclone.

rclone config              # new remote, type dropbox, use your own app key for throughput
rclone copy dropbox: /srv/dropbox -P --transfers 8 --checkers 16 --track-renames

# prove it landed before you touch the account
rclone check dropbox: /srv/dropbox --one-way --combined /tmp/dbx-check.txt
grep -vc '^=' /tmp/dbx-check.txt      # anything other than 0 needs looking at

Things rclone's own Dropbox documentation warns about, all of which you will hit on a real account:

• Rate limiting. Without batching you get too_many_requests errors and 15 to 300 second waits. The default sync batch mode is what makes --transfers 32 viable. Leave it alone.
• Case insensitivity. Dropbox cannot hold Hello.doc and hello.doc in one folder; a case-sensitive Linux filesystem can. Collisions appear on the way back, not on the way out.
• Rejected filenames. Dropbox refuses certain names such as thumbs.db, so a round trip is not always symmetric.
• Restricted content. Files flagged as copyrighted fail with path/restricted_content, and they fail individually, quietly, in the middle of a 400 GB run. This is what the check step is for.

Three more things to collect before you cancel:

1. Shared links. List them in the web UI. Each one is a URL someone else has. They break, permanently, with no redirect.
2. Shared folders you do not own. Your copy vanishes when you leave. If you need the contents, copy them into your own space first, and tell the owner.
3. Dropbox Paper documents. These are not files. Export them separately or they do not come.

Which one to pick#

Start with Syncthing. It is one binary per device, no database service, no reverse proxy, no certificate you provision, and it idles around 60 MB. If it covers what you do, nothing else here is worth the operational load. Move up to Seafile when you need accounts and share links, and only to Nextcloud when you genuinely need the groupware.

A warning on Seafile specifically: what sits under seafile-data/ is not your files. It is a Git-like store of commits and content-defined blocks. You cannot ls it, grep it, or serve it with another program, and a backup of that directory without the matching database dump restores to nothing. The manual is explicit about the order: dump ccnet_db, seafile_db and seahub_db first, then copy the data directory, so that every database row points at an object that already exists.

What the migration actually costs#

A 500 GB Dropbox Plus account, three devices:

• Pull down: 500 GB at 100 Mbit is about 11 hours, but small files are the real constraint. Expect a day of wall clock, and run it in screen or a systemd unit.
• Disk, Syncthing: copies times devices. Three peers holding the same 500 GB is 1.5 TB of disk across the fleet, plus whatever .stversions/ accumulates, which is not pruned unless you set a versioning policy.
• Disk, Seafile: roughly the library size plus retained history, and history keeps old blocks until garbage collection runs. Instances that grow inexplicably are almost always uncollected history. Set a history limit per library and schedule GC.
• Setup time: Syncthing is under an hour end to end. Seafile is an evening: .env, seafile-server.yml, caddy.yml, a MariaDB password you cannot change after first init, and a JWT_PRIVATE_KEY of 32 characters or more.
• Ongoing: Syncthing scores 1 of 5 and genuinely is a tag bump. Seafile scores 3 of 5, and its major upgrades edit config files rather than just image tags: 12 to 13 meant new compose files, moving database and cache settings into .env, and deleting [memcached], [database] and [block_backend] sections from seafile.conf.
• The backup you now owe: budget an hour to set up restic or BorgBackup to a second location, and 30 minutes a quarter to test a restore. See Backups that actually restore.

What breaks and how to tell early#

Conflict files. When the same file is edited on two devices between syncs, Syncthing keeps one and renames the other to filename.sync-conflict-<date>-<time>-<deviceid>.ext. Nothing merges and nothing warns you. Run find /srv -name '*sync-conflict*' weekly for the first month. If your workflow includes a note app, a password database or anything with an open write handle, this is a corruption source rather than a merge strategy.

Mobile. The official Syncthing Android app was discontinued in December 2024; what people run now is the community Syncthing-Fork. On iOS there is no first-party client at all. If phones were half of your Dropbox usage, this is the part that will not feel like an upgrade, and it is worth testing with one phone before you migrate anything.

The stale peer. Since version 2.0, Syncthing forgets deleted items after six months, controlled by --db-delete-retention-interval. A laptop that sleeps in a drawer for eight months and then rejoins can resurrect files the cluster deleted, as new files. If you have a device that hibernates for long periods, raise the interval or expect the reappearance.

The moment someone notices. Usually a phone photo that never arrived, or a document that opened as yesterday's version. Put Uptime Kuma or a simple check on the always-on peer, and look at the Syncthing web UI once a week for folders stuck at "Out of Sync".

The point of no return#

Keep paying Dropbox until every one of these is true:

1. rclone check dropbox: /srv/dropbox --one-way reports zero differences, twice, a week apart.
2. You have restored a file from your new backup, on a different machine, from a snapshot that is at least a day old. Not the sync target: the backup.
3. Every device that mattered has been syncing for 30 days with no conflict files and no manual intervention.
4. Every shared link you cared about has a replacement, and the people using it have the new URL.

Then downgrade to the free tier rather than deleting the account outright. It keeps the account alive, keeps the shared-link URLs resolving for a while longer, and costs nothing while you find the thing you forgot. Delete for real a month after that.

Next: plan the backup target with the Backup planner, and if you are moving a running service between machines later, Moving a service to a new machine covers the order of operations. For the head to head detail, see Syncthing vs Nextcloud and Nextcloud vs Seafile.