Self-hosted Dropbox alternatives, compared

Which self-hosted Dropbox alternative should you run?

Four self-hosted Dropbox alternatives are worth your time: Nextcloud, Seafile, Syncthing, and object storage with a client on top. They are not interchangeable. Nextcloud suits a household or a small team where other people need to receive files. Seafile suits a person or a team syncing a very large number of small files, where sync speed matters more than what the data looks like on disk. Syncthing suits one person syncing their own devices, where nobody outside needs a link. Object storage suits an archive: cheap bytes you rarely open.

Choose on how the sync works before you compare features. Feature lists all look the same. The topology, meaning which machine holds the copy that every other machine agrees with, is what decides whether you are still happy in six months.

Sync topology: a server of record, or peers with no server

Two designs are on the table, and most of what follows comes from which one you pick.

A server of record. Nextcloud, Seafile and object storage all work this way. One machine, usually a VPS (virtual private server), holds the authoritative copy. Every device talks to that machine. Your laptop can be off for a month, come back, and catch up on its own. A phone with 6 GB free can hold a subset while the server holds everything. A browser can reach the files, which is the reason share links can exist at all.

Peers with no server. Syncthing works this way. Devices find each other and exchange file lists directly over an encrypted connection. No copy is authoritative: a file exists on the devices that hold it and nowhere else. Two devices must be online at the same moment for a change to pass between them. There is no URL to give anybody, because no machine is serving a page.

Four consequences follow, and they are the ones people meet late.

• Sending a file to a person who will not install software needs a server of record. A link is a URL, and a URL needs a process listening on a port.
• Reaching your files from a machine you do not control, a work laptop for example, needs a server of record.
• A device that was off for weeks catches up from a server whenever it wakes. In a peer setup it catches up only while another device holding that data is online too. That is why many Syncthing users run one instance on a VPS as an always-on peer.
• Storage adds up differently. A server of record holds one full copy, plus whatever each device keeps locally. Four peers sharing one folder hold four full copies, because every peer keeps the whole folder.

Nextcloud: users, groups and public links

Nextcloud is a PHP web application. It stores your files as ordinary files under a data directory and tracks them in a database. You can share a folder with a user, with a group, or as a public link carrying a password and an expiry date. Version history is on by default and deleted files land in a trash bin first. Desktop clients cover Linux, macOS and Windows, and the iOS and Android apps are official. If your reason for leaving Dropbox is that other people need to receive your files, this is the honest answer.

The price is moving parts. A normal install runs a web server, PHP-FPM (the PHP process manager), a database such as MariaDB or PostgreSQL, and Redis for file locking. A background job runs every five minutes from cron or a systemd timer. On a 1 GB VPS it will start, and then a large upload or a long occ maintenance command meets the out-of-memory killer. Treat 2 GB as the floor for a handful of users, and expect to want 4 GB once you enable more apps. The other price is upgrades: app-store apps are built against a specific core release, so check that the apps you depend on support the next major version before you take it.

Nextcloud slows down when one account holds hundreds of thousands of small files, because each file is a row in the file cache table and a real file on disk, and the desktop client walks them one at a time. At household scale this never comes up. Sizing, TLS (transport layer security) and backups are covered in a Docker based Nextcloud install with TLS and backups, which is where to go once you have decided.

One warning about scope. Nextcloud will also run your calendar, contacts, notes and photo library, and every app you enable adds background work and one more thing that can block an upgrade. If photos are the actual problem, a dedicated tool handles them better: see Immich as a self-hosted Google Photos replacement. If documents and wikis are the actual problem, look at the self-hosted Notion alternatives rather than stacking apps onto your file server.

Seafile: built for a very large number of small files

Seafile splits every file into blocks and stores them in an internal object store addressed by content hash, the same idea git uses for its objects. The unit of sync and sharing is a library rather than a folder tree. Because the client uploads blocks and one commit instead of one request per file, syncing a directory of 100,000 small files finishes far faster than a per-file protocol manages. Identical blocks are stored once, so a second copy of a large file costs almost nothing.

The trade is that your files on the server stop being files. Open the storage directory and you find object files with hexadecimal names. Getting data out means the Seafile client, or Seafile's own export and fsck tools. Backups still work, since those objects are ordinary files, but you cannot restore one spreadsheet with cp. Decide now whether that is acceptable, because it is the property people regret later.

Seafile ships a community edition and a paid professional edition, and the split between them moves between releases, so read the current terms on their site before you plan a team around a specific feature. Official desktop and mobile clients exist. Encrypted libraries are encrypted on the client, so the server stores ciphertext it cannot read. Lose the passphrase and the library is unreadable, including by you. Opening an encrypted library in the browser means giving that passphrase to the web session, so the strong version of that guarantee belongs to the desktop and mobile clients.

Resource cost lands close to Nextcloud. You are running a database, a memory cache and two application processes, so 2 GB is again the sensible floor.

Syncthing: nothing to log in to

Syncthing is a single Go binary. It watches folders, finds its peers through a discovery server or a relay, and syncs directly between devices. There are no accounts and no login page for the people you sync with. You pair two devices by ID and accept the folder on each side. It is the least work to run of anything here, because there is very little to run.

What you give up is the entire sharing column. Its entry reads Device pairing only, no links. You cannot hand a link to a client, an accountant, or a relative. Mobile is the other gap: Android app, no official iOS. The project's own FAQ is direct about it: "There are no plans by the current Syncthing team to officially support iOS in the foreseeable future", because iOS restricts background processing enough to make reliable syncing hard. iOS users are left with third-party apps.

Resource use is small, with one thing worth knowing. Syncthing keeps an index entry for every file it syncs, so memory and the first scan grow with file count rather than with total size. Hashing a large folder the first time will use the CPU for a while, and then settle. On the smallest VPS plan it is comfortable.

Conflicts are handled by keeping both sides. When two devices change the same file while they cannot see each other, Syncthing renames one copy and keeps it beside the other, so you find files like notes.sync-conflict-20260802-141530-K7MB3QT.md. Nothing is lost. Nothing is merged either, and you resolve it by hand.

Object storage with a client: cheap bytes, not a sync folder

Object storage means an S3 (simple storage service) compatible bucket, either self-hosted with MinIO or rented from a provider. You reach it with a tool: rclone from the command line, or a desktop client that presents the bucket as a drive. Sharing is a presigned URL, a link you generate that carries its own expiry time. Versioning is a bucket setting: Bucket versioning, off by default, so turn it on when you create the bucket, because it does not apply to objects you uploaded before.

Treating a bucket as a sync folder is where this goes wrong. Nothing watches your Documents directory by default. rclone bisync does two-way sync, and rclone's own documentation is direct about the care it needs. What object storage does very well is sit underneath: a backup target, or the storage layer behind an application. Self-hosted S3 compatible object storage with MinIO covers the server side.

The resource cost is unusual here. MinIO is one binary and idles small. The cost you actually pay is disk, and on a VPS that means a block volume rented by the gigabyte, plus the bandwidth you spend moving objects in and out. Neither of those shows up in free -h, so read what a VPS actually costs per month before you size an archive.

Sharing, mobile clients and versioning compared

[
  {
    "tool": "Nextcloud",
    "sharing": "Public links, users and groups",
    "mobile": "Official iOS and Android apps",
    "versioning": "On by default, plus trash"
  },
  {
    "tool": "Seafile",
    "sharing": "Public links with password and expiry",
    "mobile": "Official iOS and Android apps",
    "versioning": "Library history and snapshots"
  },
  {
    "tool": "Syncthing",
    "sharing": "Device pairing only, no links",
    "mobile": "Android app, no official iOS",
    "versioning": "Optional per folder, off by default"
  },
  {
    "tool": "Object storage",
    "sharing": "Presigned URLs you generate",
    "mobile": "Third party clients only",
    "versioning": "Bucket versioning, off by default"
  }
]

All 4 options split along one line. Three of them can hand a file to a stranger holding nothing but a browser. One of them only talks to devices you already own. Seafile's versioning entry, Library history and snapshots, deserves a note: history is kept per library, so deleting a library takes its history with it.

Getting your data out again

Exit cost is cheap to check now and expensive to discover later, so check it before you commit.

Nextcloud stores real files in real directories, so a tar of the data directory gives you your documents even if the application never starts again. Syncthing does the same on every peer, which is the strongest exit story here: the files are simply sitting on each device. Seafile's object store needs Seafile or its export tools to reassemble the blocks into files. Object storage needs rclone or an equivalent, which is one command away.

Sync is not a backup, and that gap is where people lose data

Every tool here copies changes between machines. A delete is a change. Remove a folder on your laptop and the client tells the server, the server applies it, and every other device removes it too. Ransomware uses the same path: it encrypts files locally, the client sees modified files, and it uploads the encrypted versions. The sync worked correctly. Your data is still gone.

Trash bins and version history soften this. They also expire, they can be emptied by the same account that made the mistake, and they sit on the same disk as the live copy. A failed volume takes the files and their history together.

A backup is a separate copy, on separate hardware, taken on a schedule, that you have restored from at least once. Back up the database in the same run as the files. Restoring a Nextcloud data directory without its database gives you an instance that does not know those files exist, and an occ files:scan afterwards recovers the files while losing the shares and the version history that lived in those tables. Scheduled restic backups from a VPS covers the encrypted, deduplicated version of this, including how to test a restore instead of assuming one.

What I would pick

Nextcloud, for most people reading this. What people miss after leaving Dropbox is handing a link to someone who will never install anything, and opening a file on a phone. Nextcloud does both with official clients and no paid tier, and 2 GB of RAM is a fair price for that. Two exceptions I hold to. If the folder is only ever yours and only ever on hardware you own, run Syncthing and enjoy having no server to patch and no web login to defend. If you sync a working directory of hundreds of thousands of files, run Seafile and accept the opaque storage in exchange for the speed. Object storage belongs underneath whichever one you choose, as the backup target, not in front of it as the sync tool.

FAQ

Is Syncthing a backup for my laptop?

No. Syncthing copies changes between devices, and a deletion is a change like any other, so a file you delete by accident disappears from every paired device within seconds. Per-folder file versioning helps, and it is off until you enable it on each folder. Keep a real backup on separate hardware, taken on a schedule, and restore from it once so you know the restore works.

Can I run Nextcloud and Syncthing on the same VPS?

Yes, they listen on different ports and do not conflict. Do not point a Syncthing folder at Nextcloud's data directory. Nextcloud tracks every file in a database, so files that appear on disk underneath it stay invisible until you run occ files:scan, and files removed underneath it leave database rows pointing at nothing. Give Syncthing its own directory, or attach that directory to Nextcloud as external storage so Nextcloud knows to look at it.

Which one lets me share a link with someone who has no account?

Nextcloud and Seafile both create public links, with an optional password and an expiry date. Object storage gives you a presigned URL that stops working on its own after the time you set. Syncthing has no answer here. Its sharing model is device pairing, so the other person must install Syncthing, give you a device ID, and accept the folder.

How much disk does the server need?

For a server of record, plan for the full size of the shared data, plus space for version history and trash, plus working room for uploads in progress. Version history is the part people underestimate: keeping every version of a 2 GB file that changes daily grows fast, so set a retention policy early. Putting the data on a separate volume keeps that growth away from the root filesystem, where a full disk stops the whole server rather than one upload.