Self-Hosted Alternative to Google Drive: 6 Apps Tested

The right self-hosted alternative to Google Drive depends on what you use Drive for. Pick Nextcloud for files plus calendar and office add-ons (untested): 297 MiB idle, files only. Pick Seafile when files are the whole job: 616 MiB idle, the only one of six in our 2 GB tier. Pick ownCloud Infinite Scale for one small container: 151 MiB idle (noisy); its docs suggest 4 GB. Pick Syncthing for device-to-device sync with no server: 22 to 24 MiB idle per node. Pick FileBrowser Quantum for a simple web file manager: 29 MiB idle. Skip the archived File Browser.

The lab put the same 103 files (194,456,599 bytes) through each app as one user on a clean install, three runs each, on 2-vCPU GitHub Actions runners. Rows marked Tested come from those runs. Rows marked Researched come from each project’s own documents, read on Oct 17, 2026 (FileBrowser Quantum: Oct 18, 2026), and nothing in them was benchmarked. RAM and image sizes carry across hosts; timings do not, and we do not rank the apps on speed. The method and its caveats are in Nextcloud vs ownCloud vs Seafile. Each of the five single-stack results has a Test box below. Syncthing has none: its result is two lab nodes, so its per-node figures are in its own section.

What Google Drive costs

Every Google account includes up to 15 GB of storage, “shared across Gmail, Google Drive, and Google Photos” (Google Account Help, read Oct 17, 2026). More storage is sold as a Google One membership, “where available” on that page. The plans page we could read on Oct 17, 2026 showed plan sizes but no prices, so this page states none. Check the page for your country and currency.

Self-hosting swaps that monthly bill for hardware or a VPS you run, plus your time to update and back it up. The sizing tiers below say how much RAM each app needs.

If you want a hosted service that is not Google, we read one example. Proton’s Drive plan page lists a free 5 GB plan and Drive Plus at 200 GB for $4.99/month in its US-dollar monthly view (read Oct 17, 2026), and calls Drive “end-to-end encrypted”. The page also has currency and monthly or yearly toggles, so the price you pay depends on country and billing period. Not tested in our lab.

Alternatives compared

The first table is Tested, apart from its last column. The second is Researched. The same apps also answer “Dropbox alternatives, open source” and “Nextcloud alternative”, but we compared against Drive’s features, not Dropbox’s.

Measured: RAM, images and sizing tier

Each figure is the median of three runs with the lowest to highest run in brackets. RAM is Docker’s working set for all containers of one stack, idle after the stack settled (how we measure idle RAM). Peak is the highest sample while the 103-file load ran. Sources: nextcloud.json, seafile.json, owncloud.json, filebrowser.json, filebrowser-quantum.json and syncthing.json in lab/results/ (figures and script in lab/notes/gdrive-alternatives-2026-10-17.md; that note’s Nextcloud figures are the Oct 8 run, and the Oct 18 Nextcloud figures are in lab/notes/nextcloud-2026-10-18.md; the FileBrowser Quantum figures and script are in lab/notes/gdrive-alternatives-2026-10-18.md).

How to read it.

• The tier is a floor. Our rule (highest reading in any run, times 1.5, rounded up to 1, 2, 4, 8, 16 or 32 GB; how we size) gives 1 GB for five of the six, so it hides the spread between 15 MiB idle and 452 MiB peak. Use the RAM columns for that. The tier is for one user and 103 files, not for a family with years of photos.
• Project guidance is higher than our tiers for two apps. ownCloud’s 4GB for production is four times our 1 GB tier. Seafile’s 2G matches ours. Nextcloud’s 512MB is per process, and we did not count processes.
• Infinite Scale’s idle figure moves between runs. The three runs idled at 155, 151 and 101 MiB, and the result carries a variance flag. For the first two minutes after start, 10-second means sat between 213 and 322 MiB (startup peak 282 MiB median, highest single sample 323). Details are in the three-way comparison.
• Nextcloud’s idle is measured after cron’s first run, and its peak depends on a cron burst. The Oct 18 run on 35.0.2 gave 297 MiB idle and 452 MiB peak (the Oct 8 run on 35.0.1 gave 299 and 454). The Oct 17 run (265 and 367) was taken before the cron container’s first background run in two of its three runs, and the lab now waits for that run before it measures idle (methodology, 2026-10-18). The peak varies with whether a cron burst of 147 to 182 MiB lands inside the upload: single runs peaked from 402 to 479 MiB on Oct 18, and from 362 to 497 MiB over the three batches. We do not claim 35.0.2 uses less memory (Nextcloud guide).
• The hosts differ. Nextcloud and Syncthing ran on EPYC 7763 runners, Seafile, Infinite Scale and File Browser on EPYC 9V45, and FileBrowser Quantum on an Intel Xeon Platinum 8573C, each in its own job. Peaks rest on 3 to 21 samples, taken 2 to 3 seconds apart.
• Syncthing’s two nodes. The lab ran two nodes because Syncthing needs a peer. The result file’s own totals add them (45.4 MiB idle, 109.4 MiB peak); a reader runs one node per device, so the table gives each node. Node A is the one the files were written into, node B received them.

What each one replaces from Google Drive

Researched, not tested: each cell is from the project’s documents or repository, read on Oct 17, 2026 (the FileBrowser Quantum column: Oct 18, 2026). “Not checked” means we did not look.

Photo backup from a phone is a different job from file sync. For a photo library with machine-learning search, see the Immich Docker Compose guide and its measured RAM.

Nextcloud: the full suite

Nextcloud is the closest match to a whole Google account: files, plus a calendar, contacts and online office as documented add-ons. In the lab, the four-container stack (app, cron, PostgreSQL, Redis) idled at 297 MiB and peaked at 452 MiB while one user uploaded the 103 files over WebDAV (35.0.2, Oct 18; the Oct 8 run on 35.0.1 gave 299 and 454). The load was files over WebDAV only; we did not set up or use the calendar, contacts or office apps, so these numbers say nothing about them. It is also the only app here for which we ran proxy, cron, update and restore tests.

The verified compose file, the trusted-domain, Redis and cron settings and the reverse proxy are in the Nextcloud Docker Compose guide, so we do not repeat them. Why you might pick it over Seafile or Infinite Scale is in When to pick Nextcloud.

Seafile: files are the whole job

Seafile 13.0.28 idled at 616 MiB across Seafile, MariaDB and Redis, and peaked at 905 MiB during the upload. That is the most RAM and the most image data (720.0 MB) of the six, and the only 2 GB tier. Its manual describes a Git-like block storage model and a desktop client with selective sync (researched). It has no calendar or contacts section in the manual’s contents. The lab used Seafile’s upload API because its WebDAV component is off by default; we did not run the sync client.

The lab’s compose file and .env are under Compose files in the comparison. The reasons to pick it are under When to pick Seafile.

ownCloud Infinite Scale: one small container

Infinite Scale 8.2.1 (oCIS, ownCloud’s Go rewrite) is one container: 151 MiB idle, 305 MiB under the upload, 87.5 MB of image. That is a little over half of Nextcloud’s idle RAM (297 MiB), with the noise noted above. ownCloud’s own guidance of 4GB for production, and its production Compose example with Collabora and ONLYOFFICE asking for “at minimum 4-6GB”, is the number to plan on for real users. We tested Infinite Scale, not ownCloud Classic (the PHP server), and the license terms for the Docker image are unsettled in our sources; both are covered in Which ownCloud and Infinite Scale license.

Syncthing: sync between your devices, no server

Syncthing is not a cloud or a server. Its 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”. Every device runs the same program, and two devices connect only if each has the other’s device ID (getting started). There are no share links, and its web page manages devices and folders rather than showing your files (researched, see the table above). What you get instead is a copy of a folder on each device, with nothing stored on a server you pay for unless you choose to run one as an always-on peer. Check your phones before choosing it: its FAQ says the team has no plans to support iOS officially, and the official Android app is discontinued (feature table above).

That changes what the lab could measure. Syncthing has no upload call, so the lab ran two nodes, wrote the 103 files into node A’s folder and timed how long node B took to have them all. The second node and a shared volume are lab-only; the compose file below is the single node you would run.

Source: syncthing.json (raw result), figures in lab/notes/gdrive-alternatives-2026-10-17.md. The peak rests on 4 samples per node.

Two more differences from a node you would run. The lab switched off global discovery, local discovery, relays, NAT traversal and usage reporting, and the network had no route out, so idle RAM on a node with those on may differ; we did not measure that. And we found no RAM guidance in Syncthing’s FAQ. Our test had 103 files; memory for a large library was not measured.

The compose file below is the single node you would run. The lab ran this image and its healthcheck in the two-node setup above, not this exact file with its ports mapped (its header says so). Its header comments also mark where it differs from the project’s Docker README. Set a password for the web interface before you publish its port to anything but localhost, as the file’s header says.

# Verified compose for Syncthing, tested 2026-10-16 by the SelfHostBench lab (3 runs; the figures are the median).
# Lab host: AMD EPYC 7763 64-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: syncthing.json (schema 3).
# Lab difference: Syncthing is peer to peer, so the lab runs TWO nodes: the published service (node A) and a second, identical service (node B, `syncthing-b`), which is not in the published file. The lab publishes no host ports, puts both on a Compose network with no route out (`internal: true`), gives each node a fixed GUI API key, and mounts one shared volume at /data in both nodes so the load step can write into node A's folder and read the files node B received. A real deployment has one node per device, on different machines. Image, user, volume at /var/syncthing and healthcheck are the published file's. The published single-node file has not been run with its ports mapped in the lab.

# Syncthing 2.1.6: continuous peer-to-peer file synchronisation. This is ONE node, the thing you run on a server and pair your laptop, phone and other machines with.
# Syncthing has no central server and no upload API: every device runs the same program, and a folder is shared by adding the other device's ID on both sides.
#
# Follows README-Docker.md of the Syncthing repository (tag v2.1.6). Differences from it, all marked below: a pinned tag, a named volume instead of ./st-sync,
# published ports on a bridge network instead of `network_mode: host`, the web interface bound to localhost only, a 5-second healthcheck.
# The GUI has no password after the first start. Set one (Actions > Settings > GUI, "GUI Authentication User" and "Password") before you publish the port to anything but localhost.
name: syncthing

services:
  syncthing:
    image: syncthing/syncthing:2.1.6  # sha256:4d0281bdcb4ed9baf503d251d0544ddd856f49fce3f114056257ae172b7fb670  (version v2.1.6, from label:org.opencontainers.image.version)
    # The name other devices show for this one. Change it.
    hostname: my-syncthing
    restart: unless-stopped
    environment:
      # The user the process runs as (the image starts as root and switches). Files in your folders are owned by this user.
      PUID: "1000"
      PGID: "1000"
      # The image sets STGUIADDRESS=0.0.0.0:8384 so the GUI answers on the Docker network; the port mapping below keeps it on localhost of the host.
    ports:
      # Web GUI and REST API. Localhost only: reach it with an SSH tunnel (ssh -L 8384:127.0.0.1:8384 you@server) or put a TLS reverse proxy in front.
      - "127.0.0.1:8384:8384"
      # Sync protocol (TCP, and QUIC over UDP). Other devices connect here; open it in the server's firewall.
      - "22000:22000/tcp"
      - "22000:22000/udp"
      # Local discovery (UDP broadcast). It does not cross Docker's bridge network, so on a LAN it finds nothing from here; README-Docker.md recommends
      # `network_mode: host` for that reason (then delete this `ports:` block). On a VPS, devices find each other by address or global discovery, and this line is unneeded.
      - "21027:21027/udp"
    volumes:
      # Configuration, keys, the index database and the default folder (~/Sync = /var/syncthing/Sync). Your device ID comes from the key in here: back it up.
      - syncthing:/var/syncthing
      # More folders: mount them below and add them in the GUI. A named volume or a path, for example:
      # - /srv/files:/data/files
    healthcheck:
      # The image's own check (the no-auth health endpoint) with a 5 s interval instead of 60 s, so the container is "healthy" a few seconds after the start.
      test: ["CMD-SHELL", "curl -fkLsS -m 2 127.0.0.1:8384/rest/noauth/health | grep -o --color=never OK || exit 1"]
      interval: 5s
      timeout: 5s
      start_period: 5s
      retries: 3

volumes:
  syncthing:

FileBrowser Quantum: the maintained web file manager

FileBrowser Quantum is a web file manager for one or more folders on a server, and the one we would pick for a new install: it is maintained and idled at 29.3 MiB. Its README calls it “a massive fork of the file browser open-source project”, and it is Apache-2.0 licensed. The archived File Browser’s README does not name it or any other successor (see the next section). It is actively released: the releases page, read Oct 18, 2026, lists seven tagged releases between Oct 4 and Oct 13 (stable and beta; the page gives no year, and the Docker Hub push date for 2.0.1-stable is Oct 13, 2026). Release v2.0.1-stable, the one we tested and marked Latest, fixed two advisories: a High one (“New accounts named with “..” breaks out of scoped folder on creation”) and a Medium one (a session token collision when several users log in at once). So update promptly. It has its own API (calls take source and path parameters), a YAML config file and a SQLite database, so we treat it as a different program from File Browser 2.63.23, not a new version, and its numbers are a separate row.

We tested gtstef/filebrowser:2.0.1-stable, the project’s stable channel, which its version page calls “the most reliable version as the name implies” (beta “may encounter unexpected issues”). The lab host was a GitHub Actions runner with an Intel Xeon Platinum 8573C (2 vCPU), on Oct 18, 2026, three runs, the same 103 files as the other apps. The load went through Quantum’s documented upload call (POST /api/resources), one request per file; the web interface cuts large uploads into chunks, and we did not use that path.

Source: filebrowser-quantum.json (raw result), figures in lab/notes/gdrive-alternatives-2026-10-18.md. The peak rests on 3 samples per run. The folder listing reports sizes as disk usage (4 KiB blocks), so the lab checked the 103 names and that no size was below the file’s length; the listing summed to 194,654,208 bytes against 194,456,599 uploaded.

Against the archived File Browser. Quantum idled at about twice the RAM in these runs: 29.3 MiB against 14.7 MiB (2.0 times), 44.0 against 22.8 MiB at peak (1.9 times), and a 63.1 MB image against 16.8 MB (3.8 times). The idle ranges do not overlap (27.4 to 31.4 against 12.8 to 14.8). Both sit in our 1 GB tier. Treat the ratio as two runs on two hosts, not a controlled comparison: File Browser ran on Oct 16 on an AMD EPYC 9V45, Quantum on Oct 18 on an Intel Xeon Platinum 8573C, and the two programs use different APIs. RAM and image size carry across hosts better than timings, and we do not compare upload times. The default image includes ffmpeg and document preview; the project’s -slim variant leaves them out, and we did not test it.

What the idle figure does not include. Quantum indexes its folder in a SQLite database: one pass at start, then scheduled scans. The indexing page says scans run on “a complexity-based schedule that ranges from 5 minutes to 12 hours”, and gives 50 MB for a full scan of 10,000 folders and 10,000 files (150 MB for 50,000 and 50,000). In two probes on our development sandbox, not published results, the debug log scheduled the first scan 12 min 51 s and 17 min 40 s after the start, and a lab run lasts about 3 minutes, so we saw no scan inside the idle or load windows (lab/notes/filebrowser-quantum-2026-10-18.md, section 4). The same probe saw memory after a load fall slowly, from 36 to 21.6 MiB over 8 minutes, and a scan with 103 files add about 4.5 MiB. Idle here is an empty folder, measured before the load; a stack just after a big upload will read higher, and a large tree will use more.

The compose file below is the one the lab ran.

# Verified compose for FileBrowser Quantum, tested 2026-10-18 by the SelfHostBench lab (3 runs; the figures are the median).
# Lab host: INTEL(R) XEON(R) PLATINUM 8573C, 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: filebrowser-quantum.json (schema 3).
# Companion env file: filebrowser-quantum.env (save it as .env next to this file).
# Secrets are not published: the lab's values are public. In filebrowser-quantum.env:
#   FILEBROWSER_ADMIN_PASSWORD is commented out. Uncomment it and set your own value (the comment above it explains how).

# FileBrowser Quantum 2.0.1 (stable channel): a web file manager for one or more folders on the server. The actively maintained fork of the archived File Browser
# (filebrowser/filebrowser, archived 2026-09-01). Single container, no database server (users and settings are in a SQLite file).
#
# Follows the Docker page of the project's docs (filebrowserquantum.com, "Getting started > Docker", v2.0.x): the image, a data directory at /home/filebrowser/data that holds
# config.yaml, the database and the cache, port 80, runs as UID/GID 1000. Differences from the docs, all marked below: a pinned tag, the admin password set through the
# environment (the docs let Quantum print a random one into the log), ONE named volume instead of two /path bind mounts (the served folder is a directory inside it),
# the config file written inline under `configs` (needs Docker Compose 2.23.1 or newer), a localhost-only port, and a health check every 5 s.
#
# Channels: Quantum ships a `stable` and a `beta` channel. This file follows STABLE (2.0.x). Beta (2.1.x) gets new features first and "may encounter unexpected issues".
# Image variants: the default image (about 60 MB) includes ffmpeg and document preview; `-slim` (about 15 MB) leaves them out. This file uses the default image.
#
# Do not expose it directly to the internet: put a reverse proxy with TLS in front.
name: filebrowser-quantum

services:
  filebrowser:
    image: gtstef/filebrowser:2.0.1-stable  # sha256:2e3936caf7b12908f7d3ebb68ddfcea075cda5f732e4bd95beae6cfa529cbec7  (version v2.0.1-stable, from label:org.opencontainers.image.version)
    restart: unless-stopped
    # Quantum does not create the folder it serves, and a second named volume would belong to root while Quantum runs as UID 1000 and must write into it.
    # So the folder is a directory inside the data volume (which the image prepares for UID 1000), made here before Quantum starts. `exec` keeps Quantum as the main process.
    # With a /path bind mount of a folder you own, as in the docs, you do not need this line: mount it at /folder and set `path: /folder` in the config below.
    entrypoint: ["sh", "-c", "mkdir -p /home/filebrowser/data/files && exec ./filebrowser"]
    ports:
      # Localhost only. A reverse proxy on the host sends traffic here. The docs publish 80:80 on every interface.
      - "127.0.0.1:8080:80"
    environment:
      # The admin password (the user is `admin` unless auth.adminUsername is set in config.yaml). Set in .env. Quantum uses any value except an empty one or `admin`
      # as given and does not ask for a change at the first login. Without a value it generates a random password and prints it once in the log
      # (docker compose logs filebrowser), which is what the docs describe; here a value is required so the first login is known.
      # The docs say a password set in the configuration is applied again at every start, so change it here, not only in the web interface.
      FILEBROWSER_ADMIN_PASSWORD: "${FILEBROWSER_ADMIN_PASSWORD:?set FILEBROWSER_ADMIN_PASSWORD in .env}"
    volumes:
      # config.yaml is mounted here (see `configs`). Quantum keeps its SQLite database (database.sqlite: users, settings, shares) and its cache (tmp/) here, and the folder it
      # serves is files/ in this directory. This is your data: back it up.
      - filebrowser-data:/home/filebrowser/data
    configs:
      - source: quantum_config
        target: /home/filebrowser/data/config.yaml
    healthcheck:
      # The image's own check (GET /health with curl, every 30 s, 10 s start period) with a shorter interval so the container is marked healthy within seconds.
      test: ["CMD", "curl", "-f", "http://localhost:80/health"]
      interval: 5s
      timeout: 3s
      start_period: 2s
      retries: 3

configs:
  quantum_config:
    content: |
      # FileBrowser Quantum config (docs: filebrowserquantum.com > Configuration; every key not set here has its default).
      server:
        # Thumbnails, the icon cache and other cached files; inside the data volume so they survive a restart.
        cacheDir: /home/filebrowser/data/tmp
        sources:
          # The folder to serve, from the container's point of view (never "/" and never /var). `name` is how the API refers to the source.
          - path: /home/filebrowser/data/files
            name: files
            config:
              # New users (and, from 2.0.1, every user at every start) get this source.
              defaultEnabled: true

volumes:
  filebrowser-data:

Two parts of it differ from the project’s Docker page, which mounts a folder you own at /folder and a ./data directory. Both are explained in the file’s header and in lab/notes/filebrowser-quantum-2026-10-18.md (section 2).

• The entrypoint line. Quantum does not create a missing source folder (it fails with “Failed to open root directory … no such file or directory”), and a second named volume would belong to root while Quantum runs as UID 1000 and must write into it. So the served folder is a directory inside the data volume, which the image prepares for UID 1000, and the container creates it with mkdir -p before exec ./filebrowser. A one-shot service that fixes ownership would also work, but the lab harness expects every service to keep running. With a bind-mounted folder you own, as in the docs, you can drop the line and mount it at /folder. Not tested in our lab: the lab used the one-volume layout.
• The configs: block. The config.yaml is written inline in the compose file (this needs Docker Compose 2.23.1 or newer) instead of a file you create. It is mounted read-only and Quantum starts and runs normally with it, because it writes nothing to config.yaml. Its one source is the folder from the line above, with defaultEnabled: true so every user gets it.

The stack does not start without an admin password, and the file takes it from .env. The lab’s value is public, so the .env below has the line commented out: uncomment it and set your own. Do not leave a placeholder, because Quantum uses any value except admin or an empty one as the real password.

# Admin password of FileBrowser Quantum (user `admin`). Choose your own, long. The stack does not start without it.
# A placeholder would become a real, known password, so the lab's value is not published and this line is commented out.
# Generate one with:  openssl rand -hex 16
# FILEBROWSER_ADMIN_PASSWORD=

What we did not test for Quantum: login by OIDC, LDAP or a proxy; a large folder tree (only the docs’ figures above); previews and thumbnails, which the web interface generates and our API load never asked for; chunked uploads from the web interface; and the beta channel (2.1.x). The full list is under What we did not test.

File Browser: archived upstream

File Browser is a web file manager for one directory on a server. It is the smallest app in this test, at 14.7 MiB idle (12.8 to 14.8), 22.8 MiB peak and a 16.8 MB image, and the lab’s 110 requests all succeeded. It is also unmaintained. The project’s README, read Oct 17, 2026, opens with (GitHub’s own banner on the repository reads Aug 31, 2026):

File Browser is archived on 2026-09-01. The last planned release has already shipped. There will be no further releases, bug fixes, or security fixes.

The README lists two classes of issue that “will not be fixed”: the command runner and hooks (off by default), and session tokens that cannot be revoked, so a leaked token stays valid until it expires. For anyone still running it, the README says not to expose it directly to the internet and to put it behind a reverse proxy that does TLS and its own authentication. Our version, 2.63.23, is the last release (Jul 27, 2026). Our advice, based on those two unfixed issue classes and the end of security fixes: do not start a new install.

The README does not name a successor; it links only a July 2026 background post. The fork we tested, FileBrowser Quantum, is in the section above. We keep these numbers as a record of what existed: the maintained fork we tested uses about twice the RAM, and we did not test whether Quantum opens a File Browser database.

How to migrate

Not run in our lab: we moved no real data into or out of any of these apps. What the sources say.

• Export from Google. Google’s Takeout help page (read Oct 17, 2026) says you can export Drive data as Zip or Tgz archives, delivered by “Add to Drive”, which counts toward your Google storage, and that “Your archive expires in about 7 days”. It does not say whether Google Docs, Sheets and Slides are converted to other formats, so open a few exported files before you delete anything.
• Import. Each app takes plain files. Nextcloud and Seafile take uploads in the web interface or through their desktop clients, Syncthing takes whatever you put in the shared folder, and File Browser and FileBrowser Quantum serve a directory. We did not test any import, and calendars, contacts, shares and version history do not come with a file copy.
• Back up first. The only restore we tested is Nextcloud’s, in its guide. A database dump alone did not restore there.

What we did not test

• Desktop and mobile sync clients for any app: the lab used API scripts, and for Syncthing a second container.
• Photo backup and photo apps, including Nextcloud’s Photos. For photos, see the Immich guide.
• Online office (Collabora, OnlyOffice, Euro-Office, SeaDoc), full-text search and previews.
• More than one user, sharing, public links, and files over 50 MB.
• A transfer over the internet or a relay, Syncthing with discovery and relays on, and any large library. Every app had 103 files.
• ARM hardware (one x86-64 runner type only), and memory growth over days.
• ownCloud Classic, Seafile 14 and Nextcloud AIO.
• FileBrowser Quantum beyond the API load: the web interface in a browser, OIDC, LDAP and proxy login, a large folder tree, previews and thumbnails, chunked uploads, WebDAV, shares, several users, a reverse proxy, the beta channel (2.1.x), the -slim image, and moving a File Browser database into it.
• The apps behind a real reverse proxy with a domain. Only Nextcloud has that test, in its guide.
• Hosted services, including Proton Drive.

Hosting needs

Our tiers are for one user. For a household, use the project’s guidance where it is higher: 4 GB for Infinite Scale, 2 GB for Seafile. Syncthing needs no new server, because it runs on devices you already own. FileBrowser Quantum fits our 1 GB tier (48.1 MiB highest reading, 29.3 MiB idle) with room for a larger folder than our 103 files. File Browser should not be a new install. The module below is for Nextcloud, the full-suite pick; Seafile needs the next RAM tier up.

Related

• Nextcloud in depth: the Nextcloud Docker Compose guide, with the verified file and the update, backup and restore tests.
• The three file servers side by side, with the host and API caveats: Nextcloud vs ownCloud vs Seafile.
• Photos instead of files: the Immich Docker Compose guide and its RAM requirements.
• How the lab measures RAM, CPU and image sizes: methodology. Other apps in the same format: the self-hosted apps index.
• Primary sources, read Oct 17, 2026: Google’s storage and Takeout help pages; Nextcloud’s sharing, web interface, office and groupware documents, client downloads and Photos README; the Seafile user manual and sharing page; the ownCloud Infinite Scale README and documentation; Syncthing’s FAQ, getting started, config reference, downloads and Android repository; the File Browser README; and, read Oct 18, 2026, the FileBrowser Quantum repository, releases, version page, indexing page and Docker page.