Nextcloud alternatives worth self-hosting

Which Nextcloud alternatives are worth self-hosting?

The Nextcloud alternatives worth running are the ones that drop the parts you never used. Nextcloud is a file server, a calendar, a contact book, an office suite and an app platform inside one PHP application, and you pay for all of it on every page load. So pick a replacement by naming the one job you still need, then check what it costs to move the files you already have.

This guide sorts the options by that job: sync only, sync with a faster server, object storage with a client on top, or plain remote file access. Each section says what the server needs on a small VPS (virtual private server) and what happens to your existing folder tree. If you are arriving from Dropbox or Google Drive rather than from a Nextcloud box you already run, the wider roundup of self-hosted Dropbox alternatives starts from that side instead.

Why Nextcloud gets slow on a small VPS

The slowness has causes you can point at, and knowing them tells you whether leaving will actually help.

Every page load occupies a PHP worker. Nextcloud's own system requirements state memory per process: 128 MB minimum, 512 MB recommended, as of August 2026. That is not a server total. A pool of ten workers is a real memory budget on a 2 GB plan, so admins lower pm.max_children in the PHP-FPM pool config, and then requests queue behind the workers that exist. The interface feels slow while the disk is idle.

The database grows with file count, not with bytes. The file cache table, oc_filecache under the default table prefix, holds one row for every file and folder in every storage the server knows about. A photo library of 300,000 small files is a large table; 300 GB of video files in 400 files is a small one. Sharing, search and the file scanner all read that table.

sudo mysql nextcloud -e 'SELECT COUNT(*) FROM oc_filecache;'

A count in the millions explains a slow file list better than any disk benchmark will. If your instance uses a different table prefix or PostgreSQL, adjust the query.

Background jobs compete with the web interface. Nextcloud's manual recommends a system cron entry running cron.php every five minutes. Preview generation and file scanning run there, on the same CPU that serves your browser.

Major upgrades are a database migration. The instance goes into maintenance mode and answers every request with Nextcloud is in maintenance mode, please try again later until the migration finishes. On a small VPS with a large oc_filecache, that window is long enough to notice.

Decide what you are keeping first

• Sync one folder between machines you own, with no web interface: Syncthing.
• Sync for several people, with a web interface, mobile clients and share links: Seafile.
• Store a lot of data cheaply and reach it from scripts and backup tools: object storage plus a client.
• Read and write your files remotely with no new server software: SFTP or WebDAV.
• Edit documents together in a browser, or share a calendar between people: stay on Nextcloud, or accept running two services.

Syncthing: file sync with no server application

Syncthing keeps your files as ordinary files. There is no content database and no web interface that serves your documents. Every device that joins a folder holds a full copy, and Syncthing keeps the copies equal.

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

sudo systemctl enable --now syncthing@$USER
sudo ss -lntp | grep 8384

A line showing 127.0.0.1:8384 means the web interface is running and bound to localhost only, which is what you want on a public VPS. Reach it with an SSH tunnel: ssh -L 8384:127.0.0.1:8384 you@your-vps, then open http://127.0.0.1:8384 on your laptop. No listener on 8384 means the service failed to start, and journalctl -u syncthing@$USER -n 50 says why.

Resources. Syncthing publishes no minimum memory figure. What it uses tracks the number of files it indexes rather than their total size, because it keeps an index entry per file per shared folder. The first scan of a large folder is CPU work: Syncthing hashes every file before it can compare anything. Expect that first pass to run for a while on a shared vCPU, and expect memory to climb with file count rather than with gigabytes.

Disk is the real cost. There is no server-side saving, because Syncthing is not a server. A 200 GB folder shared between a VPS and a laptop needs 200 GB on both. That is the opposite of Nextcloud, where the server holds everything and clients pick what to sync. Use selective folders and a receive only folder on the VPS if the VPS is meant to be a backup target rather than a peer.

Migration is the reason to pick it. Point Syncthing at the directory tree you already have. There is no import, no upload and no conversion. Add the folder on the VPS, add it on the laptop with the same folder ID, and let the two sides converge. If the same file exists differently on both sides at first contact, Syncthing keeps both and renames one to filename.sync-conflict-20260809-142530-ABCD123.txt. Seeing those files is normal on the first sync, not a failure.

What you give up. No accounts, no share links to send to other people, and no way to browse your files from a phone browser. The original Android app is no longer maintained by the project itself and a community fork carries it forward, which matters if mobile access is the point. The direct comparison of Syncthing and Nextcloud goes through the feature gaps one by one.

Seafile: fast sync with a lighter server

Seafile splits the work in two. A Python web application called Seahub draws the interface, and a separate C process handles sync traffic. Your file transfers do not pass through the web application, which is why a large upload stays fast while somebody else is clicking around the interface. Version 13.0 was released on 5 January 2026.

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

Edit .env before starting anything. It sets SEAFILE_SERVER_HOSTNAME, INIT_SEAFILE_ADMIN_EMAIL, INIT_SEAFILE_ADMIN_PASSWORD, SEAFILE_MYSQL_DB_PASSWORD and JWT_PRIVATE_KEY, which must be a random string of at least 32 characters. That file also tells compose which of the downloaded YAML files to read, so the four downloads act as one stack.

cd /opt/seafile
sudo docker compose up -d
sudo docker compose ps

Every container should report a running state. A container restarting in a loop is almost always a value missing from .env, and sudo docker compose logs seafile names which one.

Resources. Seafile's documentation asks for at least 2 GB of RAM and a 2 core CPU above 2 GHz, as of August 2026. Read that as the floor for the whole stack, because the Docker deployment also starts MariaDB, the Caddy reverse proxy and the SeaDoc editor. Give it 4 GB if more than one or two people use it, or leave out the optional containers.

The migration catch is the storage format. Seafile does not keep your files as files. It splits each one into blocks under /opt/seafile-data and records the tree in its database. You cannot point Seafile at an existing directory and have it appear as a library, so moving in means one full upload pass over everything you own. The same design means you cannot get data back out with cp: recovery goes through the server, seaf-fsck for consistency checks, or the read-only seaf-fuse mount.

rclone has a native Seafile backend, which turns that upload into one resumable command instead of a long drag-and-drop session.

rclone config
rclone copy /srv/files seafile:MyLibrary --progress

The rclone documentation lists Seafile 6.x through 9.x as tested, so run it against one small folder and check the result before pushing a terabyte through it.

Encrypted libraries are the feature people move for. The password is set in the client, and the server stores blocks it cannot read. One honest caveat: previewing a file from an encrypted library in the browser sends the password to the server for that session, so browser preview and zero-knowledge storage are not available at the same time. The Seafile and Nextcloud head to head covers the rest of the feature trade.

Object storage with a sync client on top

If the goal is many bytes stored cheaply and reachable from scripts, run an S3 compatible object store and treat sync as a separate tool. You get durability, versioning and a protocol every backup tool already speaks. You do not get user accounts in the file-server sense or a file manager anyone will enjoy. Self-hosted object storage with MinIO covers the server side.

rclone copy /srv/files s3remote:mybucket --progress
rclone check /srv/files s3remote:mybucket

rclone check compares both sides by size and hash and prints how many files differ. Anything other than zero errors means the copy is incomplete, so run copy again before you delete the source. Two things to expect: object storage has no directories, only key prefixes, so an empty folder does not survive the copy; and raising --transfers together with the S3 chunk size is what drives rclone's memory use up, so leave both at their defaults on a 1 GB VPS.

Plain WebDAV or SFTP when you only need remote files

The cheapest replacement is often nothing new. If your VPS runs OpenSSH, you already have a file server. SFTP costs no extra daemon, no database, no PHP, and no upgrade that can break on a Sunday.

sftp you@your-vps
rclone mount sftpremote: ~/vps --vfs-cache-mode writes

For clients that speak WebDAV, including most phone file managers, rclone can serve the same tree.

sudo apt install apache2-utils
sudo htpasswd -c /etc/rclone/htpasswd you
rclone serve webdav --addr 127.0.0.1:8080 --htpasswd /etc/rclone/htpasswd /srv/files

Bind it to 127.0.0.1 and put a reverse proxy with TLS (transport layer security) in front. WebDAV basic authentication sends the password on every single request, so plain HTTP here means handing over the password many times a minute. Migration cost is zero, because the files never move. The cost is that there is no sync and no offline copy: when the link drops, the files are gone from the client until it comes back.

What replaces calendars, contacts and document editing

Leaving Nextcloud costs you something here, and it is worth being clear about what. Calendars and contacts are CalDAV and CardDAV (calendar and contact synchronisation over HTTP), and Radicale is the small replacement. It stores each collection as files on disk and runs in tens of megabytes.

sudo apt install radicale
sudo systemctl enable --now radicale
sudo ss -lntp | grep 5232

The package ships /usr/lib/systemd/system/radicale.service and its default config at /etc/radicale/config, listening on localhost:5232. Radicale has no interface for editing events, so you point a phone or desktop client at it and edit there.

Browser document editing is harder to replace. OnlyOffice Docs and Collabora Online are both editing engines, not storage: each one needs a host application that holds the files and hands documents over. Take Nextcloud away and you need another host, such as Seafile with its own SeaDoc editor. The OnlyOffice and Collabora comparison covers which engine to run once you have decided what hosts it.

Stay on Nextcloud if any of these are true

• Several people share one calendar and one address book, on the same accounts as the files.
• You edit office documents in the browser, in the same file, at the same time as somebody else.
• You need per-file share links with expiry dates and passwords, plus group permissions.
• Your users are not technical, and the mobile apps are what they actually use.

For those jobs there is no lighter answer that does all of it, and the honest move is to fix the install rather than leave it. Most slow instances are running a default PHP-FPM pool with no memory cache configured, and Nextcloud's admin overview page warns about the missing cache. Trimming the number of tracked files helps more than any other single change, because the file cache table is what grows. A Nextcloud install on a VPS with Docker, TLS and backups sets it up the way that avoids most of this.

What migration actually costs, option by option

• Syncthing: no import. Point it at the tree you already have on both sides and let it converge.
• SFTP or WebDAV over the same tree: no import at all, because nothing moves.
• Object storage: one full network copy, resumable and scriptable, and empty folders do not survive it.
• Seafile: one full upload into libraries, because the server keeps blocks rather than files.

Whichever you pick, get a clean copy out of Nextcloud first. User files live under the data directory in plain form, one folder per user, so rsync of that tree is your source. Put the instance into maintenance mode before you copy, or you will copy files mid-write.

sudo -u www-data php occ maintenance:mode --on
sudo rsync -a --info=progress2 /path/to/nextcloud/data/ /srv/files/
find /srv/files -type f | wc -l

Compare that count against the same find on the source. A shortfall usually means permissions stopped rsync reading something, and it prints those errors as it goes.

Two traps sit in that copy. Files reached through Nextcloud's external storage feature are not in the data directory at all, because they live on the remote system Nextcloud was told about. And if server-side encryption was ever enabled, the files on disk are ciphertext, so occ encryption:decrypt-all has to run before the copy or you will move a folder of unreadable data. Check both before you cancel anything.

FAQ

Is there a Nextcloud alternative that keeps my existing folder structure?

Syncthing, and any plain SFTP or WebDAV setup. Syncthing indexes the directory you point it at and keeps the same names and layout on every device, so there is no import step and no upload. Seafile and object storage both need one full upload pass, because neither stores your data as ordinary files in an ordinary tree. Seafile splits files into blocks under its data directory, and object storage has keys rather than directories.

Will Seafile run on a 2 GB VPS?

Seafile's documentation asks for at least 2 GB of RAM and a 2 core CPU above 2 GHz, as of August 2026. Read that as a floor with no headroom, because the Docker deployment also runs MariaDB, Caddy and the SeaDoc editor in their own containers. For a single user it is workable. For a household or a small team, move to 4 GB, or leave the SeaDoc container out of the stack and give up in-browser document editing.

Why is my Nextcloud web interface slow when downloads are still fast?

Because the two paths do different work. A download streams bytes from disk, while a page load runs PHP, queries the file cache table and often waits for a free PHP-FPM worker. Count the rows in oc_filecache and check pm.max_children in your PHP-FPM pool before blaming storage. A table with millions of rows and a pool of five workers produces exactly this pattern.

Can I keep Nextcloud for calendars and move only the files?

Yes, and it is often the cheapest answer. Sync your large folders with Syncthing or Seafile, and leave Nextcloud running for CalDAV, CardDAV and browser document editing. Because Nextcloud's database grows with the number of files it tracks, removing the big trees from it is what makes the interface quick again. Delete them through the web interface or occ, not from the data directory on disk, or the database keeps rows pointing at files that no longer exist.