Every Nextcloud vs ownCloud vs Seafile thread ends up arguing about RAM, and most of the numbers come from vendor pages. We wanted our own figures first, because this choice decides what runs on your home server for years. An idle Nextcloud used far less memory than its reputation suggests, and Seafile used the most. The “OpenCloud needs about 100 MB” claim also holds only until you add the office suite its compose file ships with.
This comparison covers Nextcloud, ownCloud (Classic and Infinite Scale), OpenCloud, Seafile and Syncthing. It explains how ownCloud 10, oCIS and OpenCloud relate and puts the measured RAM, disk and startup time of each stack in one table. For Cloudreve, FileBrowser or Immich, see our Cloudreve and Immich comparison. We ran all six stacks one at a time on the same Ubuntu 26.04 VM in our homelab in October 2026, and every RAM figure below comes from that box.
Which one should you pick?
Pick by the job the server has to do, not by which project sounds lightest. Do you need calendars, contacts, chat and office editing behind one login? Then the decision is already made. If you only need files on every machine, a full cloud suite costs RAM and patching time for features you will never open. Our picks by job:
- Family or small office Google Drive replacement: Nextcloud
- Light file sync and sharing on small hardware: OpenCloud or oCIS
- Large libraries with many small files: Seafile
- Folders mirrored between your own devices: Syncthing
- An existing ownCloud 10 server: move to Classic 11, oCIS or OpenCloud
Nextcloud wins on breadth, with calendar, contacts, office and the biggest app catalog. oCIS idles at 95 MiB in one container. OpenCloud plus the Traefik and Yjs containers its compose adds comes to about 151 MiB, before Collabora. Seafile is fast with big libraries but was the heaviest stack we ran. People most often get Syncthing and ownCloud wrong. Syncthing has no user accounts, no web file browser, no share links and no central copy unless you dedicate a machine to it. ownCloud is now three products under one name, and nobody should start a new server on ownCloud 10.
Nextcloud vs ownCloud vs Seafile vs Syncthing vs OpenCloud at a glance
The table lines up what each project is built on and what you get on day one. RAM is the idle total we measured for each official Docker setup, database and cache containers included:
| Project | Server stack | Database | Idle RAM (measured) | Office editing | CalDAV / CardDAV | Clients |
|---|---|---|---|---|---|---|
| Nextcloud | PHP + Apache | MariaDB, MySQL or PostgreSQL | 332 MiB (3 containers) | Nextcloud Office (Collabora) or OnlyOffice | Yes, Calendar and Contacts apps | Desktop, Android, iOS |
| ownCloud Classic | PHP | MariaDB, MySQL or PostgreSQL | 203 MiB (3 containers) | Collabora or OnlyOffice through apps | DAV endpoints in core | Desktop, Android, iOS |
| ownCloud Infinite Scale (oCIS) | Go, single binary | None | 95 MiB (1 container) | Collabora or OnlyOffice over WOPI | Not built in | Desktop, Android, iOS |
| OpenCloud | Go, fork of oCIS | None | 590 MiB with Collabora, about 151 MiB without it, 91 MiB for OpenCloud itself | Collabora or Euro Office overlays in the official compose | Optional Radicale overlay | Desktop, Android, iOS |
| Seafile CE | C core + Python web app | MariaDB | 698 MiB (4 containers) | SeaDoc, OnlyOffice or Collabora integration | No | Desktop, Android, iOS |
| Syncthing | Go, peer to peer | None | 25 MiB (1 container) | No | No | Desktop, community Android fork |
Most of the RAM gap comes from the database. The PHP servers carry MariaDB at 99 to 125 MiB on their own, while oCIS, OpenCloud and Syncthing keep metadata on disk and run as one process. Seafile goes the other way, because its database used only 109 MiB but the Seafile container sat at 571 MiB idle before we uploaded a single file.
Measured RAM and disk footprint of each stack
All six stacks ran on one Proxmox VM called nas01 (Ubuntu 26.04.1, 4 vCPU, 8 GB RAM, no swap, Docker Engine from the Docker apt repository). We ran one stack at a time and removed it with its volumes before starting the next. Each came from the official images and compose files, with an admin account created so the app was fully set up:
| Stack (version tested) | Idle RAM | Peak during 1 GiB upload | 120 s after upload | Upload time | Images on disk | Ready after start |
|---|---|---|---|---|---|---|
| OpenCloud 8.1.0 + Collabora + Traefik + Yjs | 590 MiB | 750 MiB | 625 MiB | 10.8 s | 2.66 GB | 8 s (web UI) |
| oCIS 8.2.2 | 95 MiB | 190 MiB | 127 MiB | 5.9 s | 331 MB | 7 s |
| Nextcloud 35.0.2 + MariaDB + Redis | 332 MiB | 377 MiB | 363 MiB | 8.6 s | 2.75 GB | 51 s |
| ownCloud Classic 11.0.1 + MariaDB + Redis | 203 MiB | 252 MiB | 275 MiB | 11.2 s | 2.55 GB | 26 s |
| Seafile CE 14.0.9 + MariaDB + Redis + Caddy | 698 MiB | 856 MiB | 780 MiB | 17.0 s | 2.91 GB | 44 s |
| Syncthing 2.1.7 | 25 MiB | 27 MiB | 28 MiB | 4.2 s to scan | 72 MB | 1 s |
Idle RAM is the median of three docker stats readings taken 20 seconds apart, after 300 seconds untouched. Docker reports cgroup memory minus inactive file cache, so it is close to the memory you actually lose to the app. The upload was one 1 GiB random file sent by the admin user from the VM itself, so the network is out of the picture. Nextcloud and the three ownCloud-family servers took it over WebDAV, and Seafile through its web API because SeafDAV is off by default. Syncthing has no upload path, so we copied the file into its folder and timed the scan. We sampled peaks about every 2 seconds, so treat them as lower bounds, and memory measured after the upload can exceed the sampled peak, as it did for ownCloud Classic.
The reading that surprised us most was the OpenCloud stack at idle:
OpenCloud itself idled at 91 MiB, close to the “about 100 MB” that a managed-hosting vendor’s comparison gives for it. Collabora, which the official compose starts alongside it, used 438 MiB with no document open. The Yjs relay for real-time collaborative editing added another 41 MiB, and Traefik 18 MiB. A fair comparison with Nextcloud is therefore about 151 MiB for OpenCloud without the office suite (OpenCloud, Yjs and Traefik added together) and 590 MiB with it. The same vendor table puts Nextcloud at 1 to 2 GB (PHP-FPM, database and Redis), yet our empty single-user Nextcloud on the Apache image used 332 MiB with its database and Redis. Nextcloud grows with users, apps and PHP workers, so that range likely describes a loaded server rather than a fresh install.
Disk tells a different story. The Nextcloud images take 2.75 GB. Its app volume held another 906 MB right after setup, because the image copies the whole code tree into the volume on first start. oCIS needs 331 MB of image and about 1 MB of data. The OpenCloud image is 304 MB, but Collabora alone is 1.84 GB. The single binaries also start fastest, with oCIS answering WebDAV after 7 seconds while Nextcloud spent 51 seconds in its first-boot installer.
1. Nextcloud: the full self-hosted suite
Nextcloud forked from ownCloud in 2016 and is the safe default if you want more than files. The current major is Nextcloud 35 (Hub 26 Summer), running on PHP 8.3 to 8.5 with MariaDB, MySQL or PostgreSQL. You enable Calendar, Contacts, Talk and Nextcloud Office from the admin panel, and those apps are why families and small offices end up here.
The Files app below comes from the test stack, with sample folders plus the skeleton files every new user gets.
You pay for that breadth in moving parts. A working Nextcloud needs PHP, a web server, a database, Redis for file locking and a background job runner, and each one needs patching and backups. The official Docker README example does not set REDIS_HOST, so its Redis container sits unused until you add that variable, as we did. For a native install without Docker, follow our Nextcloud on Ubuntu 26.04 guide.
Skip Nextcloud if you will never open the calendar or office apps. You would be carrying a database and a PHP stack for a sync job that OpenCloud or Seafile does with fewer components.
2. ownCloud Classic, oCIS and OpenCloud: how they relate
The name “ownCloud” now covers three code bases, and most old tutorials describe the one you should not start on. In the order they appeared, the pieces are:
- ownCloud 10, the PHP code base Nextcloud split from in 2016 (at version 9)
- ownCloud Classic 11, its July 2026 successor, supported only on Docker
- ownCloud Infinite Scale (oCIS), a Go rewrite with no database
- OpenCloud, the oCIS fork launched in January 2025
ownCloud 10 still gets patch releases, and Classic 11 needs PHP 8.3 or newer. Kiteworks bought ownCloud in November 2023, and the Heinlein Group then started OpenCloud with former ownCloud developers. Both Go servers use the Apache-2.0 license and have kept shipping, so they are now separate products with one architecture. On Docker Hub, owncloud/server:latest still points at the 10.16 line, so a pull without a tag gives you ownCloud 10. Pin owncloud/server:11.0.1 or later. If you run ownCloud 10 today, choose Classic 11 to keep your PHP apps, or oCIS and OpenCloud for the lighter Go server without the classic app ecosystem.
Classic 11 looks and behaves like the ownCloud most people remember. At 203 MiB idle with MariaDB, it was lighter than Nextcloud in our run.
oCIS runs as one container with no database. At 95 MiB idle, it was the lightest complete web file server stack in the test, although the OpenCloud process alone used 91 MiB before its compose added more containers. OpenCloud inherited the same web interface, so the two look almost alike.
Both Go servers organize files into spaces, with a personal space per user plus shared project spaces, instead of one big folder tree. Plan for that before you migrate a team that relies on deep shared folders, because the old structure does not map one to one.
3. OpenCloud: the Infinite Scale fork
Choose OpenCloud if you want the oCIS design from a vendor other than Kiteworks. A minor release lands roughly every three weeks, and the official opencloud-compose repository wires it up with Traefik, Let’s Encrypt and Collabora, plus optional overlays for Radicale (CalDAV and CardDAV), Keycloak and antivirus. The project’s own requirements page asks for 512 MB of RAM for up to 10 users and 8 GB for about 1,000 users.
The footer in that screenshot reads “OpenCloud 8.1.0 rolling”, and the word rolling matters. OpenCloud publishes two image channels. The 8.x releases exist only in the rolling one, which opencloud-compose pulls by default.
Error: “docker.io/opencloudeu/opencloud:8.1.0: not found”
We hit this after pointing the compose file at the production image, since the .env comment says production releases live in opencloudeu/opencloud. Docker refused the pull with this message.
Error response from daemon: failed to resolve reference "docker.io/opencloudeu/opencloud:8.1.0": docker.io/opencloudeu/opencloud:8.1.0: not foundThe production repository tops out at 7.2.4, published in August 2026, while 8.0 and 8.1 are only tagged in opencloudeu/opencloud-rolling. You have two valid choices: stay on the 7.2 production line if you want the slower, supported channel, or set OC_DOCKER_IMAGE=opencloudeu/opencloud-rolling and accept that you are running the fast release train. We measured the rolling 8.1.0 image, since that is what the compose repository ships.
On first start, the Traefik ACME registration also failed with contact email has forbidden domain "example.org", because the example .env leaves the contact address at a placeholder. Set your own address before the first docker compose up, or Traefik serves its self-signed default certificate.
4. Seafile: block sync for big libraries
Seafile takes a different approach from everything above. It splits files into blocks inside “libraries” and syncs only changed blocks, so large folders with many small files sync quickly. A library can also carry its own password, which the desktop client uses to encrypt files before they leave your machine. In return, your files are not stored as plain files on the server disk. A backup has to copy the Seafile data directory and its database together.
It was also the heaviest stack we measured: 698 MiB idle across four containers, with the Seafile container alone at 571 MiB, which is consistent with the 2 GB of RAM recommended in the Seafile Docker setup manual. Two defaults surprise people coming from Nextcloud. WebDAV (SeafDAV) stays disabled until you set ENABLE_SEAFDAV=true in the .env file and recreate the stack with docker compose up -d, because a plain docker compose restart, which the Seafile WebDAV page suggests, does not pick up changed variables. The official .env also lists the SeaDoc editor in COMPOSE_FILE, so it starts unless you remove it. We left SeaDoc out, so the numbers above are for Seafile without its document editor. For a step-by-step setup, see the Seafile Docker install guide.
Seafile returns an empty page on localhost
Our first readiness check requested http://127.0.0.1/ and got HTTP 200 with an empty body. The token request after it failed with JSONDecodeError: Expecting value: line 1 column 1 (char 0). The Caddy proxy in the official compose only routes the hostname set in SEAFILE_SERVER_HOSTNAME, so any other name falls through to an empty response. Use that exact hostname in health checks and API calls.
5. Syncthing: sync without a server
Syncthing keeps folders identical across your devices over an encrypted peer-to-peer link, and nothing else. It has no accounts, no web file browser for other people and no share links. That is why it idled at 25 MiB, and also why it does not replace Nextcloud. For a central copy, run Syncthing on a home server and let every laptop and phone sync with it, as our Syncthing on Ubuntu guide sets it up.
Mobile support is the weak spot. The official Android app was discontinued with the December 2024 release, so Android users now run the community fork researchxxl/syncthing-android, which tracks Syncthing releases. No official iOS app exists either. On the server, our Syncthing container started with no folder configured, so you add the first folder in the GUI or through the REST API.
6. Size the home server for the stack you pick
The idle numbers set the floor, not the target. Every stack grew under a single 1 GiB upload, and real use adds thumbnails, search indexing, previews and more users. Our own RAM guidance per stack, with headroom above the vendor minimums:
- Syncthing, oCIS or OpenCloud without Collabora: 2 GB
- Nextcloud or ownCloud Classic with MariaDB: 4 GB
- Seafile, or any stack plus Collabora: 4 GB recommended, 8 GB comfortable
- Disk: 3 to 4 GB for images and app files, about 6 GB with Collabora
Storage matters more than CPU for all of them, because the data outgrows the app within weeks and none of these servers is CPU bound at home scale. If the files are going onto a dedicated NAS, our 8-bay NAS picks cover enclosures with room to grow, and the home server CPU guide helps if Collabora, thumbnails or a media server will share the same box. For office editing on a separate host, the Collabora Online setup keeps those 438 MiB off your file server.
