Seafile vs Nextcloud for file sync

Seafile vs Nextcloud: the short answer

Seafile vs Nextcloud comes down to one difference: what a file is once it reaches the server. Seafile splits every file into blocks and stores them in an object store that only Seafile can read, so sync is fast and backup becomes a two part job. Nextcloud writes your file to disk as a file, and treats sync as one feature of a platform that also runs calendars, contacts, documents and share links. Decide on that difference, because the rest follows from it.

As of August 2026, Seafile is on the 13.0 series and Nextcloud on the 34 series. Both are mature, and neither is about to change its storage model.

How Seafile stores your files

Seafile models a library the way git models a repository. The admin manual gives the internal model as Repo, Commit, FS and Block, and notes that a repo is also called a library. Each file is split into blocks of variable length by content defined chunking (CDC, an algorithm that picks block boundaries from the data itself), and the manual gives an average block size of about 8 MB. Blocks are named after their contents, so two versions of one large file share every block that did not change, and two libraries share identical blocks as well.

The relational database holds only a small amount of metadata about the libraries. Everything else, meaning the commits, the directory objects and the blocks, sits under the data directory. In the Docker layout used by the 12 and 13 series that is /opt/seafile-data/seafile/seafile-data. Running ls there tells you nothing useful, because you see directories full of hash names, not Invoices/2026/march.pdf.

Sync follows the same model. The client asks the server what changed, receives a list of block hashes, and fetches only the blocks it does not already hold. That is why Seafile holds up on a large library: the bytes transferred are proportional to the blocks that changed, not to the size of the file that contains them.

How Nextcloud stores your files

Nextcloud puts the file on disk where you expect it. The path data/<username>/files/ mirrors what the user sees in the web interface. A database table, oc_filecache, mirrors that same tree with sizes, modification times and etags, and Nextcloud trusts the table rather than the disk.

The desktop client speaks WebDAV (web distributed authoring and versioning) over HTTPS. Each file costs at least one request, which is why Nextcloud added a bulk upload API: the developer manual explains that uploading many small files is slower than it could be because the network bandwidth is not fully used, so small files are packed together. Large files go through the chunking API instead, and the desktop client's default chunk size is 5 MiB (OWNCLOUD_CHUNK_SIZE defaults to 5242880 bytes).

The payoff of files on disk is that every tool you already own can read your data. The cost is that Nextcloud does not notice changes made behind its back. Copy files straight into the data directory and they stay invisible in the web interface until you scan:

sudo -E -u www-data php occ files:scan --all -vv

The admin manual names exactly these cases for a rescan: after copying files directly into the data directory, after a migration, and when you are investigating file cache inconsistencies.

Which one syncs a large library faster?

Seafile, in the two cases that hurt: tens of thousands of small files, and repeated edits to large files. The mechanism is block level deduplication, so a 4 GB disk image whose middle changed uploads as a few blocks. Nextcloud narrows the small file gap with bulk upload, and it cannot close the large file gap, because its unit of transfer is the whole file.

Do not take my word for the size of the gap, and do not take a vendor benchmark either. Build a library that looks like yours and time it:

mkdir -p ~/synctest && cd ~/synctest
for i in $(seq 1 20000); do head -c 4096 /dev/urandom > "file_$i.bin"; done
du -sh ~/synctest

Drop that directory into a synced folder on each server and watch the client finish. Reliability counts as much as speed. A Seafile client uploads blocks first and writes the commit that references them last, so an interrupted upload leaves the library on its previous commit instead of a half written tree.

What each needs on a small VPS

Seafile's docs ask for "at least 2G RAM and a 2-core CPU (> 2GHz)". Nextcloud documents memory per PHP process instead: a minimum of 128 MB and a recommended 512 MB per process, which you multiply by your worker count before adding the database, the cache and preview generation. Below are the starting points I would use for a small team. They are starting points, not measurements.

[
  {
    "label": "Seafile CE 13",
    "start_ram_gb": 4,
    "start_cpu_cores": 2,
    "sql_databases": 3
  },
  {
    "label": "Nextcloud 34",
    "start_ram_gb": 4,
    "start_cpu_cores": 2,
    "sql_databases": 1
  },
  {
    "label": "Syncthing 2",
    "start_ram_gb": 1,
    "start_cpu_cores": 1,
    "sql_databases": 0
  }
]

Both land in the same class, 4 GB of RAM with 2 cores, so the footprint axis does not decide between them. Syncthing runs in 1 GB on 1 core, which is the honest reason to consider it. The moving parts differ more than the memory does. Seafile keeps 3 SQL databases where Nextcloud keeps 1, and the default Seafile Docker deployment brings up the server, MariaDB, Memcached, SeaDoc and Caddy from files you download first:

mkdir /opt/seafile
cd /opt/seafile
wget -O .env https://manual.seafile.com/13.0/repo/docker/ce/env
wget https://manual.seafile.com/13.0/repo/docker/ce/seafile-server.yml
wget https://manual.seafile.com/13.0/repo/docker/seadoc.yml
wget https://manual.seafile.com/13.0/repo/docker/caddy.yml
nano .env

In .env set SEAFILE_SERVER_HOSTNAME, the MySQL root and database passwords, the initial admin account, and JWT_PRIVATE_KEY. The manual requires a random string of no less than 32 characters for that key, and it is read on the first start, so generate it before you bring the stack up:

openssl rand -base64 40
docker compose up -d

The first start creates the three databases and the admin user. Nextcloud's equivalent decisions, including TLS and reverse proxy, are worked through in the Nextcloud on a VPS guide with Docker, TLS and backups.

How do backups differ?

This is the axis people underestimate, and it is where the two products differ most.

For Seafile the order is not optional. The manual's rule is to back up the SQL first and the data directory afterwards, because then every record in the database has a valid object to reference, so the libraries are not corrupted. Reverse it and a database row can point at a block your snapshot never captured.

docker exec -i seafile-mysql mariadb-dump -uroot -p"$MYSQL_ROOT_PASSWORD" --opt ccnet_db > ccnet_db.sql
docker exec -i seafile-mysql mariadb-dump -uroot -p"$MYSQL_ROOT_PASSWORD" --opt seafile_db > seafile_db.sql
docker exec -i seafile-mysql mariadb-dump -uroot -p"$MYSQL_ROOT_PASSWORD" --opt seahub_db > seahub_db.sql
rsync -az /opt/seafile-data/seafile /backup/data/

Two details in those lines. Use mariadb-dump, because the mysql series of commands is deprecated in the MariaDB image Seafile ships. Drop the -t flag from docker exec when you redirect to a file, because a TTY rewrites line endings and damages the dump.

The two halves are captured separately, so they can drift. After any restore, check the store before you trust it:

docker exec -it seafile bash
cd /opt/seafile/seafile-server-latest
./seaf-fsck.sh

When something is missing, the tool names the object:

Block 650fb22495b0b199cff0f1e1ebf036e548fcb95a is missing.
Repo ca1a860d HEAD commit is corrupted, need to restore to an old version.

Plan for garbage collection too. Deduplication means deleted files and deleted libraries keep their blocks until you run ./seaf-gc.sh from that same directory, and the run reports what it found, such as GC finished. 507 blocks total, about 507 reachable blocks, 0 blocks can be removed. Skip it for a year and your backups keep paying for data your users deleted.

Nextcloud has the same two part problem in a different shape, because the data directory and the database must describe the same tree:

sudo -E -u www-data php occ maintenance:mode --on
rsync -Aavx /srv/nextcloud/ /backup/nextcloud-dirbkp/
mariadb-dump --single-transaction --default-character-set=utf8mb4 -u nextcloud -p"$DB_PASS" nextcloud > /backup/nextcloud-sqlbkp.bak
sudo -E -u www-data php occ maintenance:mode --off

Keep the config folder, the data folder, any custom apps and your theme, plus that dump. Restore both halves from the same moment. If the data directory is newer than the database, users see files the file cache does not know about, and occ files:scan --all repairs it. If the database is newer, cache rows point at files that are gone, and occ files:cleanup removes cache entries that have no matching entry in the storage table.

Either way you want a backup program that copes with many small files and keeps history, which is what restic and BorgBackup do differently.

Clients on desktop and mobile

Seafile ships two desktop programs. The syncing client keeps a local copy of the libraries you select. The Drive client (SeaDrive) mounts your libraries as a virtual drive and downloads on access: on Windows it uses Microsoft's cloud files API, on macOS version 3.0 is a Finder extension, and on Linux it ships as an AppImage since 3.0.12 and mounts at ~/SeaDrive. Encrypted libraries work on all three desktop platforms. The mobile apps exist to reach files, and that is all they try to do.

Nextcloud's desktop client also offers virtual files, and its mobile apps carry the rest of the platform, so calendar, contacts, Talk and notes arrive alongside file access. If your users live on phones and want more than files, that is a real difference in daily use.

One Seafile detail deserves planning: the library is the unit of sharing, sync, permissions and encryption. Decide your library layout before you load 500 GB into a single library, because a move between libraries is a copy and a delete, not a rename, so the file's history does not travel with it.

Encryption: what each one actually protects

Seafile's encrypted libraries are client side. The password is never stored on the server. A magic token derived from the password and the library id is stored with the library, so a client can check the password before it syncs. The file key is encrypted with a key and IV (initialisation vector) derived from your password using AES 256/CBC, and the file data is encrypted with that file key.

Read the documented limits, because people miss them. An encrypted library encrypts file contents only. Folder and file names are not encrypted, and neither are file sizes or the edit history. Browsing an encrypted library in a web browser is not end to end: you type the password, the server uses it to decrypt the file key, and it caches the password in memory for one hour. The manual is also plain that an encrypted library does not ensure integrity, because a server admin can change part of a file's contents and the client cannot detect it.

Nextcloud has two features with confusingly similar names. Server side encryption encrypts files at rest but keeps the keys on the same server, so it protects data held on external storage far better than it protects you from someone with root on the box. The end to end encryption app encrypts chosen folders on the client, and by design the server cannot read them, so the web interface, server side search and previews cannot see inside those folders either.

Neither product's encryption replaces an encrypted backup. Encrypt the backup on its own.

Calendars, contacts, office and the app platform

This axis is not close. Nextcloud ships CalDAV (calendar over WebDAV) and CardDAV (contacts over WebDAV) in core, integrates Collabora or OnlyOffice for documents, and has an app store for everything else. Seafile 13 ships SeaDoc for collaborative documents and wiki pages, and stops there. There is no calendar and no address book.

The platform has a price, and the price is upgrades. Every app you install is another thing that can block a Nextcloud upgrade or misbehave after it, so the more your users depend on, the more careful your upgrade window becomes. Seafile has less to break because it does less. Note also that Seafile Professional, not the Community Edition, is what adds full text search inside documents and folder level permissions under a paid licence, so confirm the feature you are counting on is in the edition you plan to run.

The failure mode each one is known for

Seafile fails when the database and the object store drift apart. You see a library that will not open, or files that vanish, and seaf-fsck.sh prints the missing block. There is no file tree to repair by hand, so recovery is your database dump plus your object store, restored in the right order. Test that restore on a spare VPS once, because a backup you have never restored is a guess.

Nextcloud fails when the file cache and the disk disagree, usually because something wrote into the data directory without telling Nextcloud. You see a file on disk that the web interface does not list, or a folder whose size is wrong, and occ files:scan is the fix. Its other two sore points are protocol speed on many small files, which no amount of CPU repairs, and PHP memory: previews for large images and videos are the usual spike, so keep 512 MB per process and generate previews in a scheduled job rather than during requests.

Neither one: Syncthing, if you only want file sync

If your real requirement is one folder mirrored between machines, both products are more software than you need. Syncthing has no server and no accounts. Every device is a peer, and a VPS becomes the peer that stays awake when your laptop sleeps. Syncthing 2 is the current line, and the packages come from the project's own repository:

sudo mkdir -p /etc/apt/keyrings
sudo curl -L -o /etc/apt/keyrings/syncthing-archive-keyring.gpg https://syncthing.net/release-key.gpg
echo "deb [signed-by=/etc/apt/keyrings/syncthing-archive-keyring.gpg] https://apt.syncthing.net/ syncthing stable-v2" | sudo tee /etc/apt/sources.list.d/syncthing.list
sudo apt-get update
sudo apt-get install syncthing

Run it as a normal user, never as root, so the files it writes have sane ownership:

sudo systemctl enable --now syncthing@youruser
systemctl status syncthing@youruser

The web interface binds to 127.0.0.1:8384 by default, so it is not reachable from the internet, which is the correct default. Reach it through an SSH tunnel from your laptop:

ssh -L 8384:127.0.0.1:8384 youruser@your-server

Then open http://127.0.0.1:8384 on the laptop. Sync itself uses port 22000 over TCP and QUIC, and local discovery uses UDP 21027, which does nothing across the internet. On a VPS, open 22000 and leave the interface closed:

sudo ufw allow 22000/tcp
sudo ufw allow 22000/udp

What you give up is every server feature: no share links for people who do not run Syncthing, no web file browser, no user accounts, and no server side trash unless you enable file versioning per folder. The classic surprise is the conflict file. Edit one file on two devices while they cannot see each other, and you get a sibling named like notes.sync-conflict-20260806-142233-ABCD1EF.md. Nothing warns you, so search for sync-conflict from time to time.

If what you want is not a synced folder but a bucket that applications write to, that is a different tool again: see self-hosted S3 compatible object storage. For the wider field, the roundup of self-hosted Dropbox alternatives covers what did not make this comparison.

The decision rule

1. Choose Seafile if the job is sync at size: many files, large files, several devices, and you accept a data store only Seafile can read.
2. Choose Nextcloud if the job is a platform: calendars, contacts, documents and share links, with plain files on disk that any backup tool can read.
3. Choose Syncthing if the job is a mirrored folder and nothing else.

Choose carefully now, because the migration between Seafile and Nextcloud is the real lock in. There is no converter. You sync everything down to a client, upload it into the other server, and pay in bandwidth and time while version history and share links stay behind. Sizing today's choice for the next three years is cheaper than switching in year two.

FAQ

Is Seafile faster than Nextcloud for syncing large libraries?

Yes in the two cases that usually hurt, and for a reason you can verify. Seafile splits files into blocks that average about 8 MB and transfers only the blocks that changed, so an edit inside a large file moves a few blocks. Nextcloud's unit of transfer is the whole file, so the same edit re-uploads all of it, and many small files each cost at least one WebDAV request, which is why its bulk upload API packs small files together. Time both on your own VPS before committing, because your CPU, disk and network link matter as much as the protocol.

Can I back up Seafile by running rsync on the data directory?

Only together with the databases, and in the documented order. Seafile's manual says to back up the SQL first and the data directory afterwards, because then every database record refers to an object that exists in the backup. The command rsync -az /opt/seafile-data/seafile /backup/data/ copies conf, seafile-data and seahub-data, but on its own it is not restorable, because the object store holds no readable file tree and the database is its index. After restoring both halves, run seaf-fsck.sh and read its output before you trust the result.

Do I need Nextcloud if I only want file sync?

No. Nextcloud is a platform, and the calendar, contacts and app store cost you memory and upgrade care whether you use them or not. For plain file sync, Seafile is the lighter product with the faster protocol, and Syncthing is lighter still because it has no server side to run. Pick Nextcloud when you want the extra applications, not as a default.

Does an encrypted Seafile library hide my file names?

No. An encrypted library encrypts file contents on the client and the password never reaches the server, but folder names, file names, file sizes and the edit history all stay visible on the server. Opening an encrypted library in the web interface also sends the password to the server, which decrypts the file key and keeps the password in memory for one hour. If the names themselves are sensitive, keep that library out of the web interface and encrypt at another layer.

How much RAM should I give Seafile or Nextcloud on a VPS?

Start at 4 GB with 2 cores for either one with a handful of users, then watch memory during preview generation and search. Seafile's own docs set the floor at 2 GB of RAM and a 2 core CPU above 2 GHz. Nextcloud documents 512 MB per PHP process as its recommendation, which you multiply by worker count before adding the database and cache. Syncthing runs comfortably in 1 GB.