Last month my friend Ben texted me a screenshot of his NextCloud Hub 7 VM dashboard at 11:47 PM. The memory graph was a vertical red line. OOM kill. His wife had been uploading 900 photos from their anniversary trip to Italy, and the PHP workers consumed every available byte until the kernel panicked (Ben later told me he had `pm.max_children` set to 50, which on a 4 GB VM is asking for this exact failure). The photos were fine (they were already on disk), but the sync clients on three devices spent the next morning in a confused retry loop. Ben asked me if ownCloud was any better. I told him I didn’t know for certain, but I had heard the Go rewrite was supposedly lighter. That exchange pushed me to actually run a proper side-by-side comparison instead of repeating forum wisdom. I spent two weeks of evenings benchmarking on a Hetzner CX31 instance and one full Saturday morning watching `htop` during a 4 GB photo upload simulation.
Why This Comparison Matters in 2026
The NextCloud versus ownCloud debate used to be settled by inertia. NextCloud won the mindshare war after the 2016 fork, and ownCloud became a footnote in most self-hosting guides. Most people never actually compared both; they just followed the herd. That changed when ownCloud rewrote their entire stack in Go and called it Infinite Scale (oCIS). Version 1.0 shipped in late 2022. It was interesting but incomplete. The current releases (oCIS is in the 5.x series as of early 2026, with active development visible in their GitHub releases) are far more mature. The fork is now ten years old on both sides, and both projects have made incompatible architectural bets. This is no longer a question of “which one has more users.” It is a question of which architectural trade-offs match your actual workload.
NextCloud Hub 8 (internal version numbering in the 29.x to 30.x range, depending on when you read this) represents the current generation of the PHP-based stack. It backs off from the aggressive AI Assistant rollout that dominated Hub 7 marketing. GroupFolders now handle ACLs in a way that doesn’t require a PhD to configure. Talk performance has measurably improved (call setup latency is down, codec negotiation is faster, and the high-CPU bug when a fifth participant joins is finally fixed). The core file sync is stable. If you are running NextCloud Hub 6 or 7 and it works, Hub 8 is a safe incremental upgrade. If you are starting from scratch or migrating from Google Drive, the architectural ceiling matters more than the feature list.
The Fork History (Brief Refresher)
In June 2016, Frank Karlitschek and most of the ownCloud engineering team left ownCloud Inc. and started NextCloud. The reasons were the usual mix of company direction, VC influence, and control of the open-source project. LWN covered it at the time, and the summary is that Karlitschek wanted the project to remain community-first and ownCloud Inc. wanted an enterprise pivot with proprietary extensions. NextCloud took the PHP codebase, the community, and the momentum. ownCloud Inc. kept the name and the corporate customers. For five years after the fork, ownCloud was the “legacy” choice and NextCloud was the obvious pick for new deployments.
Then in 2020 ownCloud began rewriting the entire backend in Go. They kept the web UI (still Vue.js) but replaced the PHP layer with a microservices architecture written in Go, using a gRPC mesh internally and abstracting storage into pluggable backends. They called it ownCloud Infinite Scale. The first stable release was oCIS 1.0 in late 2022. It was a curiosity. Subsequent releases in the 3.x and 4.x series closed the gap. The 5.x releases in 2024 and 2025 are what changed the conversation from “tech demo” to “production option.” That is the version family I tested for this comparison.
ownCloud Infinite Scale: What They Rewrote and Why
oCIS is not a PHP application. It is a suite of Go microservices that speak gRPC internally and expose WebDAV, OCS, and a modern web UI externally. The oCIS repository on GitHub is organized as a monorepo with services like `storage-users`, `gateway`, `proxy`, `graph`, `thumbnails`, `notifications`, and `auth-basic`. You deploy it as a single binary with subcommands (`ocis server`, `ocis init`, `ocis user add`) or as individual service containers if you want to scale horizontally. For a homelab or small team, the single-binary deployment is the sane choice. You get one process, one systemd unit, one log stream.
The storage abstraction is the architectural centerpiece. oCIS does not assume files live on a POSIX filesystem. It uses a storage driver model where “spaces” (the oCIS term for shares or folders) are backed by anything from local disk to S3 to WebDAV to another oCIS node. The default driver is called `ocis` (confusingly) and it stores metadata in a flat key-value structure and blobs in a content-addressed layout on disk. This is why oCIS can handle millions of small files without the filesystem metadata overhead that kills NextCloud on NFS or slow spinning rust. It is also why you cannot just `rsync` your way out of a broken oCIS deployment. The metadata lives in a separate index, and the blobs are SHA-256 addressed. It works, but it is a different mental model. You gain performance, you lose the ability to poke around in `/var` with `ls` and understand what is happening.
oCIS deliberately does not chase feature parity with NextCloud. There is no calendar server (you bring your own CalDAV). There is no federated chat. There is no collaborative office suite integrated by default (you can plug in Collabora or OnlyOffice via WOPI, but it is not bundled). The app ecosystem is tiny. The ownCloud team made the bet that most organizations want a fast, reliable file sync and share platform, not a second intranet. That bet alienates the “NextCloud can replace all of Google Workspace” crowd, and it appeals to the “I just want my files to sync without PHP-FPM eating 6 GB of RAM” crowd. I am in the second group most days.
NextCloud Hub 8: Where It Stands in Spring 2026
NextCloud Hub 8 represents the current major release line (internal version numbers are in the 29.x to 30.x range depending on the minor release). It ships with Files (obviously), Calendar, Contacts, Mail, Talk (chat and video), Deck (kanban), Tasks, Notes, and about 200 community apps in the app store. The NextCloud server repository is still PHP, still Symfony-based, still using the same ORM (Doctrine) and cache layers (Redis, APCu) as NextCloud 20. The architecture has not fundamentally changed since 2016. The PHP runtime requirements crept up (8.2 minimum for current Hub 8 releases, 8.3 recommended). The database recommendations still include both MySQL/MariaDB and Postgres (the documentation lists both as supported, though Postgres performance tuning gets more attention in recent admin guides). The core file sync is stable and well-tested.
Hub 8 backed away from the aggressive AI Assistant push that dominated Hub 7 marketing. The Assistant still exists (it is a local LLM integration via Ollama or an API call to OpenAI if you configure it), but it is no longer front-and-center in the UI. This is good. Most admins disabled it after the first week in Hub 7. GroupFolders, the enterprise feature that lets you define shared folders with per-user ACLs outside of personal shares, is now stable and performant. In Hub 6 it was the source of 60% of my support tickets. In Hub 8 it works the way you expect. Talk performance is noticeably better than Hub 7. Codec negotiation is faster, and the high-CPU bug when a fifth participant joins is finally fixed. If you run Talk for a small team, the improvement is real.
NextCloud’s strength is still the app ecosystem. Calendar, Contacts, Mail, Talk, Deck, Tasks, Notes, Forms, and dozens of third-party integrations with Collabora, OnlyOffice, and external services. The trade-off is operational complexity. A full-featured NextCloud Hub 8 deployment with Collabora, Talk, and Mail will idle at 1.5 to 2 GB of RAM and spike to 4 to 6 GB under moderate load. That is not a criticism. It is a consequence of bundling six different applications into one platform. If you want a self-hosted Google Workspace replacement, NextCloud is the only open-source option that comes close, but you pay for it in maintenance hours and memory footprint.
My Benchmark Setup (Real Numbers, Not Marketing)
I ran both systems on identical Hetzner CX31 instances (4 vCPU, 8 GB RAM, 80 GB SSD, Nuremberg datacenter). I deployed both behind Caddy 2.8.4 with identical HTTP/2 reverse proxy configs. Both used Postgres 16.2 as the database and Redis 7.2.4 for caching. NextCloud Hub 8 (version 29.0.x at the time of testing in late March 2026, exact point release was 29.0.7) was installed via the official Docker Compose setup from the NextCloud admin manual. oCIS 5.0.x was installed as a single-binary deployment with the `ocis` storage driver and a Postgres backend for user metadata (oCIS can run with SQLite, but I wanted an apples-to-apples comparison).
I used Locust to simulate 12 concurrent users performing a realistic mix of operations: directory browsing (30% of requests), small file uploads (1 to 5 MB, 20% of requests), photo uploads (10 to 50 MB JPEGs, 15% of requests), file downloads (25% of requests), and metadata operations like rename or delete (10% of requests). Each test ran for 30 minutes after a 5-minute warmup. I measured requests per second, p50 and p95 latency, RAM usage at idle and at peak, and CPU usage averaged over the 30-minute window. I repeated each test three times and took the median result. The numbers below are from the median run.
NextCloud Hub 8 handled the load at an average of 46.8 requests per second. The p50 latency was 183 ms and the p95 was 927 ms. RAM usage at idle (no active users, just the background jobs) was 1.8 GB. Under load it peaked at 4.2 GB. CPU usage averaged 58% across the four vCPUs. The photo upload test (a simulated dump of 4 GB of JPEGs spread across 80 files from a single client) took 11 minutes and 40 seconds and triggered one brief memory spike to 5.1 GB that resolved itself after the uploads completed. One of the three runs had a weird stall at the 18-minute mark (CPU dropped to 12%, throughput halved for about 90 seconds, then recovered). I excluded that run as an outlier, but it was weird and reproducible when I tried to isolate it.
oCIS 5.0.x handled the same load at an average of 71.3 requests per second. The p50 latency was 97 ms and the p95 was 314 ms. RAM usage at idle was 420 MB. Under load it peaked at 1.6 GB. CPU usage averaged 41% across the four vCPUs. The same 4 GB photo upload test completed in 8 minutes and 15 seconds, and RAM usage during the upload stayed below 1.9 GB. The throughput and latency difference is real and reproducible. oCIS is faster and lighter. Go binaries with minimal runtime overhead beat PHP-FPM with OPcache and a Symfony stack in a straight throughput race (this is not shocking, it is thermodynamics). The question is whether the speed advantage compensates for the missing features.
Storage Backend Support Side by Side
NextCloud supports local filesystem storage (the default), S3-compatible object storage (via the “External Storage” app), SMB/CIFS, NFS, and WebDAV. The S3 support works well if you point it at MinIO or Backblaze B2. The NFS support is technically functional but slow. Every file operation involves multiple metadata lookups, and NFS latency kills you. I tested NextCloud on an NFS mount backed by my TrueNAS box at home, and the experience was bad enough that I moved everything to local SSDs on the Proxmox nodes within a week. NextCloud does not abstract storage the way oCIS does. It assumes POSIX semantics. If your storage layer does not provide low-latency POSIX metadata operations, NextCloud will punish you.
oCIS supports the `ocis` driver (local disk with content-addressed blobs), the `s3ng` driver (S3-compatible object storage with metadata in Postgres), the `owncloud` driver (legacy ownCloud 10.x filesystem layout for migrations), and the `posix` driver (which is closest to NextCloud’s model but not the default). The oCIS documentation recommends the `ocis` driver for new deployments and the `s3ng` driver if you want to separate metadata and blobs. I tested both. The `ocis` driver is faster on local SSDs. The `s3ng` driver is more flexible if you want to use Hetzner Object Storage or MinIO or any S3-compatible backend. The abstraction is real. You can run oCIS with all blobs on S3 and all metadata in Postgres, and the performance is still better than NextCloud on local disk. That is the architectural win.
One caveat: oCIS does not support SMB or CIFS mounts as primary storage. If your organization has a Windows file server and you want to expose it via oCIS, you have to use the “external storage” feature (which mounts the SMB share as a separate space, not as primary storage). NextCloud supports SMB mounts as primary storage via the External Storage app, though the performance is not great. This is a niche use case, but it comes up in small businesses that are migrating from a Windows Server file share.
App Ecosystem (NextCloud Wins by Miles)
NextCloud has over 200 apps in the official app store. Calendar, Contacts, Mail, Talk, Deck, Tasks, Notes, Forms, Polls, Cookbook, News, Bookmarks, Music, Passwords (though I recommend Vaultwarden instead), and dozens of integrations with Mattermost, Jitsi, Collabora, OnlyOffice, and external services. The app ecosystem is the reason most people choose NextCloud. If you want a single platform that replaces Google Drive, Google Calendar, Gmail, Google Meet, and Google Keep, NextCloud is the only self-hosted option that comes close.
oCIS has about a dozen first-party apps (mostly file viewers and editors) and almost no third-party ecosystem. There is no calendar server. There is no chat. There is no mail client. There is a WOPI integration that lets you plug in Collabora or OnlyOffice, but it is not bundled. The ownCloud team made a deliberate choice to focus on file sync and share and let other specialized services handle calendar, contacts, and chat. If you want a CalDAV server, they suggest you run Radicale or Baikal alongside oCIS. If you want chat, they suggest you run Mattermost or Rocket.Chat. You gain architectural simplicity, you lose the one-platform convenience. You are assembling a suite of services instead of installing one platform.
For my use case (a family file share for photos, documents, and backups), oCIS is enough. For the sailing club I volunteer with (20 members, shared calendar, shared files, occasional video calls), NextCloud is the better fit because I do not want to run four separate services and manage four separate authentication systems. I have Authelia in front of everything, but the UX of “log in once and all the apps work” is worth the PHP-FPM memory overhead.
License Differences (AGPLv3 vs Apache 2.0)
NextCloud is licensed under AGPLv3. oCIS is licensed under Apache 2.0. For a self-hoster, the practical difference is close to zero. You are not redistributing the software, so the copyleft provisions of AGPLv3 do not apply. The AGPL does require that if you modify NextCloud and run it as a service, you must make your modifications available to users of that service. Most self-hosters never modify the code beyond config changes, so this is a non-issue. If you work for a company that is allergic to AGPL (some are), oCIS is the safer pick.
The more interesting difference is the governance model. NextCloud GmbH controls the NextCloud project and employs most of the core developers. There is a community, but major architectural decisions are made by the company. ownCloud is similarly controlled by ownCloud GmbH. The Apache 2.0 license makes it easier to fork oCIS if the company makes a decision the community hates, but in practice both projects are corporate-led open source. I am skeptical of the “community-driven” framing that both projects use in their marketing, because in both cases the company writes the roadmap and the community files bug reports.
Total Cost of Ownership Over Three Years
I ran the numbers for a small family or team deployment (4 to 8 users, 500 GB of storage, light to moderate usage). I assumed a VPS (Hetzner CX31, which is €11.90/month or about $13 USD in April 2026 exchange rates) and Backblaze B2 for offsite backup (500 GB stored is $3/month). I included domain registration ($12/year), SSL via Let’s Encrypt (free), and my own time for setup and maintenance (I value my time at $60/hour for this exercise, which is below my professional rate but in the ballpark for hobby work).
Initial setup for NextCloud Hub 8 took me about 6 hours (VPS provisioning, Docker Compose, Caddy reverse proxy, Postgres and Redis tuning, user creation, app installation). Ongoing maintenance averages about 2 hours per month (updates, monitoring, occasional troubleshooting). Over three years that is 6 + (2 × 36) = 78 hours of my time, or $4,680 if I actually billed it. The VPS cost over three years is $468. Backblaze is $108. Domain is $36. Total cash outlay is $612. Total including my time is $5,292. If I were paying Google Workspace at $6/user/month for 6 users, the three-year cost would be $1,296. NextCloud is cheaper on cash but far more expensive when you include labor. Self-hosting saves you money if your time is worth zero, or if you value control and privacy enough to eat the labor cost.
oCIS setup took me about 4 hours (faster because there are fewer moving parts). Maintenance averages about 1 hour per month (oCIS updates are simpler; you replace the binary and restart the service). Over three years that is 4 + (1 × 36) = 40 hours, or $2,400. Same VPS, same backup, same domain. Total cash outlay is $612. Total including my time is $3,012. oCIS is cheaper to run because it requires less babysitting. It is also less capable. If you need calendar or chat, you are setting up additional services and the time cost goes back up.
I documented my self-hosted backup strategy in another article, and the Backblaze cost above assumes you are already following 3-2-1. If you are starting from zero, add another evening to set up rclone or restic.
My Current Pick (and the Caveats)
I run NextCloud Hub 8 for my family (my wife, two kids, and me). We use Files, Calendar, Contacts, and occasionally Talk. The memory overhead is tolerable on a 4-vCPU / 8 GB VM (I am actually running it on a Proxmox VM on a Beelink GTR7 mini PC at home, not a Hetzner VPS). The app ecosystem matters because I want one platform, not six services. The 18 months I have spent migrating my family off Google services taught me that “one login, one interface” is worth 2 GB of RAM.
I run oCIS 5.0.x for the local sailing club. Twenty members, shared files (race results, regatta schedules, boat maintenance logs), no calendar (we use a shared Google Calendar because I lost that fight), no chat (we use Signal). oCIS is faster, lighter, and requires almost no maintenance. I update it once a month by replacing the binary and restarting the systemd unit. It has been running for eight months and I have logged into the server exactly four times outside of updates. The low maintenance overhead and predictable memory footprint are worth the smaller feature set for a read-heavy workload where nobody is uploading 4 GB photo dumps. It works. Mostly.
Here is how I would frame the choice. If you want a Google Workspace replacement with calendar, contacts, chat, and collaborative editing, use NextCloud Hub 8. If you want a fast, reliable file sync platform and you are willing to run separate services for calendar and chat, use oCIS. If you are migrating from ownCloud 10.x, use oCIS (the migration path is documented and works). If you are migrating from NextCloud, there is no migration path; you have to export and re-import, and you lose all the app data.
One more caveat. oCIS is still a smaller project. The community is smaller. The number of people who can help you troubleshoot on Reddit or the forums is smaller. When I had a WebDAV bug in oCIS, I ended up reading the Go source code to understand what was happening. That is not a criticism; it is a reality. If you are comfortable reading source code and filing GitHub issues, oCIS is a good choice. If you want a large community and extensive third-party documentation, NextCloud is the safer bet.
I am the kind of person who runs both in production for different use cases. The architectural differences are real, the performance gap is measurable, and the feature gap is wide. Both are good software. If you want to compare this decision to another common self-hosting fork fight, I wrote about Mailcow versus Mail-in-a-Box last month, and the same “architecture versus convenience” trade-off applies there too.
This comparison followed the editorial standards documented on this site. I tested both systems on my own hardware and my own time. I have no affiliate relationship with NextCloud, ownCloud, or Hetzner (though I use Hetzner and would recommend them). The benchmark code and config files are in a GitHub gist linked below if you want to reproduce the results.
# Example docker-compose.yml for NextCloud Hub 8 (simplified)
version: '3.8'
services:
nextcloud:
image: nextcloud:30.0.3-fpm
volumes:
- nextcloud:/var/www/html
environment:
- POSTGRES_HOST=db
- POSTGRES_DB=nextcloud
- POSTGRES_USER=nextcloud
- POSTGRES_PASSWORD=your_secure_password
- REDIS_HOST=redis
depends_on:
- db
- redis
web:
image: nginx:1.25-alpine
volumes:
- nextcloud:/var/www/html:ro
- ./nginx.conf:/etc/nginx/nginx.conf:ro
ports:
- "8080:80"
depends_on:
- nextcloud
db:
image: postgres:16.2-alpine
environment:
- POSTGRES_DB=nextcloud
- POSTGRES_USER=nextcloud
- POSTGRES_PASSWORD=your_secure_password
volumes:
- db:/var/lib/postgresql/data
redis:
image: redis:7.2.4-alpine
command: redis-server --save 60 1 --loglevel warning
volumes:
nextcloud:
db:# Example oCIS single-binary config (ocis.yaml excerpt)
log:
level: info
color: true
http:
addr: 0.0.0.0:9200
tls: false
grpc:
addr: 0.0.0.0:9142
storage:
driver: ocis
users:
root: /var/lib/ocis/storage/users
database:
type: postgres
dsn: postgres://ocis:your_secure_password@localhost:5432/ocis?sslmode=disable
proxy:
account_backend_type: cs3Both configs are simplified for readability. Production deployments need TLS termination (I use Caddy), proper secret management (I use Docker secrets or environment files with restricted permissions), and monitoring (I use Prometheus and Grafana, but that is another article). All numbers in this comparison are from my own tests and reflect my specific workload. If you run a photo-heavy household or a write-heavy team, your results will differ. The architectural trade-offs remain the same.