OpenCloud or Nextcloud: which should you self-host for file sync?

Self-host OpenCloud if you want file sync and sharing and nothing else, and Nextcloud if you want calendar, contacts and the rest of a groupware suite in the same login. OpenCloud runs without a database and starts at 512 MB of RAM. Nextcloud needs PHP, a real database and three major upgrades a year, and in exchange it is a suite rather than a file server. Most people asking this question want files, which is why OpenCloud deserves the look.

What OpenCloud is, and why it looks familiar#

OpenCloud is a fork of ownCloud Infinite Scale (oCIS), the Go rewrite of ownCloud. The Heinlein Group, the company behind mailbox.org, announced it on 22 January 2025 as a subsidiary, with more than a dozen former ownCloud developers on the team, and heise reported at the time that ownCloud's owner Kiteworks threatened to sue. OpenCloud says it forked only the public oCIS code. The licence is Apache 2.0.

That history matters for one reason: this is the third branch of the same family tree. Nextcloud was the 2016 fork of PHP ownCloud. OpenCloud is the 2025 fork of the Go rewrite. They share an ancestor and almost nothing else, so experience with one does not transfer to the other.

What each one asks of the server#

OpenCloud's requirements page says no database is required because it stores everything on storage systems, which it says reduces complexity and improves reliability. The minimal tier names a Raspberry Pi 3 as its example. The filesystem list is not decoration: both file drivers need a POSIX filesystem with atomic read-after-write consistency for directory metadata, and PosixFS also needs extended attributes. SMB shares and NFS older than 4.2 are not on it.

Nextcloud's page measures memory differently, per PHP process, because that is how it grows: 128 MB minimum and 512 MB recommended per process, at least 256 MB for the built-in updater. The current edition of the manual recommends MariaDB 11.8 or PostgreSQL 18 and PHP 8.5, with 8.3 and 8.4 supported.

The groupware line: what OpenCloud does not do#

OpenCloud is a file platform. It syncs and shares files. Calendar and contacts are not built in. Since 2.3.0, OpenCloud can act as an authenticating reverse proxy for Radicale, a separate CalDAV and CardDAV server: you add the opencloudeu/radicale container, OpenCloud forwards /caldav and /carddav to it, and Radicale creates a calendar and an address book for each user. Desktop and mobile CalDAV and CardDAV clients connect to it directly.

The catch is in OpenCloud's own wording. The feature is, until further notice, intended for non-customers, is not covered under the business licence, and is supported on a best-effort basis without warranty. It is a second service with its own data that you back up separately.

If your household lives in Nextcloud's calendar, contacts and shared documents, this is the end of the comparison: stay on Nextcloud, and read Nextcloud vs Seafile if the complaint was sync speed rather than the suite.

Upgrade day: a PHP calendar against a release channel#

Nextcloud's schedule is published and fixed. New majors every four months, each supported for one year through monthly maintenance releases. 32 reached end of life in September 2026. 35 shipped on 16 September 2026. You cannot skip a major, so a server still on 32 goes 32 to 33 to 34 to 35, one migration run at a time, and each step has its own PHP and database window. An update strategy that does not lose data is how you keep that routine.

OpenCloud gives you a choice of channel, and the choice is the trap. Its lifecycle page lists three:

• Rolling, every three weeks, marked "for enthusiasts", community supported.
• Production, about every six months, full quality assurance. 7.2 is the current one, dated 25 June 2026.
• LTS, two years of backports, only for customers with a professional or premium subscription.

Run Production. The 7.x upgrade guide accepts both 6.x rolling and 4.0.x stable as starting points, so a production install moved from 4.0 to 7.x in one step. The steps are not a tag bump, though:

docker compose stop
docker pull opencloudeu/opencloud:7.x.x
# in a temporary container from the new image
opencloud init --diff        # apply the generated patch to opencloud.yaml
docker compose up -d --remove-orphans
docker compose exec opencloud opencloud search index --all-spaces

The guide calls the configuration patch mandatory before the upgraded instance starts, and warns that first startup can take several minutes while space memberships migrate. No database migration, because there is no database. Configuration drift is the OpenCloud failure, where Nextcloud's is a database migration.

Backups: no dump, but not just files either#

This is the part the vendor pages skip, and it is where the two circulating claims both go wrong. One says OpenCloud has no database, so backing it up is a file copy. The other, carried over from oCIS, says its storage is an opaque tree you cannot read. On a new 2026 install, neither is right.

OpenCloud's backup page lists four things to keep: configuration data, system data, metadata and blobs. The search index is optional, and if you skip it you rebuild it after a restore. The instance must be stopped before the backup starts. The page prefers filesystem snapshots, which take seconds, then a copy to secondary storage.

What is on the disk depends on the driver:

• PosixFS is the default for new installations. User files sit in the folder structure users see in the web interface. Metadata lives in extended attributes on each file, and when it outgrows the filesystem's limit it moves to a separate metadata file with a reference left behind.
• DecomposedFS stores files in what OpenCloud's own docs call a technical folder structure with limited meaning for admins. Installs that predate the PosixFS default kept it, and there is no migration path from DecomposedFS to PosixFS.
• System storage stays decomposed on PosixFS installs too. The issue that made PosixFS the default says so in its acceptance criteria.
• decomposeds3 puts blobs in an S3 bucket and keeps configuration and metadata on a POSIX filesystem. You back up both halves, the bucket by your provider's procedure, and the docs state there is no migration path from other storage.

So a PosixFS install gives you readable files, which is real progress over oCIS. But a copy that drops extended attributes has dropped the metadata, and a copy of only the user tree has dropped the system data. With rsync that means -aX, not -a; with a ZFS or Btrfs snapshot of a stopped instance you get everything, which is why the docs prefer snapshots. The upgrade guide's own backup command, cp -a of the config and data directories, preserves extended attributes with GNU cp. A backup tool that strips xattrs will report success and restore files whose metadata is gone.

Nextcloud's backup is a different shape. The manual lists the config folder, the data folder, the theme folder, custom apps if you have them, and the database, taken with maintenance mode on (sudo -E -u www-data php occ maintenance:mode --on) and a mariadb-dump --single-transaction or pg_dump. Files are plain files, but shares, versions metadata and comments live in the database, so the dump and the copy have to come from the same moment. Backing up a running database explains why that ordering matters.

Both are restorable. Neither is restorable until you have tried. Backups that actually restore has the rehearsal, and restic vs BorgBackup picks the tool.

Which one for your situation#

Where this answer stops applying#

This compares fresh installs in October 2026. An existing OpenCloud or oCIS-derived install on DecomposedFS does not get the readable tree, because there is no migration to PosixFS. Nothing here covers moving data from Nextcloud to OpenCloud: they share an ancestor, not a storage format, so plan on a client-side copy. And the sizing figures are OpenCloud's own, which its requirements page says scale with request rate, device count, file count and integrated apps.

What to do next#

If files are the job, install OpenCloud from the Production channel, give it a filesystem that supports extended attributes (ZFS makes the snapshot advice trivial: ZFS, btrfs, mdadm or one disk), then stop it, snapshot it, restore into a scratch directory and check that shares survived. If the calendar is the job, stay on Nextcloud and schedule the upgrade windows. Moving off a commercial service first? Replace Google Drive and Replace Dropbox cover the migration, and the rest of the category is in Photos and files.