OpenCloud vs Nextcloud:
Performance, Architecture & the Right Choice for 2026

Background & Lineage

To understand OpenCloud, you first have to understand ownCloud. ownCloud was the original self-hosted cloud storage project, founded in 2010 by Frank Karlitschek. In 2016, Karlitschek forked the project to create Nextcloud - a community-driven fork with more transparency and a faster release cadence. ownCloud continued in parallel as a commercial project.

Meanwhile, the Heinlein Group - a Berlin-based IT infrastructure company operating one of Germany's largest independent email providers - saw the limitations of PHP-based file sharing platforms and began building something new. The result is OpenCloud: a clean-room redesign that shares the user-facing concept of Nextcloud and ownCloud but is implemented entirely differently, in Go, with a microservices architecture designed for modern infrastructure.

OpenCloud is developed openly at opencloud.eu, licensed under Apache 2 (server) and GPL (clients), with no Contributor Licence Agreement required. The project runs on GitHub and welcomes community contributions to both code and documentation.

Architecture: Monolith vs Microservices

This is the most fundamental difference between the two platforms - and everything else flows from it.

Nextcloud: The Monolith

Nextcloud is a monolithic PHP application. The entire platform - file management, sharing logic, notifications, user management, app framework, WebDAV server, and every installed app - runs within a single PHP process (or FPM pool). All components share the same database, the same file system, and the same request/response lifecycle.

This is not inherently bad. Monolithic architectures are simple to deploy and reason about, and for small to medium installations it works well. The problem emerges at scale: to handle more load, you add more PHP-FPM workers, more memory, and more database connections. There is no way to scale individual components - the entire stack scales uniformly. CPU-intensive operations like thumbnail generation, full-text indexing, and file scanning compete directly with serving files over WebDAV.

Nextcloud mitigates this with background jobs via cron, Redis-backed locking and caching, and APCu for opcode caching. But these are optimisations on top of a fundamentally synchronous, process-per-request model.

OpenCloud: Microservices

OpenCloud is built as a set of independently deployable services that communicate over gRPC. There is a dedicated service for file storage, a separate service for search indexing, another for sharing logic, another for thumbnail generation, and so on. Each service can be scaled independently - you can run ten thumbnail workers alongside a single sharing service without paying the memory overhead of duplicating every component.

In practice, OpenCloud ships a single binary deployment mode (all services in one process) for small installations - this is what the Docker Compose setup uses. But the architecture underneath is still microservices: the services communicate via in-process gRPC calls rather than network calls, and you can split them out to separate containers or machines as load grows.

The result is a platform that scales horizontally in a way that a PHP monolith fundamentally cannot.

Language: PHP vs Go

The choice of programming language has real, measurable consequences for a file sharing server - particularly one that handles concurrent uploads, stream processing, and a large number of simultaneous WebDAV connections.

Nextcloud: PHP

PHP was designed for request-response web pages. It starts a process (or reuses an FPM worker), executes a script, and terminates. There is no persistent application state between requests - every request bootstraps the framework, loads configuration, establishes a database connection (or grabs one from a pool), and runs. PHP-FPM and opcode caching (OPcache, APCu) reduce this overhead substantially, but the fundamental model is still stateless and process-per-request.

For Nextcloud this means: every WebDAV request, every file operation, every API call goes through this lifecycle. Under high concurrency, you need a large number of PHP-FPM workers, each consuming memory independently. A modest Nextcloud instance serving 50 concurrent users typically requires 2–4 GB of RAM just for PHP-FPM, plus additional memory for Redis, the database, and Nextcloud's background workers.

OpenCloud: Go

Go is a compiled, statically typed language with native concurrency via goroutines. A goroutine is far lighter than an OS thread - you can run hundreds of thousands of goroutines in a single process, each handling a connection or a background task, with a memory overhead of roughly 2–8 KB each. There is no bootstrapping per request: the Go binary starts once, loads its configuration, and serves requests indefinitely with persistent in-memory state.

For OpenCloud this means: a single Go process can handle the same number of concurrent connections as dozens of PHP-FPM workers, at a fraction of the memory. File streaming is handled natively with Go's io.Reader/io.Writer interfaces - data flows through the process without unnecessary buffering. gRPC over HTTP/2 provides efficient multiplexed communication between services.

The practical consequence: OpenCloud has been demonstrated running comfortably on a Raspberry Pi 4 serving a small team. Nextcloud on a Pi is functional but noticeably sluggish.

Performance: Where the Gap Really Shows

The architectural and language differences translate directly into measurable performance advantages for OpenCloud across every dimension that matters for a file sharing server.

Cold Start & Container Startup

OpenCloud's Docker container starts in under a second. The Go binary initialises, binds its ports, and is ready to serve requests almost immediately. In Kubernetes or any auto-scaling environment, this means pods are ready instantly after scheduling.

Nextcloud's Docker container requires PHP-FPM to start, Nginx or Apache to initialise, and a first request to trigger OPcache warming. A cold Nextcloud container takes 20–60 seconds before it serves requests at full performance. In autoscaling scenarios this creates a meaningful lag between scale-out trigger and capacity being available.

Memory Footprint

A freshly started OpenCloud instance (single binary mode, Docker Compose) uses approximately 100–200 MB of RAM. This covers the entire application including the search service, thumbnail service, and all other components.

A minimal Nextcloud installation with PHP-FPM, Redis, and a database typically uses 1.5–4 GB under real load. Each PHP-FPM worker process consumes 40–120 MB depending on installed apps, and you need enough workers to handle concurrent requests without queuing. This makes Nextcloud expensive to run on small VPS instances.

File Streaming & Large Uploads

Go's native I/O model streams data directly between the network connection and storage without intermediate buffering. OpenCloud pipelines large file uploads through the Go runtime efficiently, with low and predictable memory usage even for multi-gigabyte files.

PHP buffers request bodies in memory or temp files before processing. For large file uploads via WebDAV, this can cause memory spikes and requires careful tuning of upload_max_filesize, post_max_size, memory_limit, and max_execution_time in PHP configuration - a familiar source of frustration for Nextcloud administrators.

Modern JavaScript & the Frontend Stack

Both platforms use Vue.js for their frontends, but OpenCloud treats the JavaScript layer as a first-class citizen in a way Nextcloud historically has not.

OpenCloud: Vue.js + TypeScript, Built for Speed

OpenCloud's frontend is written entirely in TypeScript with Vue 3 and the Composition API. The entire UI is a single-page application: once the initial bundle is loaded, navigation between sections, file browsing, sharing dialogs, and collaboration features all happen client-side without full page reloads. This makes the interface feel immediate and responsive - closer to a native desktop application than a server-rendered web page.

The frontend communicates with the backend exclusively through well-defined REST and gRPC-Web APIs. File listings, search results, sharing operations, and space management all go through these APIs as JSON or Protobuf responses, with the Vue layer managing application state locally. Heavy use of async/await and reactive Vue 3 stores ensures the UI remains responsive even during background operations like bulk file moves or large uploads.

OpenCloud also supports UI extensions and theming through a plugin system - teams can add custom UI elements, integrate internal tools, or apply brand themes without patching the core application.

Nextcloud: Vue.js, But With Legacy Baggage

Nextcloud has progressively adopted Vue.js over the years, but the migration is incomplete. The core file manager and newer apps use Vue components, but many parts of the UI - admin settings, older apps, the activity feed - still render server-side PHP with jQuery interactions. This results in a mixed experience: some actions trigger a full page reload, others are reactive, and the visual consistency between core and app UIs varies widely.

Nextcloud's JavaScript build pipeline has improved significantly with Nextcloud 25+ and the adoption of Webpack and Vite for newer apps. But the app store model - where hundreds of independently maintained apps each ship their own JS - means the overall frontend experience is harder to keep consistent. A heavily-app-loaded Nextcloud instance may serve hundreds of separate JavaScript bundles to the browser.

API Surface & Protocol Support

OpenCloud exposes a notably wider and more modern set of APIs than Nextcloud, reflecting its design goal of being embeddable in larger infrastructure rather than a self-contained silo.

The Microsoft Graph API support deserves special mention: OpenCloud implements a subset of Microsoft's RESTful Graph API, which means tools and clients built for Microsoft 365 can interact with OpenCloud without modification. This dramatically lowers the barrier to integration with existing enterprise tooling.

The native OpenID Connect support means OpenCloud plugs directly into any OIDC-compatible identity provider - Keycloak, Authentik, Azure AD, Google Workspace - without installing an app or patching the configuration. Nextcloud supports OIDC but requires the Social Login or OpenID Connect User Backend app, adding a layer of complexity and a third-party dependency.

Feature Comparison

Deployment & Resource Requirements

OpenCloud Deployment Options

OpenCloud ships three official deployment paths:

• Docker Compose - the recommended production setup, includes full-text search, Collabora Web Office, and all services in a single docker-compose.yml
• Docker (classic) - a simpler single-container setup without the optional services
• Bare-metal - a manual setup with the OpenCloud binary directly on the host, for minimal resource usage

Minimum requirements for a small team (up to 20 users): 2 CPU cores, 2 GB RAM. The Go binary itself uses under 200 MB at idle. The Docker Compose stack with Collabora and search needs around 2 GB total. This is a setup that runs comfortably on a €4/month VPS.

Nextcloud Deployment

Nextcloud can be deployed via Docker Compose, the All-in-One container, or traditional LAMP/LEMP stack. The All-in-One image is the recommended approach and bundles Nginx, PHP-FPM, Redis, PostgreSQL/MySQL, and Collabora.

Minimum requirements for a small team: 2 CPU cores, 4 GB RAM - and that's on the optimistic side. Real-world Nextcloud instances with a dozen active users, background jobs running, and a few apps installed comfortably consume 4–8 GB of RAM. Running the Nextcloud All-in-One on less than 4 GB RAM produces noticeable performance degradation.

# OpenCloud Docker Compose - starts in <1 second
# Total stack RAM at idle: ~200 MB (without Collabora)

$ docker compose up -d
$ docker compose ps
NAME              STATUS
opencloud         Up 1 second (healthy)

# Nextcloud All-in-One - typical startup
$ docker compose up -d
$ docker compose ps
NAME              STATUS
nextcloud-aio     Up 45 seconds (starting...)

Ecosystem & App Store

This is Nextcloud's strongest card. After nearly a decade of development and a large community, Nextcloud's app store contains over 300 apps covering everything from e-signature to Jira integration, Zammad ticketing, Discourse, Moodle, password managers, and dozens of niche utilities. If you need deep integration with a third-party tool, there is a reasonable chance a Nextcloud app exists for it.

OpenCloud's ecosystem is newer and smaller. The focus has been on getting the core platform right - performance, security, federation, and the file sharing fundamentals - before building out an app ecosystem. The official integrations cover Collabora Web Office, full-text search, and federation. Third-party integrations are growing as the project matures.

For teams whose workflow depends on specific Nextcloud apps, this matters. For teams that primarily need fast, reliable, GDPR-compliant file sharing and collaboration, the core feature set of OpenCloud covers the vast majority of requirements out of the box - without needing to install and maintain additional apps.

Verdict: Which Should You Run?

Choose OpenCloud if:

• Performance and resource efficiency matter - you want fast response times on modest hardware
• You run or plan to run a larger installation (50+ concurrent users) where PHP scaling becomes a bottleneck
• You need native OIDC/SSO integration with an existing identity provider
• GDPR compliance, audit logs, and file firewall are requirements (all built-in, not app-dependent)
• You want a modern, TypeScript-based frontend with a consistent UX
• Horizontal scalability and microservices architecture align with your infrastructure philosophy
• You need OCM 1.1 federation with other platforms
• The Blauer Engel certification (energy-efficient software) matters to your organisation

Choose Nextcloud if:

• You need built-in CalDAV/CardDAV for calendar and contact synchronisation
• You rely on specific apps from the Nextcloud app store that have no OpenCloud equivalent
• You need Nextcloud Talk for integrated video conferencing
• You want ONLYOFFICE as your Web Office solution
• Your team is already deeply familiar with Nextcloud administration
• You have a small team where the performance difference is not perceptible

OpenCloud is not just a faster Nextcloud. It is a fundamentally different piece of software that happens to solve the same user-facing problem. The Go backend, microservices architecture, and TypeScript frontend are not incremental improvements - they are architectural choices that compound into a platform that scales and performs in ways the PHP monolith never will. For new deployments in 2026, OpenCloud is the technically superior choice for file sharing. Nextcloud remains the better fit where its broader app ecosystem or built-in CalDAV are hard requirements.

wg/all offers fully managed OpenCloud hosting - we handle setup, hardening, monitoring, backups, and Collabora Web Office integration. GDPR-compliant, EU data residency, zero operational overhead on your end.