ownCloud Production Guide

Overview

ownCloud is a self-hosted file synchronization and sharing platform that gives organizations full control over their data. Originally announced by Frank Karlitschek in January 2010 during a keynote at Camp KDE in San Diego, ownCloud began as a KDE community project and became the de facto open-source alternative to Dropbox and Google Drive for enterprises that needed on-premises file storage with web, desktop, and mobile access.

In April 2016, Karlitschek and most of the core contributors left ownCloud and forked the project to create Nextcloud. This split is one of the most significant forks in open-source history. Shortly after the fork, ownCloud Inc. (the US entity) shut down, but ownCloud GmbH (Germany) secured new investors and continued. ownCloud remained a commercial entity focused on enterprise customers, while Nextcloud pursued a broader community-driven approach. Both projects share the same PHP codebase ancestry but have diverged significantly since.

In November 2023, ownCloud was acquired by Kiteworks, a US-based company focused on secure content communications. The most important technical development is oCIS (ownCloud Infinite Scale) — a complete rewrite in Go that abandons the PHP/MySQL stack entirely. oCIS is a microservices-based platform designed for massive scale, with no external database dependency, a built-in identity provider, and a fundamentally different storage architecture. A community fork of oCIS called OpenCloud has also emerged, published under Apache 2.0 and AGPL-3.0 licenses.

Two versions of ownCloud

Legacy ownCloud 10 (Classic)

PHP application (similar to Nextcloud)
Requires Apache/Nginx, MySQL/PostgreSQL, Redis
Mature, well-understood, large app ecosystem
In maintenance mode — no major new features
AGPLv3 (community) / commercial license (enterprise). No longer receiving major updates

Current oCIS (Infinite Scale)

Written in Go, single binary or Docker deployment
No PHP, no database, no Redis required
Built-in identity provider (LibreGraph / OIDC)
Spaces concept for project-based collaboration
Apache 2.0 license (source code). Note: official binary builds from ownCloud GmbH may include a separate EULA/Freemium license

Key decision

For new deployments, always choose oCIS. ownCloud 10 is in maintenance mode and will eventually reach end-of-life. oCIS is the future of the platform and offers dramatically better performance, simpler operations, and a modern architecture.

ownCloud Infinite Scale (oCIS)

oCIS is a ground-up rewrite of ownCloud in Go. It is not a refactoring or incremental improvement — it is an entirely new platform that shares the ownCloud name and mission but none of the classic codebase. The project started around 2020 and reached production readiness in 2023. As of early 2026, the latest production release is oCIS 8.0.

Why a complete rewrite?

The classic PHP ownCloud (and by extension Nextcloud) suffers from fundamental scalability limitations. PHP's request-based execution model, combined with a relational database backend for file metadata, creates bottlenecks that are difficult to overcome. oCIS was designed from scratch to solve these problems.

Key characteristics

Microservices architecture — oCIS is composed of numerous microservices (auth, proxy, storage, graph, web, search, thumbnails, collaboration, settings, etc.) that can run as a single binary or be deployed independently for horizontal scaling. The service count has grown across releases; use ocis --help to list all available services
No external database — File metadata is stored alongside files on the filesystem or in S3, eliminating the database as a bottleneck and single point of failure
Built-in IDP — oCIS includes its own OpenID Connect identity provider based on LibreGraph, so no external Keycloak or LDAP is required (though both can be integrated)
Spaces — A new collaboration model where project folders have their own quota, membership, and lifecycle, independent of any single user's account
DecomposedFS — A custom filesystem layer that stores each file version and its metadata as separate objects, enabling native S3 storage without a database
Performance — Benchmarks show oCIS handling 10–100x the concurrent users compared to classic ownCloud on the same hardware, thanks to Go's concurrency model and the elimination of per-request database queries

Recommendation

oCIS is production-ready and is the only version receiving active feature development. If a client is currently running ownCloud 10, start planning the migration to oCIS. The architectures are fundamentally different, so this is not a simple upgrade — it is a platform migration.

Architecture (Classic)

ownCloud 10 follows a traditional LAMP-style architecture that will be familiar to anyone who has deployed WordPress, Nextcloud, or similar PHP applications.

┌─────────────────────────────────────────────┐ │ Reverse Proxy │ │ (Nginx / Apache) │ └────────────────┬────────────────────────────┘ │ ┌────────────────▼────────────────────────────┐ │ ownCloud 10 (PHP) │ │ mod_php / php-fpm │ │ │ │ ┌──────────┐ ┌──────────┐ ┌───────────┐ │ │ │ WebDAV │ │ Web UI │ │ OCS API │ │ │ └──────────┘ └──────────┘ └───────────┘ │ └───┬──────────────┬──────────────┬───────────┘ │ │ │ ┌───▼───┐ ┌─────▼─────┐ ┌────▼────┐ │ MySQL │ │ Redis │ │ File │ │ Postgres│ │ (cache/ │ │ Storage │ │ SQLite │ │ locking) │ │ (local/ │ └───────┘ └───────────┘ │ NFS/S3)│ └─────────┘

Components

Web server — Apache with mod_php or Nginx with php-fpm. Apache is the officially supported option
PHP — PHP 7.4 is the primary supported version for ownCloud 10. PHP 8.x support has been limited and experimental; check release notes for the specific ownCloud 10.x version you are deploying. Required extensions include ctype, curl, dom, gd, iconv, intl, json, mbstring, openssl, pdo, and zip
Database — MySQL 8.0+ or MariaDB 10.6+ (supported from ownCloud 10.9+) recommended for production. PostgreSQL supported. SQLite only for testing
Redis — Required for file locking (transactional locking) and recommended for session storage and caching
File storage — Local filesystem (default), NFS for shared storage in multi-server setups, or S3-compatible object storage via external storage app

Limitation

The classic architecture's biggest weakness is the database. Every file operation (upload, download, rename, share) requires multiple database queries for metadata, permissions, and locking. At scale, the database becomes the bottleneck, and horizontal scaling requires complex solutions like Galera Cluster or read replicas.

Architecture (oCIS)

oCIS is a fundamentally different architecture. It is a single Go binary that embeds dozens of microservices, each handling a specific concern. In development or small deployments, all services run in a single process. In production, services can be distributed across multiple nodes. You can control which services start using OCIS_RUN_SERVICES or OCIS_EXCLUDE_RUN_SERVICES environment variables.

┌──────────────────────────────────────────────────┐ │ Reverse Proxy │ │ (Traefik / Nginx / Caddy) │ └─────────────────────┬────────────────────────────┘ │ ┌─────────────────────▼────────────────────────────┐ │ oCIS Proxy │ │ (built-in service, handles routing) │ └──┬──────┬──────┬──────┬──────┬──────┬────────────┘ │ │ │ │ │ │ ┌──▼──┐┌──▼──┐┌──▼──┐┌──▼──┐┌──▼──┐┌──▼──┐ │Auth ││Web ││Store││Graph││Srch ││Thumb│ │Svc ││Svc ││Svc ││API ││Svc ││nail │ └──┬──┘└─────┘└──┬──┘└──┬──┘└─────┘└─────┘ │ │ │ ┌──▼─────────────▼──┐┌──▼──────────────────┐ │ DecomposedFS ││ LibreGraph (IDP) │ │ (metadata + ││ Built-in OIDC │ │ file content) ││ provider │ └───────┬───────────┘└─────────────────────┘ │ ┌───────▼───────────┐ │ Storage Backend │ │ Local / NFS / S3 │ └───────────────────┘

Key services

Proxy — Built-in reverse proxy that routes requests to the appropriate microservice, handles TLS termination, and performs authentication token validation
Auth services — auth-basic, auth-bearer, and auth-machine handle different authentication flows. The built-in IDP (LibreGraph Connect / lico) provides OIDC tokens
Storage — The storage provider uses DecomposedFS to store files and metadata without a database. Each file is stored with its metadata in MessagePack sidecar files (the default since oCIS 3.0; earlier versions used extended attributes)
Graph API — MS Graph-compatible API for user/group management, replacing the legacy OCS API
Web — Serves the web UI (built with Vue.js), supports WOPI for office integration
Search — Built-in search using Bleve (Go search library), no Elasticsearch required. By default, Bleve indexes metadata (name, size, MIME type, tags, mtime). Full content extraction requires configuring Apache Tika as an additional service
Thumbnails — Generates and caches image/video thumbnails

No database

The most radical architectural decision in oCIS is the elimination of the relational database. File metadata (permissions, shares, versions, tags) is stored directly on the storage backend alongside the file content using DecomposedFS. This means the storage backend (local disk or S3) is the only stateful component. This dramatically simplifies HA, backup, and disaster recovery.

Deployment

oCIS deployment (recommended)

oCIS ships as a single Go binary or Docker image. For production, Docker Compose or Kubernetes are the recommended deployment methods.

# Minimal oCIS docker-compose.yml
version: "3.8"
services:
  ocis:
    image: owncloud/ocis:7
    entrypoint: /bin/sh
    command: ["-c", "ocis init || true; ocis server"]
    environment:
      OCIS_URL: https://cloud.example.com
      OCIS_INSECURE: "false"
      PROXY_HTTP_ADDR: 0.0.0.0:9200
      OCIS_LOG_LEVEL: warn
    volumes:
      - ocis-config:/etc/ocis
      - ocis-data:/var/lib/ocis
    ports:
      - "9200:9200"
    restart: always

volumes:
  ocis-config:
  ocis-data:

oCIS on Kubernetes

ownCloud provides an official Helm chart for deploying oCIS on Kubernetes. The chart supports splitting microservices into separate deployments for horizontal scaling.

# Clone the ownCloud Helm charts repository
git clone https://github.com/owncloud/ocis-charts.git
cd ocis-charts/charts/ocis

# Install with custom values
helm install ocis . \
  --namespace ocis --create-namespace \
  -f values.yaml

Production Kubernetes considerations

Use persistent volumes (PVCs) for data storage or configure S3 backend
Run multiple replicas of stateless services (proxy, web, thumbnails)
Storage provider should have a single writer or use S3 with proper locking
Configure an Ingress controller with TLS termination
Set resource requests and limits for each microservice

Classic LAMP stack (ownCloud 10)

Standard LAMP/LEMP deployment (Apache/Nginx + PHP + MySQL)
Install via tarball, package manager, or Docker
Requires manual PHP extension installation
Redis must be installed and configured separately
TLS via reverse proxy (Nginx/Apache) or load balancer

Recommendation

For oCIS, Docker Compose is the simplest path to production for small-to-medium deployments (up to ~500 users). For larger deployments or organizations already running Kubernetes, use the Helm chart. The single-binary nature of oCIS means there is no complex multi-container orchestration required for basic deployments.

Storage

DecomposedFS (oCIS)

DecomposedFS is oCIS's custom storage layer. Instead of storing file metadata in a database and file content on disk (like classic ownCloud), DecomposedFS stores everything on the same backend — metadata as MessagePack sidecar files next to file content (since oCIS 3.0; earlier versions used extended attributes by default).

Local filesystem — Default backend. Files and metadata stored in a structured directory tree under /var/lib/ocis/storage
S3-compatible storage — DecomposedFS can use S3 (AWS, MinIO, Ceph RGW) as the backend, storing both file content and metadata as S3 objects. This is the recommended approach for large-scale or multi-node deployments
NFS — Supported for shared local storage across nodes, though S3 is preferred for new deployments

Spaces

Spaces are a core concept in oCIS that replaces the traditional "home folder + shared folders" model. A Space is an independent storage area with its own quota, membership, and permissions. Types of Spaces include:

Personal Space — Each user's private file area (equivalent to the home folder in classic ownCloud)
Project Space — Shared collaborative areas owned by the organization, not by any individual user. When a user leaves, project spaces remain intact
Share jail — A virtual space that aggregates all files shared with a user from other spaces

File versioning

Both ownCloud 10 and oCIS support file versioning. In oCIS, versions are stored as separate blobs in DecomposedFS, making them efficient to store and retrieve. Version retention can be configured by time or count.

External storage (Classic)

ownCloud 10 supports mounting external storage sources as folders within a user's file tree:

S3-compatible object storage (AWS S3, MinIO, Ceph)
SMB/CIFS shares (Windows file servers)
SFTP servers
WebDAV endpoints
Local filesystem paths

Storage planning

When sizing storage for oCIS with DecomposedFS, account for metadata overhead. Each file creates additional metadata files (extended attributes, version tracking). For millions of small files, this overhead can be significant. S3 backends handle this better than local filesystems because they avoid inode exhaustion issues.

Authentication

Built-in IDP (oCIS)

oCIS includes a built-in OpenID Connect identity provider based on LibreGraph Connect (lico), which has its origins in Kopano Konnect. This means oCIS can function as a complete authentication system out of the box, issuing OIDC tokens for web, desktop, and mobile clients. The built-in IDP listens on port 9130 by default and is best suited for smaller installations; for larger setups, an external OIDC provider is recommended.

User management via the Graph API (MS Graph compatible)
Users stored in the embedded IDM (a lightweight LDAP-compatible directory)
Supports OIDC flows: authorization code, PKCE, client credentials

External identity providers

For enterprise deployments, oCIS can delegate authentication to an external OIDC provider:

Keycloak — Most common enterprise choice. Configure oCIS to use Keycloak as the OIDC issuer
Authentik — Open-source alternative to Keycloak
Azure AD / Entra ID — For Microsoft-centric environments
ADFS — For on-premises Active Directory environments

# oCIS with external OIDC provider (Keycloak example)
environment:
  PROXY_OIDC_ISSUER: https://keycloak.example.com/realms/owncloud
  PROXY_OIDC_REWRITE_WELLKNOWN: "true"
  WEB_OIDC_AUTHORITY: https://keycloak.example.com/realms/owncloud
  PROXY_USER_OIDC_CLAIM: preferred_username
  PROXY_AUTOPROVISION_ACCOUNTS: "true"

LDAP integration

oCIS can synchronize users and groups from an external LDAP/Active Directory server. The built-in IDM itself is LDAP-compatible, so external LDAP sources are mapped into the same user model.

Classic ownCloud 10

ownCloud 10 uses a traditional username/password model with optional backends:

Internal user database (MySQL/PostgreSQL)
LDAP/Active Directory integration
SAML/SSO via the enterprise SSO app
OAuth2 provider app for third-party integrations

Apps & Integration

Web office integration

Both ownCloud 10 and oCIS support collaborative document editing through WOPI-compatible office suites. In recent oCIS versions, the built-in collaboration service (port 9300) replaces the previously required external cs3org/wopi server:

Collabora Online — Open-source LibreOffice-based online editing. Full-featured, supports all document types. Requires a separate Collabora server (Docker container or VM). oCIS also supports Collabora's Secure View feature for restricted document viewing
OnlyOffice — Alternative online office suite with a more modern UI. Better Excel compatibility than Collabora in some cases. Also requires a separate server
Microsoft Office Online — ownCloud supports WOPI integration with Microsoft's Office Online Server (on-premises) or Microsoft 365 for enterprise customers

Desktop and mobile clients

Desktop sync client — Available for Windows, macOS, and Linux. Supports selective sync, virtual files (VFS), and multi-account. The oCIS client supports Spaces
Mobile apps — iOS and Android apps with auto-upload for photos, offline file access, and share management
WebDAV — Standard WebDAV protocol supported for third-party clients and scripting

ownCloud 10 marketplace

ownCloud 10 has a marketplace of apps that extend functionality:

File firewall (enterprise) — block uploads based on file type, size, or content
Workflow/tagging automation
Full-text search (Elasticsearch integration)
External storage backends
Branding and theming

oCIS app ecosystem

oCIS does not have an app marketplace like ownCloud 10. Instead, functionality is built into the core platform or added via Web extensions (Vue.js-based plugins for the web UI). The app ecosystem is smaller but growing. For most enterprise use cases, the core oCIS features plus a WOPI office suite cover the requirements.

ownCloud vs Nextcloud

The ownCloud/Nextcloud split is one of the most common comparison questions in the self-hosted file sharing space. Both have the same origin, but their trajectories have diverged significantly.

Aspect	ownCloud (oCIS)	Nextcloud
Technology	Go microservices (oCIS), no database	PHP monolith, MySQL/PostgreSQL required
License	Apache 2.0 (oCIS source); official binaries may include EULA	AGPLv3
Focus	Enterprise file sync & share, large-scale deployments	Broad collaboration platform (files, calendar, mail, talk, office)
Scalability	Designed for 100k+ users, microservices scale independently	Requires significant tuning above ~5k users, PHP process model limits concurrency
App ecosystem	Smaller, core-focused	Very large marketplace (200+ apps)
Community	Smaller, more enterprise-oriented	Large, active open-source community
Business model	Enterprise subscriptions, open-core	Enterprise subscriptions, fully open source
Identity	Built-in OIDC IDP, LibreGraph API	Internal user DB, LDAP, SAML (apps)
Storage	DecomposedFS (native S3 support)	Local/NFS + database for metadata, S3 primary storage (limited)
Office integration	WOPI (Collabora, OnlyOffice)	Built-in Nextcloud Office (Collabora), OnlyOffice, WOPI

Consultant's perspective

Choose ownCloud (oCIS) when the primary requirement is large-scale, high-performance file sync and share for an enterprise with thousands of users. Choose Nextcloud when the client wants an all-in-one collaboration platform with calendaring, email, video calls, and a rich app ecosystem, especially for smaller deployments (<1000 users) where the PHP stack is not a bottleneck.

Migration

ownCloud 10 to oCIS

Migrating from ownCloud 10 to oCIS is a platform migration, not a simple upgrade. The architectures are fundamentally different, and there is no in-place upgrade path. ownCloud provides migration tooling, but the process requires careful planning.

User migration — Export users from ownCloud 10 (database or LDAP) and import into oCIS via the Graph API or configure oCIS to use the same LDAP source
File migration — Use the ownCloud migration tool (owncloud/ocis-migration) to copy file data from the classic storage format to DecomposedFS. oCIS also supports an owncloudsql storage driver that can read blobs from the existing ownCloud 10 data directory and metadata from the ownCloud 10 database, enabling a gradual user-by-user migration. This is typically the most time-consuming step for large installations
Share migration — Shares (user, group, link) need to be recreated in oCIS. The migration tool handles this, but complex share hierarchies should be tested thoroughly
Client re-configuration — Desktop and mobile clients need to be reconfigured to point to the new oCIS instance. The OIDC login flow is different from classic username/password
App assessment — Identify ownCloud 10 apps in use and determine if equivalent functionality exists in oCIS. Some apps may not have oCIS equivalents

Migration complexity

For large deployments (>10TB of data, >1000 users), plan for a migration window of several days for the data copy alone. Consider running ownCloud 10 and oCIS in parallel during the transition period, using DNS or reverse proxy switching for the cutover.

Between ownCloud and Nextcloud

Since both share the same PHP ancestry, migration between ownCloud 10 and Nextcloud is technically possible but not officially supported by either project:

ownCloud 10 → Nextcloud — Nextcloud provided a migration guide for early versions. The database schema diverged significantly after Nextcloud 13, and the codebases have diverged far since the 2016 fork. For current versions, a clean install with data import via WebDAV is the most reliable approach
Nextcloud → oCIS — No direct migration path. Export data via WebDAV/command line, import into oCIS. Users must be recreated
Data-level approach — For any direction, the most reliable method is: (1) export user list, (2) copy files via WebDAV or filesystem, (3) recreate shares manually

Consultant's Checklist

Platform

New deployment? Use oCIS, not ownCloud 10
Existing ownCloud 10? Plan migration to oCIS
Need broad collaboration (calendar, mail, talk)? Consider Nextcloud instead
Need 10k+ users? oCIS is the right choice

Infrastructure

oCIS: Docker Compose for <500 users, Kubernetes for larger
Storage: S3 backend for multi-node or large-scale deployments
Local/NFS storage adequate for single-node, <5TB
TLS: always terminate at reverse proxy or load balancer

Identity

Small deployment: use oCIS built-in IDP
Enterprise with existing IdP: integrate via OIDC
Active Directory: use LDAP sync + OIDC (Keycloak or oCIS IDP)
Test OIDC flow with desktop and mobile clients before rollout

Operations

Backup strategy: snapshot storage backend (S3 versioning or filesystem snapshots)
Monitoring: oCIS exposes Prometheus metrics on /metrics
Logging: configure structured JSON logging for log aggregation
Updates: follow oCIS release notes, test in staging before production

Collaboration

Office editing: deploy Collabora or OnlyOffice alongside oCIS
Use WOPI protocol for office integration
Spaces: use project spaces for team collaboration, not personal shares
Quota: set per-space quotas, not just per-user

Migration

ownCloud 10 → oCIS: use official migration tooling
Plan for parallel running during transition
Test share migration thoroughly before cutover
Reconfigure all desktop/mobile clients post-migration

oCIS (ownCloud Infinite Scale)

Complete rewrite of ownCloud in Go with microservices architecture

What is oCIS?

oCIS (ownCloud Infinite Scale) is the next-generation ownCloud platform, rewritten from scratch in Go. It replaces the entire classic PHP/MySQL stack with a single Go binary that embeds dozens of microservices. The project started around 2020, reached general availability in 2023, and the latest production release is oCIS 8.0 (February 2026). Note that ownCloud was acquired by Kiteworks in late 2023, and a community fork called OpenCloud has also emerged.

The name "Infinite Scale" reflects the design goal: eliminate the architectural bottlenecks (relational database, PHP process model) that limited classic ownCloud to thousands of users, and enable deployments serving hundreds of thousands of users.

Key design decisions

No database — File metadata is stored alongside file content using DecomposedFS, not in MySQL/PostgreSQL. This eliminates the database as a bottleneck and single point of failure
Single binary — All microservices compile into one binary. In development, run ocis server and everything starts. In production, individual services can be scaled independently
Built-in identity — Includes a LibreGraph-based OIDC provider, so no external Keycloak or LDAP server is needed for basic deployments
Apache 2.0 license (source code) — More permissive than the classic AGPLv3, allowing commercial use without copyleft obligations. Note that official stable binary builds from ownCloud GmbH may be covered by a separate EULA/Freemium license

Running oCIS

# Initialize configuration
ocis init

# Start all services
ocis server

# Or start individual services
ocis proxy server &
ocis storage-users server &
ocis web server &

Consultant tip: oCIS is production-ready and is the only version receiving active development. Do not start new projects on ownCloud 10. The migration from ownCloud 10 to oCIS is a platform migration (not an upgrade), so factor in planning time, but the operational benefits of oCIS make it worth the effort.

LibreGraph

Open-source API and identity layer for oCIS

What is LibreGraph?

LibreGraph is an open-source project that provides a Microsoft Graph-compatible API and an identity provider for oCIS. It was created by ownCloud to provide a standards-based API for user, group, and resource management without depending on Microsoft services.

The LibreGraph API implements a subset of the MS Graph API specification, meaning clients that speak MS Graph can interact with oCIS for user/group operations. This is a strategic choice — it aligns oCIS with the most widely adopted enterprise API for identity and resource management.

Components

LibreGraph API — RESTful API for managing users, groups, and organizational resources. Endpoints like /graph/v1.0/users and /graph/v1.0/groups follow the MS Graph convention
LibreGraph Connect / lico (IDP) — An OpenID Connect identity provider embedded in oCIS, originating from Kopano Konnect. Issues JWT tokens for authentication, supports authorization code flow with PKCE. Listens on port 9130 by default. Best suited for smaller installations; larger setups should use an external OIDC provider
LibreGraph IDM — A lightweight LDAP-compatible identity store. Stores users and groups when no external LDAP/AD is configured. Based on the libregraph/idm project

Configuration

# Using oCIS built-in IDP (default)
PROXY_OIDC_ISSUER=https://cloud.example.com
# IDP automatically configured

# Using external IDP (e.g., Keycloak)
PROXY_OIDC_ISSUER=https://keycloak.example.com/realms/ocis
PROXY_OIDC_REWRITE_WELLKNOWN=true
IDP_ISS=https://keycloak.example.com/realms/ocis

Consultant tip: For small-to-medium deployments (<500 users), the built-in LibreGraph IDP is perfectly adequate and dramatically simplifies the deployment. Only bring in Keycloak or another external IDP when you need federation, social login, or integration with an existing enterprise identity infrastructure.

Spaces

Project-based collaboration model in oCIS

What are Spaces?

Spaces are a core collaboration concept in oCIS that fundamentally changes how shared storage works. In classic ownCloud (and Nextcloud), collaboration is built around sharing files from your personal folder. Spaces introduce organizational storage areas that exist independently of any user.

Types of Spaces

Personal Space — Each user gets a personal space (equivalent to the classic "home folder"). Files here are owned by the user and deleted when the user is deleted
Project Space — Created by administrators or space managers. Owned by the organization, not any individual. Has its own quota, membership list, and permissions. When a user leaves, the project space and all its data remain intact
Share Jail — A virtual space that aggregates all files and folders shared with a user from other spaces. Provides a single view of "everything shared with me"

Why Spaces matter

The biggest operational problem with classic file sharing is the "departing user" scenario. When a user who owns shared folders leaves the organization, their data is either orphaned, must be transferred to another user (creating a chain of ownership), or is deleted (breaking shares for everyone else). Spaces solve this by decoupling data ownership from user accounts.

# Create a project space via Graph API
curl -X POST https://cloud.example.com/graph/v1.0/drives \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Engineering Docs",
    "driveType": "project",
    "quota": {"total": 107374182400}
  }'

Consultant tip: When deploying oCIS, encourage clients to use Project Spaces for all team collaboration rather than sharing from personal folders. This avoids the departing-user problem and provides cleaner quota management. Each department or project should have its own Space with appropriate managers and members.

DecomposedFS

Database-free storage layer for oCIS

What is DecomposedFS?

DecomposedFS is oCIS's custom storage driver that eliminates the need for a relational database. In classic ownCloud, file metadata (path, owner, shares, permissions, versions, etags, checksums) is stored in MySQL/PostgreSQL, while file content sits on disk. DecomposedFS stores both metadata and content on the same storage backend.

How it works

Every file in DecomposedFS is identified by a unique ID (UUID), not by its path. The storage layout uses this ID-based structure:

Nodes directory — Contains the actual file content, named by UUID
Metadata — Since oCIS 3.0, stored as MessagePack (.mpk) sidecar files by default. Earlier versions used extended attributes (xattrs). The switch to MessagePack avoids xattr size limits and compatibility issues with shared filesystems like NFS. Configurable via OCIS_DECOMPOSEDFS_METADATA_BACKEND
Tree structure — Directory hierarchy is maintained through symlinks and metadata references, not through filesystem paths
Versions — Each version is a separate blob with its own metadata

# Example DecomposedFS layout on disk
/var/lib/ocis/storage/users/
├── nodes/
│   ├── ab12cd34-...-uuid1    # file content
│   ├── ab12cd34-...-uuid1.mpk  # metadata (MessagePack)
│   ├── ef56gh78-...-uuid2
│   └── ef56gh78-...-uuid2.mpk
├── spaces/
│   ├── personal/
│   │   └── user-uuid -> ../../nodes/root-uuid
│   └── project/
│       └── space-uuid -> ../../nodes/root-uuid
└── trash/
    └── ...

S3 backend

When configured with S3, DecomposedFS stores both file content and metadata as S3 objects. The metadata sidecar files become S3 objects alongside the content objects. This makes S3 a first-class storage backend without requiring a database for metadata lookup.

Consultant tip: DecomposedFS on local disk works well for single-server deployments up to ~5TB. Beyond that, or for multi-node HA deployments, configure S3 as the backend. The metadata overhead per file is small (a few KB), but with millions of files it can add up. Monitor inode usage on local filesystems.

WOPI

Web Application Open Platform Interface for online document editing

What is WOPI?

WOPI (Web Application Open Platform Interface) is a protocol created by Microsoft that enables web-based document editing. It defines a REST API that a WOPI host (file storage system like ownCloud) exposes to a WOPI client (document editor like Collabora Online or OnlyOffice) for reading and writing files.

WOPI is the standard protocol used by ownCloud (both classic and oCIS) to integrate with online office suites. When a user clicks "Edit in Collabora" in the ownCloud web UI, the WOPI protocol handles the communication between ownCloud and the Collabora server.

How WOPI works

Discovery — The WOPI client (e.g., Collabora) publishes a discovery XML listing supported file types and editor URLs
File access — ownCloud generates a WOPI access token and redirects the browser to the editor URL with the token. The editor uses the token to call ownCloud's WOPI endpoints
Lock/unlock — WOPI includes file locking to prevent conflicts during collaborative editing
GetFile/PutFile — The editor reads file content via GET /wopi/files/{id}/contents and saves via POST /wopi/files/{id}/contents
Collaborative editing — Multiple users can edit simultaneously. The editor (Collabora/OnlyOffice) handles real-time sync between users, and periodically saves back via WOPI PutFile

oCIS WOPI configuration

In recent oCIS versions, the built-in collaboration service (port 9300) replaces the previously required external cs3org/wopi server. Configure it using COLLABORATION_WOPI_SRC to set the external address that the office app will use to communicate with oCIS.

# docker-compose addition for Collabora + oCIS WOPI
services:
  collabora:
    image: collabora/code:latest
    environment:
      aliasgroup1: https://cloud.example.com
      extra_params: "--o:ssl.enable=false"
    ports:
      - "9980:9980"

  # oCIS environment variables for WOPI (collaboration service)
  ocis:
    environment:
      COLLABORATION_WOPI_SRC: https://cloud.example.com
      # App provider configuration
      APP_PROVIDER_EXTERNAL_ADDR: collabora.example.com
      APP_PROVIDER_WOPI_APP_NAME: Collabora
      APP_PROVIDER_WOPI_APP_URL: https://collabora.example.com
      APP_PROVIDER_WOPI_INSECURE: "false"

Consultant tip: WOPI integration is straightforward but requires careful attention to TLS and domain configuration. The Collabora/OnlyOffice server must be able to reach the oCIS WOPI endpoints, and the user's browser must be able to reach both the oCIS web UI and the Collabora/OnlyOffice server. In Kubernetes, this often means separate Ingress rules for each service. Test with multiple concurrent editors before declaring the integration complete.