Nextcloud vs ownCloud vs Seafile: Measured Idle RAM

Nextcloud vs ownCloud vs Seafile comes down to scope and RAM. Pick Nextcloud for files plus calendar, contacts and online office: 297 MiB idle for the file server alone. Pick Seafile if files are the whole job: 616 MiB idle, 905 MiB peak. Pick ownCloud Infinite Scale for the smallest measured footprint: one container, 151 MiB idle (range 101 to 155, noisy), with fewer features (researched, not tested). Our sizing rule gives 1 GB, 2 GB and 1 GB for a one-user test of 103 files. Treat those as floors: ownCloud’s own documents call 4 GB a good production starting point, and Seafile’s call for 2G. We tested Infinite Scale, not ownCloud Classic.

The lab ran each app as a single user on a clean install. Nextcloud’s run (35.0.2) is from Oct 18, 2026 on an AMD EPYC 7763; Seafile and Infinite Scale ran on Oct 16 in separate jobs on EPYC 9V45. RAM and image sizes carry across hosts, timing rows do not. Seafile took its native upload API, the other two WebDAV, so the upload times are not ranked. We did not test sync clients, search, previews, office editing, LDAP or SSO, more than one user, or Arm hardware.

Side-by-side measured table

Source for every row marked Tested: nextcloud.json (run of Oct 18, 2026), seafile.json and owncloud.json (runs of Oct 16, 2026). Each figure is the median of three runs, with the lowest to highest run in brackets. Each app had its own GitHub Actions job (2 vCPU, 7.8 GiB RAM, Ubuntu 24.04.5, Docker 28.0.4, overlay2 image store), and all three runs of an app landed on one CPU model, shown in the first row. RAM is Docker’s working set. Idle is the mean of at least 10 samples over 30 s after the stack’s total memory had settled (how we measure idle RAM).

The medians and ranges in this table, and the sizing arithmetic, come from a script over the three result files. Its output for Seafile and Infinite Scale is saved in lab/notes/filesync-2026-10-16.md (its Nextcloud section is the Oct 8 run); the Nextcloud column is a script over the Oct 18 file, saved in lab/notes/nextcloud-2026-10-18.md. Notes on reading it.

• Nextcloud’s idle is measured after cron’s first run, and its peak depends on a cron burst. This page first said 299 MiB idle and 454 MiB peak (35.0.1, run of Oct 8), then 265 and 367 (35.0.2, run of Oct 17); the run of Oct 18 gives 297 and 452. The Oct 17 idle figure was taken before the cron container’s first background run in two of its three runs, when cron held 0.6 MiB; after that run it held about 34 MiB in 6 of the 7 runs we measured after a first run (1.0 MiB in the seventh). The lab now waits for that first run before it measures idle (methodology, 2026-10-18), and memory.stat shows the 34 MiB is anonymous memory, not file cache. app, db and redis together were the same in all three batches (262.5, 264.2 and 264.7 MiB idle). The peak depends on whether a cron burst of 147 to 182 MiB lands inside the upload: two of the three runs on Oct 18 had one and peaked at 452 and 479 MiB, the third peaked at 402 MiB. We do not know what starts the bursts. Single runs across the three batches ranged from 253 to 301 MiB idle and from 362 to 497 MiB peak, so read Nextcloud’s peak as roughly 400 to 500 MiB, and do not read 35.0.2 as using less memory: we did not test that. Details are in the Nextcloud guide.
• Infinite Scale’s idle figure is noisy: use the range. The three runs idled at 155.41, 151.47 and 101.46 MiB, a ratio of 1.53 against a flag threshold of 1.5, so the result carries a variance flag. In all three runs the stack sat between 213 and 322 MiB for about two minutes after the first healthy check and then dropped in one step, between the 120 s and 140 s marks, to those three levels. We do not know why it drops or why the level differs, because the result holds no per-process data. The lab waited for the total to flatten (about 180 s), so the idle figure is the level after the drop. Anyone sizing for the first two minutes should read the startup peak row.
• Seafile’s idle figure spreads too, below the flag. The runs idled at 758.82, 616.28 and 590.22 MiB (ratio 1.29). The difference sits in the Seafile container (617, 475 and 449 MiB); MariaDB held 132 MiB and Redis 9 MiB in every run. We did not look for the cause.
• Peaks rest on few samples, and unevenly. The peak is the highest sample while the upload script ran, sampled every 2 to 3 seconds. The Nextcloud load lasted about 36 s (19 to 21 samples), Infinite Scale’s about 9 s (6 to 7) and Seafile’s about 4 s (4). A spike shorter than the sample interval is missed, and a short window gives it fewer chances, so the Seafile and Infinite Scale peaks are the less certain ones.
• By our sizing rule (the highest reading in any run, times 1.5, rounded up to 1, 2, 4, 8, 16 or 32 GB; how we size): Nextcloud 479.0 MiB (the peak under load in run 3, with a cron burst in it) gives 1 GB, Seafile 911.4 MiB gives 2 GB (1.34 GiB needed), and Infinite Scale 322.7 MiB (a startup peak in run 3) gives 1 GB. No one in the lab used a sync client, an office server or more than one user, so these are floors for a one-user setup, not for a team.
• Disk for images uses the site’s rule: unpacked plus compressed size, plus 10%, rounded up, for a fresh Docker 29 or later install with the containerd image store (how we size disk). Your files and databases come on top.
• Start-up times are not the same event. Each is the wall-clock time until that stack’s own health checks passed, and each includes a first-run setup (Nextcloud’s automatic install, Seafile’s database and admin creation, Infinite Scale’s ocis init). The checks themselves differ: Nextcloud’s waits for status.php to report installed, Seafile’s for the web API and the file server, Infinite Scale’s for status.php. They are lab-host figures and we do not rank on them.

What each project’s documents say about RAM

Researched, not tested by us: read from each project’s own documentation on Oct 16, 2026.

Read our sizing tiers next to these, not instead of them. Our test was one user, one 194 MB upload of 103 files and a clean install, so its 1 GB, 2 GB and 1 GB say what that load needs, not what a working server needs. It did not cover search indexing, thumbnails and previews, an office server, sync clients, many users or many spaces, and each of those adds memory. For Infinite Scale, ownCloud’s guidance (4GB to start, 4-6GB with the production example’s other services) is four times our tier, and our 151 MiB idle and 305 MiB peak do not contradict it. We would not run Infinite Scale for real users on 1 GB on the strength of this test. Seafile’s 2G matches our tier, so we would treat it as a minimum. Nextcloud’s 512MB is per process, and the total depends on how many processes run at once, which we did not count.

Upload, list and download timing

The same 103 generated files went to each app: 100 small ones of 1 KB to 1 MB and three of 50 MB, 194,456,599 bytes in all, from one user, one request at a time. Seconds, median of three runs with the range in brackets, lab host only. Source: Tested (nextcloud.json, seafile.json, owncloud.json).

What the rows say, and what they do not:

• Every upload in every run succeeded and every downloaded file matched its checksum. Seafile’s script counts 116 requests because it asks for an upload address once and a download address for each of the five files; the other two have no such step.
• The Nextcloud result file predates the request-count fields, so it reports no failed-request count. Its 103 uploads returned 201, as our Nextcloud guide describes.
• The Seafile and Infinite Scale rows come from the same CPU model, but still differ in API and transport. The gap between 1.5 and 6.8 s is not a pure comparison of the two servers.
• The upload script is not a sync client. A desktop client sends changes in its own way, and we did not measure it.

Test method

Same load, three scripts. One generator (the same seed, file names and order) built the 103 files for all three apps; a test in the lab repository fails if the files differ by a byte. Each script created a folder, uploaded the files, listed the folder and downloaded five files (small-000, small-050, small-099, large-0, large-2) and checked their SHA-256. Files were generated before the memory window began. One user (the admin), no browser, no sync client, no chunked upload, no previews, no sharing.

Why Seafile used its upload API. Seafile’s WebDAV server is an optional component and is off by default: the manual says “By default, seafdav is disabled” (WebDAV extension), and the same page recommends the sync client if you want better performance. Seafile’s Web API has a documented call that returns an upload link; the desktop client uses its own protocol, and we found no documented script interface for it. So the lab used the Web API: log in for a token, create a library, request one upload address and reuse it for every file with a multipart POST. That is one request per file, the same shape as one WebDAV PUT, but it is a different code path, and we say so wherever timing appears.

Transport. Nextcloud and Seafile were reached over plain HTTP on the Compose network, with a Host header for their configured names. Infinite Scale serves HTTPS with a self-signed certificate it generates, and the script does not verify it, which adds TLS work to the Infinite Scale rows only (we did not measure how much). Infinite Scale’s WebDAV login used Basic authentication, switched on for the lab (see the Compose section).

What we made equal, and what we did not. Equal: the files, the request order, one request at a time, one admin user, a clean install, the default settle rule (wait until the stack’s total memory is flat to within max(2%, 10 MiB) over 60 s, at least 120 s after setup), three runs from fresh volumes. Not equal: the hosts (see the table), the number of containers, the database (PostgreSQL, MariaDB, none), and everything that comes with each product’s own setup. Seafile ran without Caddy, SeaDoc, its notification and metadata servers, Seafile AI and WebDAV; Infinite Scale ran without Traefik, Collabora, ONLYOFFICE, Tika, ClamAV, Keycloak and a mail server. Nextcloud had no apps beyond the image’s defaults.

Versions. Nextcloud 35.0.2 (Apache image; its changelog dates the release to Oct 15, 2026, read Oct 17), Seafile Community Edition 13.0.28, ownCloud Infinite Scale 8.2.1. Seafile 14.0.9 was out on Oct 14, 2026 but its own changelog labels it “14.0.9 beta” and lists 13.0.28 (Sep 18, 2026) as the newest release without that label, so we tested 13.0.28. Re-test when 14.0 leaves beta. For Nextcloud, the setup, update and restore steps are in the Nextcloud Docker Compose guide; we ran no such steps for the other two.

Which ownCloud: Infinite Scale, not Classic

A search for “nextcloud vs owncloud” can mean two different products. ownCloud Classic is the PHP server (versions 10 and 11) that Nextcloud descends from; Nextcloud’s repository still carries “2013-2016 ownCloud, Inc.” copyright lines. ownCloud Infinite Scale (oCIS) is a separate product, written in Go. We tested Infinite Scale, and our numbers say nothing about Classic.

Why Infinite Scale: ownCloud’s download page labels it “Our Flagship Product” and “ownCloud’s modern successor to the old PHP monolith (ownCloud 10 / oC10)”, read Oct 16, 2026. An ownCloud blog post of Apr 24, 2026 (PHP 8.3: yes for Classic) says “oCIS is the future”, calls Classic “a maintenance commitment” and says “We’re not building major new features on the Classic codebase”; it also says a migrator from Classic to oCIS is “in the pipeline, not shipped yet”. We found no sentence in which ownCloud says “use Infinite Scale for new installs”, so that is our reading of these.

Classic is still released. Docker Hub showed owncloud/server 10.16.6 and 11.0.1 pushed on Oct 15, 2026 (read Oct 16), and ownCloud’s 11.0.0 announcement (Jul 31, 2026) describes eleven security fixes and a PHP 8.3 baseline, with PHP 7.4 installs staying on 10.16.x. If you run Classic today, or follow a tutorial that installs it, you are on the maintenance line. A later lab test of owncloud/server:11.0.1 would complete this page; it has not been done.

Features compared (researched)

We did not test these. Each row is from the project’s own documentation, repository or registry page, read Oct 16, 2026.

Three things the table does not settle. First, “no calendar section in the manual” is an absence we saw in the contents, not a statement by Seafile that it has none. Second, the license rows are the projects’ words and are not legal advice. Third, we ran none of the sync clients, so we cannot say how any of these designs behaves when files change on a laptop.

Infinite Scale license

Researched, read Oct 16, 2026. The Infinite Scale source is Apache 2.0, and the oCIS README has a separate section that says: “Some builds of stable ownCloud Infinite Scale releases provided by ownCloud GmbH are subject to an End User License Agreement.” The agreement defines the covered software as ownCloud Infinite Scale “packaged and distributed by licensor in form of (but not limited to) zip-archives, tarballs, virtual images, software containers or the like formats”. It grants “Private Use” (an individual, family and friends, including “testing, evaluation or development purposes”) and “Productive Use” (an organization’s “productive day to day business”). It also says “You must not install and use ownCloud Infinite Scale for Commercial Use”, and defines that as corporate use for commercial advantage, “including but not limited to e.g. offering ownCloud Infinite Scale based software-as-a-service (SaaS), platform-as-a-service (PaaS) or any other types of hosted services to a third party”, and also an indirect advantage such as a “cost-free add-on” to other products. It states that Private Use and Productive Use “are explicitly NOT considered as Commercial”.

What we could not settle: whether the owncloud/ocis image on Docker Hub is one of the “some builds”. Its Docker Hub page does not mention the agreement. It carries an Apache-2.0 badge for the image’s packaging repository, owncloud-docker/ocis, and says the image is built from source. No source we read says the image is covered or that it is not. If you would run Infinite Scale as a hosted service for others, or inside a product you sell, ask ownCloud before you start. Running it for yourself or inside your own organization is what the agreement’s Private Use and Productive Use describe. This is our reading of the sources, not legal advice.

When to pick Nextcloud

• You want more than file storage from one server. Calendar, contacts, mail and Deck boards are documented as Nextcloud’s groupware bundle, and online office is a documented add-on (researched, not tested). The lab stack did not run any of those apps, so 297 MiB idle is the file server alone.
• You want the stack we tested furthest. Whole stack: 297 MiB idle, 452 MiB peak under a one-user upload (the Oct 8 run on 35.0.1 gave 299 and 454; the Oct 17 run, 265 and 367, was taken before cron’s first run in two of three runs; see the note under the table), 1 GB by our sizing rule for that load, the same tier as Infinite Scale and half of Seafile’s. Nextcloud’s documents recommend 512MB per process, and we did not count processes, so add room for more users. It is also the only one of the three for which we ran proxy, cron, Redis, patch and major update, backup and restore tests. They are in the verified Nextcloud compose file and guide.
• You accept four containers and 676.4 MB of images to download. app held 204 MiB of the 297 at idle. The cron container held 34 MiB at idle in this run, after its first background run (0.6 MiB before it), and reached 147 and 167 MiB during the upload in two of three runs (on Oct 8 it reached 154 and 182 MiB in two of three runs).

When to pick Seafile

• Files are the whole job. Seafile’s manual describes a Git-like model with content-defined blocks and deduplication between versions of a file (researched; we did not exercise the sync client, so we have no measure of what that saves you). There is no calendar or contacts section in the manual, and online office goes through its OnlyOffice or SeaDoc extensions.
• You have 2 GB or more. Whole stack: 616 MiB idle and 905 MiB under the upload, 2 GB by our rule. The manual’s own figure for the Community Edition is 2G of memory and 2 cores, and it says extensions such as OnlyOffice need more. Of the three, it is the stack with the most RAM and the most image data (720.0 MB to download).
• You are fine with MariaDB and Redis. The 13.0 Docker documentation says that “Since Seafile 13” Redis is the recommended cache and Memcached “will no longer be integrated into Seafile Docker by default” (Docker setup). The lab’s file follows that setup. Our compose file leaves out Caddy, which the official setup uses for TLS.
• Check the edition. Cluster installation, virus scan and SeaSearch are marked “(Pro)” in the manual’s contents. Which Community Edition limits matter for you is for the manual to say; we tested Community Edition 13.0.28 only.

When to pick ownCloud Infinite Scale

• You want the smallest measured footprint of the three. One container: 151 MiB idle (range 101 to 155), 305 MiB peak under our one-user upload, 87.5 MB of image to download, 1 GB by our rule for that test. By its idle median it used 51% of Nextcloud’s RAM (151 against 297 MiB) and about a quarter of Seafile’s; by its lowest run, 34% of Nextcloud’s. Its peak (305 MiB) was 68% of Nextcloud’s (452). Against the Oct 17 Nextcloud medians (265 and 367 MiB), which were taken before cron’s first run, the shares would have been 57% and 83%. For about two minutes after start it sat at 213 to 322 MiB, close to Nextcloud’s idle.
• Do not read that as “runs on 1 GB”. ownCloud’s prerequisites page calls 4GB “a good starting point” for production and says RAM depends on the number of spaces and the tasks running at once. Our test had one user, one space, no search, previews or office server. It shows the footprint of the empty server and a small upload, not the memory a team would need.
• You can live without calendar and contacts, or will run them elsewhere. Neither is in the 8.2 documentation we read (see the table). If you need CalDAV and CardDAV on the same server, Nextcloud documents them, and ownCloud’s edition comparison, which names ownCloud 10.13, lists optional Calendar and Contacts apps that sync over CalDAV and CardDAV; the Infinite Scale pages we read do not.
• You like the spaces model and no PHP. Infinite Scale organizes data into spaces that have roles of their own and runs as a Go binary (researched). We tested neither the spaces features nor the web interface.
• Read the production notes first. The lab ran it the evaluation way, with a self-signed certificate (see the Compose section). The documented production setup is a different, larger stack. Read the “Infinite Scale license” section above if you plan to host it for other people or build it into a product.

Syncthing, if you do not need a server

A search for “seafile vs syncthing” is asking a different question. Syncthing’s FAQ says it “does not upload your data to the cloud but exchanges your data across your machines as soon as they are online at the same time”. It copies folders between your own devices instead of keeping them on a server you run. If that covers your need, none of the three stacks above is required. We have since tested Syncthing 2.1.6, on Oct 16, 2026: 22 to 24 MiB idle per node, measured as two lab nodes. Those numbers, and how a peer-to-peer tool differs from a server, are on our page about a self-hosted alternative to Google Drive. This page has no feature comparison for it.

Migration notes

Not run in our lab: we did not move data between any of these apps. What we can say from the sources:

• Classic to Infinite Scale. ownCloud’s April 2026 post says the migrator is “in the pipeline, not shipped yet”. Check ownCloud’s documentation for the state of the migrator before you plan a move; we did not look for a converter.
• Between any two of these. All three can hold plain files, and rclone has a WebDAV backend with Nextcloud and ownCloud options and a Seafile backend, so a file-level copy through rclone is possible in principle (researched; not run in our lab). Calendars, contacts, shares, versions and comments would not come with a plain file copy.
• Back up first. The only restore we tested is Nextcloud’s, in its guide. It showed that a database dump alone did not restore; do not assume the other two are simpler.

Compose files

Nextcloud’s verified compose file and .env are in the Nextcloud guide’s verified-file section, which also covers the trusted-domain, Redis and cron settings and the reverse proxy; they are the files the Oct 18 run used (35.0.2) and we do not repeat them here.

The Seafile and Infinite Scale files below are the ones the lab ran on Oct 16, 2026, with their ports as published (localhost only). Each .env has its password lines commented out, on purpose: both products create the first admin account with whatever they are given, so a placeholder would become a real, known password. The compose files refuse to start until you set them. The measured runs used the lab’s own values.

Seafile

Three services: seafile, db (MariaDB 10.11) and redis. Data lives in two named volumes: db and seafile-data. The file has no TLS. It follows the official Seafile 13.0 Docker setup, with one file instead of four and without Caddy and SeaDoc.

# Verified compose for Seafile, tested 2026-10-16 by the SelfHostBench lab (3 runs; the figures are the median).
# Lab host: AMD EPYC 9V45 96-Core Processor, 2 vCPU, 7.8 GiB RAM, x86_64, Docker 28.0.4.
# Floating image tags below were replaced by the version resolved at test time;
# the registry digest is in the comment on each image line.
# Measurements: seafile.json (schema 3).
# Companion env file: seafile.env (save it as .env next to this file).
# Secrets are not published: the lab's values are public. In seafile.env:
#   INIT_SEAFILE_ADMIN_PASSWORD is commented out. Uncomment it and set your own value (the comment above it explains how).
#   INIT_SEAFILE_MYSQL_ROOT_PASSWORD is commented out. Uncomment it and set your own value (the comment above it explains how).
#   SEAFILE_MYSQL_DB_PASSWORD is commented out. Uncomment it and set your own value (the comment above it explains how).
#   JWT_PRIVATE_KEY is commented out. Uncomment it and set your own value (the comment above it explains how).

# Seafile Community Edition 13.0 with MariaDB and Redis.
# Follows the official Docker setup, https://manual.seafile.com/13.0/setup/setup_ce_by_docker/ (seafile-server.yml and .env of
# that page, read 2026-10-16). Differences from it, all marked below: one file instead of four, no Caddy and no SeaDoc, named volumes
# instead of /opt/... bind paths, a pinned image tag, required passwords, healthchecks on every service, a stricter Seafile healthcheck.
# There is no TLS in this file. Put a reverse proxy in front before you expose it (see the article).
name: seafile

services:
  db:
    # MariaDB 10.11, the version the official file uses. Seafile needs a MySQL-compatible database (SQLite is not supported since 11.0).
    image: mariadb:10.11  # sha256:7db29378d4fdab73f8123bbc2b48905c90d1a4b00cf848b028f1e81e623257f2  (version 10.11.19, from label:org.opencontainers.image.version)
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: "${INIT_SEAFILE_MYSQL_ROOT_PASSWORD:?set INIT_SEAFILE_MYSQL_ROOT_PASSWORD in .env}"
      MYSQL_LOG_CONSOLE: "true"
      MARIADB_AUTO_UPGRADE: "1"
    volumes:
      # The Seafile databases (ccnet_db, seafile_db, seahub_db). Back them up with mariadb-dump.
      - db:/var/lib/mysql
    healthcheck:
      test: ["CMD", "/usr/local/bin/healthcheck.sh", "--connect", "--mariadbupgrade", "--innodb_initialized"]
      interval: 10s
      start_period: 30s
      timeout: 5s
      retries: 12

  redis:
    # Since Seafile 13 Redis is the recommended cache (memcached is optional and no longer part of the official file).
    # No password and no published port: only containers on this Compose network can reach it.
    image: redis:8.10.2  # sha256:2c2dff791878316e3b083188be0d578423b24813cdda5de0e80ea4f7b3e6bfd6  (version 8.10.2, from exec)
    restart: unless-stopped
    command:
      - /bin/sh
      - -c
      - exec redis-server --requirepass "$$REDIS_PASSWORD" --save "" --appendonly no
    environment:
      REDIS_PASSWORD: "${REDIS_PASSWORD:-}"
    healthcheck:
      # Differs from the official file, which has no healthcheck here.
      test: ["CMD-SHELL", "redis-cli ping | grep -q PONG"]
      interval: 5s
      timeout: 3s
      retries: 12

  seafile:
    # The Seafile server: seaf-server (file server, Go), Seahub (the web interface, Django) and the bundled nginx on port 80.
    image: seafileltd/seafile-mc:13.0.28  # sha256:b0c90832126bf432db908449f1bb450211e6bbf75a2193bab3399e2a9636eccf  (version 13.0.28, from exec)
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_healthy
    ports:
      # Localhost only. A reverse proxy on the host sends traffic here. The official file publishes nothing and puts Caddy in front.
      - "127.0.0.1:8080:80"
    environment:
      # Database. The first start creates the three databases and the "seafile" database user with the root password.
      SEAFILE_MYSQL_DB_HOST: db
      SEAFILE_MYSQL_DB_PORT: "3306"
      SEAFILE_MYSQL_DB_USER: seafile
      SEAFILE_MYSQL_DB_PASSWORD: "${SEAFILE_MYSQL_DB_PASSWORD:?set SEAFILE_MYSQL_DB_PASSWORD in .env}"
      INIT_SEAFILE_MYSQL_ROOT_PASSWORD: "${INIT_SEAFILE_MYSQL_ROOT_PASSWORD:?set INIT_SEAFILE_MYSQL_ROOT_PASSWORD in .env}"
      SEAFILE_MYSQL_DB_CCNET_DB_NAME: ccnet_db
      SEAFILE_MYSQL_DB_SEAFILE_DB_NAME: seafile_db
      SEAFILE_MYSQL_DB_SEAHUB_DB_NAME: seahub_db
      TIME_ZONE: "${TIME_ZONE:-Etc/UTC}"
      # First admin account. Used on the first start only; later changes here do nothing.
      # The official file has defaults (me@example.com / asecret); here both must be set so nobody runs with a public password.
      INIT_SEAFILE_ADMIN_EMAIL: "${INIT_SEAFILE_ADMIN_EMAIL:?set INIT_SEAFILE_ADMIN_EMAIL in .env}"
      INIT_SEAFILE_ADMIN_PASSWORD: "${INIT_SEAFILE_ADMIN_PASSWORD:?set INIT_SEAFILE_ADMIN_PASSWORD in .env}"
      # The address you type in the browser. Seafile builds its download and upload links from these two values.
      SEAFILE_SERVER_HOSTNAME: "${SEAFILE_SERVER_HOSTNAME:?set SEAFILE_SERVER_HOSTNAME in .env}"
      SEAFILE_SERVER_PROTOCOL: "${SEAFILE_SERVER_PROTOCOL:-http}"
      # At least 32 random characters. Seafile services use it to sign tokens for each other.
      JWT_PRIVATE_KEY: "${JWT_PRIVATE_KEY:?set JWT_PRIVATE_KEY in .env}"
      SITE_ROOT: /
      NON_ROOT: "false"
      SEAFILE_LOG_TO_STDOUT: "false"
      ENABLE_GO_FILESERVER: "true"
      # Redis for the cache.
      CACHE_PROVIDER: redis
      REDIS_HOST: redis
      REDIS_PORT: "6379"
      REDIS_PASSWORD: "${REDIS_PASSWORD:-}"
      # Optional components of the official file, all switched off here: SeaDoc (online documents; needs its own container),
      # the notification server, the metadata server and Seafile AI.
      ENABLE_SEADOC: "false"
      ENABLE_NOTIFICATION_SERVER: "false"
      ENABLE_SEAFILE_AI: "false"
      ENABLE_FACE_RECOGNITION: "false"
    volumes:
      # Libraries (file blocks), configuration (conf/) and logs. This is your data: back it up together with the database.
      - seafile-data:/shared
    healthcheck:
      # The official file only checks that port 80 answers. This one waits for the API (Seahub) and the file server (seaf-server)
      # behind the bundled nginx, which is when uploads work.
      test: ["CMD-SHELL", "curl -fsS http://localhost/api2/ping/ | grep -q pong && curl -fsS http://localhost/seafhttp/protocol-version | grep -q version"]
      interval: 10s
      timeout: 10s
      retries: 60
      start_period: 30s

volumes:
  db:
  seafile-data:

# Address you type in the browser: no http://, no port, no path. Seafile writes it into its upload and download links.
SEAFILE_SERVER_HOSTNAME=seafile.example.com
# http or https. Behind a TLS reverse proxy use https.
SEAFILE_SERVER_PROTOCOL=http
TIME_ZONE=Etc/UTC

# At least 32 random characters; Seafile's services use it to sign tokens for each other. Choose your own; the stack does not start without it.
# Generate one with:  openssl rand -hex 32
# JWT_PRIVATE_KEY=

# MariaDB root password. Choose your own; the stack does not start without it.
# Generate one with:  openssl rand -hex 24
# INIT_SEAFILE_MYSQL_ROOT_PASSWORD=

# Password of the database user "seafile", which Seafile creates on the first start. Choose your own; the stack does not start without it.
# Generate one with:  openssl rand -hex 24
# SEAFILE_MYSQL_DB_PASSWORD=

# E-mail address of the first admin account (it is the login name). First start only.
INIT_SEAFILE_ADMIN_EMAIL=admin@example.com

# Password of the first admin account (first start only). Choose your own, long; the stack does not start without it.
# A placeholder would become a real, known admin password, so the lab's value is not published and this line is commented out.
# Generate a password with:  openssl rand -hex 16
# INIT_SEAFILE_ADMIN_PASSWORD=

ownCloud Infinite Scale

One service, ocis, with two named volumes: ocis-config (holds the generated secrets in ocis.yaml; without it the data cannot be used) and ocis-data.

# Verified compose for ownCloud Infinite Scale, tested 2026-10-16 by the SelfHostBench lab (3 runs; the figures are the median).
# Lab host: AMD EPYC 9V45 96-Core Processor, 2 vCPU, 7.8 GiB RAM, x86_64, Docker 28.0.4.
# Floating image tags below were replaced by the version resolved at test time;
# the registry digest is in the comment on each image line.
# Measurements: owncloud.json (schema 3).
# Companion env file: owncloud.env (save it as .env next to this file).
# Secrets are not published: the lab's values are public. In owncloud.env:
#   OCIS_ADMIN_PASSWORD is commented out. Uncomment it and set your own value (the comment above it explains how).

# ownCloud Infinite Scale (oCIS) 8.2: the single-container ownCloud that ownCloud calls its flagship product.
# Follows the Docker examples of ownCloud's own documentation: "Minimalistic Evaluation Guide for oCIS with Docker" (https://owncloud.dev/ocis/guides/ocis-mini-eval/)
# and the `ocis` service of the ocis_full example (https://github.com/owncloud/ocis/tree/stable-8.2/deployments/examples/ocis_full), without that example's
# Traefik, Collabora, ONLYOFFICE, Tika, ClamAV, Keycloak and mail containers. Differences from both, all marked below.
# Infinite Scale has no separate database and no cache container: users, metadata and search index live inside this one container's volumes.
# TLS: oCIS answers on HTTPS with a certificate it generates itself (self-signed). That is fine on a private network and for a browser
# on the same machine; for the internet put a reverse proxy in front (see the article).
name: owncloud

services:
  ocis:
    image: owncloud/ocis:8.2.1  # sha256:5e007d702b78d70e5aeade14ec9da46044664996df6c9482630dedadcc74bffc  (version 8.2.1, from label:org.opencontainers.image.version)
    restart: unless-stopped
    # `ocis init` writes /etc/ocis/ocis.yaml with random secrets on the first start. It fails on later starts because the file exists,
    # so the error is ignored and the server starts (the same line as the ocis_full example).
    entrypoint: ["/bin/sh"]
    command: ["-c", "ocis init || true; exec ocis server"]
    ports:
      # Localhost only. A reverse proxy on the host sends traffic here.
      - "127.0.0.1:9200:9200"
    environment:
      # The address you type in the browser. It is also the OpenID Connect issuer, so it must be the address users really use
      # (with a reverse proxy: https://your.domain). The default works for a browser on the same machine.
      OCIS_URL: "${OCIS_URL:-https://localhost:9200}"
      # Listen on all interfaces, not only inside the container (the evaluation guide sets this too).
      PROXY_HTTP_ADDR: 0.0.0.0:9200
      # oCIS generates a self-signed certificate; the services call each other (and the identity provider) over it, so do not verify it.
      # The ocis_full example sets this to false only when a proxy with a real certificate is in front.
      OCIS_INSECURE: "true"
      # Password of the first account, "admin". Used when oCIS creates its user database on the first start; later changes here do not
      # change an existing password. The official example defaults to the public password "admin"; here it must be set.
      IDM_ADMIN_PASSWORD: "${OCIS_ADMIN_PASSWORD:?set OCIS_ADMIN_PASSWORD in .env}"
      # Not in the evaluation guide. Lets WebDAV clients and scripts that cannot do OpenID Connect log in with user name and password
      # (the ocis_full example has the same switch, off by default and described as "not recommended"). The web interface and the
      # official apps use OpenID Connect and do not need it. Remove it if you only use those.
      PROXY_ENABLE_BASIC_AUTH: "true"
      OCIS_LOG_LEVEL: "${OCIS_LOG_LEVEL:-info}"
    volumes:
      # Configuration with the generated secrets (ocis.yaml). Back it up: without it the data cannot be used.
      - ocis-config:/etc/ocis
      # Every user's files and the metadata. This is your data: back it up.
      - ocis-data:/var/lib/ocis
    healthcheck:
      # The official examples have no healthcheck. status.php answers when the proxy and the frontend are up; the image has curl.
      # -k because the certificate is self-signed.
      test: ["CMD-SHELL", "curl -fsSk https://localhost:9200/status.php | grep -q '\"installed\": true'"]
      interval: 10s
      timeout: 10s
      retries: 30
      start_period: 20s

volumes:
  ocis-config:
  ocis-data:

# Address you type in the browser, with https:// and without a trailing slash. It must match what users really use:
# a name like https://cloud.example.com behind a reverse proxy, or the default below for a browser on the same machine.
OCIS_URL=https://localhost:9200

# Password of the first account, "admin" (first start only). Choose your own; the stack does not start without it.
# A placeholder would become a real, known admin password, so the lab's value is not published and this line is commented out.
# Generate one with:  openssl rand -hex 16
# OCIS_ADMIN_PASSWORD=

Lab settings you would change in a real deployment

The file runs the way ownCloud’s evaluation guide runs it, plus one switch for the lab’s script. That guide says the setup is “ONLY intended for a quick evaluation and to access the instance from your local machine using internal certificates only”. Not tested in our lab: any of the changes below.

• OCIS_INSECURE: "true". Infinite Scale generates a self-signed certificate and its services call each other over it, so the lab told them not to verify it. The proxy page of the 8.2 docs says this setting is “not recommended for production environments” (proxy service), and the production Compose guide says to comment out INSECURE on an internet-facing server (guide).
• Real certificate and OCIS_URL. The guide puts Traefik with Let’s Encrypt in front. If a reverse proxy ends TLS, the proxy docs say PROXY_TLS can be false, and then “the communication between the reverse proxy and Infinite Scale is not secured”. OCIS_URL is also the OpenID Connect issuer, so it must be the address your users type.
• PROXY_ENABLE_BASIC_AUTH: "true". Added so a script could use WebDAV with a user name and password. The proxy docs say that in production you want it disabled, which is the default. Remove it unless you need it.
• The admin password is set from OCIS_ADMIN_PASSWORD on the first start; changing the variable later does not change an existing password.
• The rest of the stack. The official production example adds Collabora, ONLYOFFICE and other services, and its documentation asks for 4 to 6 GB. Our figures are for the single container above.

What we did not test

• Desktop and mobile sync clients for any of the three, and how they behave when files change on a laptop. The lab used API scripts.
• Online office (Collabora, OnlyOffice, Euro-Office, SeaDoc), full-text search, previews and thumbnails.
• External storage, S3 or other storage backends.
• LDAP, SSO and OpenID Connect logins (Infinite Scale’s bundled login was bypassed by Basic authentication).
• More than one user, sharing, public links, and files larger than 50 MB.
• Arm hardware: one x86-64 runner type only.
• A large library, and growth in RAM or disk over days. Each run started from an empty install and lasted a few minutes.
• ownCloud Classic 10 or 11, Seafile 14, and Nextcloud AIO.
• All three apps on the same CPU model in one job, which a clean timing comparison needs.
• Upgrades and restores for Seafile and Infinite Scale, and the published files with a real domain and certificate.

Related

• Nextcloud in depth: the Nextcloud Docker Compose guide, with the verified file, Redis, cron, reverse proxy, update and restore tests behind the Nextcloud numbers above.
• Photos rather than files: Immich runs as a separate stack with machine learning. See the Immich Docker Compose guide and its measured RAM.
• How the lab measures RAM, CPU and image sizes, and why runs are repeated: methodology. Other apps in the same format: the self-hosted apps index.
• Another two-app comparison with the same CPU-model caveat: AdGuard Home vs Pi-hole.
• Official sources used on this page, read Oct 16, 2026: Nextcloud’s system requirements, office and groupware documentation; Seafile’s manual pages on system requirements, data model, architecture, WebDAV and OnlyOffice; ownCloud’s download page, Classic blog posts, and Infinite Scale architecture, prerequisites, services and proxy pages, the end-user license agreement and the Docker Hub page for the image.