# ownCloud Infinite Scale (oCIS): a Go file sync and share server you can start with one docker run

> oCIS is ownCloud's rewrite of its file sync and share platform in Go, built on reva and CS3 APIs. It installs as a single binary or container, ships an embedded identity provider, and scales from a Raspberry Pi to Kubernetes by configuration alone.

**owncloud/ocis** — :atom_symbol: ownCloud Infinite Scale

- Repository: https://github.com/owncloud/ocis
- Website: https://doc.owncloud.com/ocis/
- Stars: 2,134 · Forks: 275
- Language: Go
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/owncloud-ocis

## The problem oCIS solves, and who ends up running it

ownCloud Infinite Scale is the successor platform to the original ownCloud server, written in Go rather than PHP. The README describes it as "the new file sync & share platform that will be the foundation of your data management platform." The practical problem it addresses is running a file sync and share service without assembling a stack of external dependencies first. The repository states that a local instance comes with "All batteries included: no external database, no external IDP needed!" That single sentence is the whole pitch: one process, one data directory, one config directory.

The audience is narrower than "everyone who wants Dropbox at home." oCIS is aimed at administrators who need to keep files on infrastructure they control, and at organizations that want to start small and grow the deployment without changing products. The README frames the scaling story explicitly: a single binary or container "allows scaling from a Raspberry Pi to a Kubernetes cluster by changing the configuration and starting multiple services as needed." If you are evaluating this as a personal file server for two people, that scaling machinery is weight you will carry and never use. If you are replacing a departmental share, it is the reason to look at oCIS rather than a lighter WebDAV daemon.

## How the multiservice architecture and reva backend fit together

oCIS is not one monolithic process. The Makefile lists the OCIS_MODULES variable, and it enumerates the services the project builds: activitylog, antivirus, app-provider, app-registry, audit, auth-app, auth-basic, auth-bearer, auth-machine, auth-service, clientlog, collaboration, eventhistory, frontend, gateway, graph, groups, idm, idp, invitations, nats, notifications, ocdav, ocm, ocs, policies, postprocessing, proxy, search, settings, sharing, sse, storage-system, storage-publiclink, storage-shares, storage-users, thumbnails, userlog, users, web, webdav and webfinger. That list is the architecture. Each name is a service that can run inside the single binary or as a separately started component.

The storage and API layer comes from reva, referenced in the README as the scalable backend, with CS3 APIs and WebDAV as the interfaces. Clients talk to the proxy on port 9200; the proxy routes to the frontend and the storage services. Authentication is OpenID Connect, served either by an external identity provider such as Keycloak or by the embedded LibreGraph Connect IdP. The nats service provides the messaging backbone between components, and the search service uses Bleve, visible in go.mod as github.com/blevesearch/bleve/v2.

This design has a direct operational consequence. Because services are separable, you can reuse infrastructure you already run, for example pointing oCIS at an existing Keycloak instead of the embedded IdP. The cost is that the number of moving parts you can configure is large, and the README redirects you to the deployment documentation rather than describing the topology itself. Anyone expecting a single config file that explains the whole system will be disappointed.

## Installing oCIS with Docker and reaching the web UI

The README's quickstart is the shortest path to a running instance. It creates two host directories, hands them to user ID 1000, pulls the image, initializes a configuration, then starts the server. The initialization step prints the credentials you will use to log in, so keep the terminal output.

```bash
mkdir -p $HOME/ocis/ocis-config
mkdir -p $HOME/ocis/ocis-data
sudo chown -Rfv 1000:1000 $HOME/ocis/
docker pull owncloud/ocis
docker run --rm -it \
    --mount type=bind,source=$HOME/ocis/ocis-config,target=/etc/ocis \
    --mount type=bind,source=$HOME/ocis/ocis-data,target=/var/lib/ocis \
    owncloud/ocis init --insecure yes
```

The init run mounts the config directory at /etc/ocis and the data directory at /var/lib/ocis, which are the paths the image expects. Note the --insecure yes flag: this quickstart deliberately runs without TLS, which is why the second command sets OCIS_INSECURE=true and points OCIS_URL at https://localhost:9200. Do not carry those settings into anything reachable from a network you do not control.

```bash
docker run \
    --name ocis_runtime \
    --rm -it \
    -p 9200:9200 \
    --mount type=bind,source=$HOME/ocis/ocis-config,target=/etc/ocis \
    --mount type=bind,source=$HOME/ocis/ocis-data,target=/var/lib/ocis \
    -e OCIS_INSECURE=true \
    -e PROXY_HTTP_ADDR=0.0.0.0:9200 \
    -e OCIS_URL=https://localhost:9200 \
    owncloud/ocis
```

PROXY_HTTP_ADDR is what makes the proxy listen on all interfaces inside the container so the port mapping works. After the container starts, the README says to open localhost:9200 and log in with the user and password printed during init. That is the bundled web UI, served by the web service in the module list.

If you prefer to build from source, the README requires Go 1.25.10 or newer and a C compile environment, because reva pulls in C-Go components. On Debian-based systems the prerequisite command is sudo apt install build-essential. The build sequence is make generate, make -C ocis build, then ./ocis/bin/ocis init, then IDM_CREATE_DEMO_USERS=true ./ocis/bin/ocis server. The README marks this path as recommended for development purposes only.

## Where oCIS is the wrong choice

The README does not document rollback. There is no section describing how to return to a previous release after an upgrade, and no statement about schema or data migration guarantees between versions. For a system whose data directory is the point of the deployment, that silence matters more than any missing feature. If your organization requires a tested downgrade procedure before it will approve a platform, you will have to build that procedure yourself, and the project has not given you the material to do it from the README alone.

The quickstart is also explicitly not a production configuration. It runs insecure, binds the proxy to 0.0.0.0, and creates demo users when you pass IDM_CREATE_DEMO_USERS=true. The README points production readers at the Prerequisites, Deployment and General Information pages, and says it "highly" recommends reading them before setting up an instance. Treat that as a requirement rather than a suggestion.

Finally, oCIS assumes you want the ownCloud client ecosystem. The README lists web, Android, iOS and Desktop clients, and the sync model is file spaces over WebDAV and CS3. If what you actually need is a document collaboration server, or a plain object store with an S3 API, oCIS is a layer above those concerns and you would be adopting a sync platform to get something else.

## oCIS compared with Nextcloud, Seafile and the classic ownCloud server

The most common comparison is Nextcloud, and the difference is architectural rather than feature-level. Nextcloud is a PHP application with a database behind it and a large app ecosystem; oCIS is a set of Go services with an embedded identity provider and no external database required for a basic instance. If your team already runs PHP and wants the app catalogue, Nextcloud asks less of you. If you want a compiled service you can scale by starting more instances of specific components, oCIS is built for that from the start.

Against Seafile, the split is in the storage and sync model. Seafile is known for its own block-based sync protocol and library concept. oCIS exposes WebDAV and CS3 APIs instead, which means existing WebDAV tooling and the ownCloud desktop client work against it without a proprietary sync layer. That openness is a real difference, not a marketing one: WebDAV is a published standard and CS3 is a public API repository.

The comparison the project itself invites is with the older ownCloud server. The README calls oCIS "the new file sync & share platform" and the repository is a separate Go codebase, so this is a successor rather than a version bump. Migrating from the PHP server means moving to a different architecture, not upgrading in place. There is also an OpenCloud comparison circulating in search results; this repository does not describe OpenCloud, so treat any such comparison as outside what it documents.

## Maintenance, licensing and what upgrades cost you

The repository is not archived, and the last push was on 2026-09-10. Releases arrive on a steady cadence: v8.0.8 on 2026-08-21, v8.2.0 on 2026-08-10, and v8.0.7 on 2026-07-31. Note that the version numbers do not sort the way you might expect, with v8.0.8 published after v8.2.0. That pattern suggests parallel maintenance lines rather than a single linear upgrade path, and it is a reason to read the changelog before picking a version. The repository keeps a CHANGELOG.md at the top level and a changelog/ directory alongside it.

The licence is Apache-2.0, stated in the README badge and in the LICENSE file. Apache-2.0 permits commercial use and modification and includes an explicit patent grant, which matters if you are embedding oCIS in a product. The repository also carries a LICENSES/ directory and a REUSE.toml, indicating REUSE-compliant licence metadata, which helps if you need to audit third-party components. This is not legal advice; check the NOTICE file and the per-component licences yourself before shipping.

Upgrade cost is the weak spot in the documentation. The README tells you how to start, not how to move between releases. Because data lives in the bind-mounted /var/lib/ocis directory and configuration in /etc/ocis, an upgrade in the container workflow means replacing the image and restarting against the same mounts. Whether that is safe across a given pair of versions is not stated in the README. Budget time to read the changelog and the deployment documentation for each jump, and test on a copy of the data directory first.

## Conclusion

Adopt oCIS if you want a self-hosted file sync and share platform that starts as one container and can later be split into services, and if you are willing to read the prerequisites and deployment pages before touching a production instance. Do not adopt it if you need a documented rollback path or an upgrade procedure you can follow without reading the changelog, because the README does not describe either. Verify first that your target deployment matches the official Ubuntu compose production example, that your IdP choice is settled (embedded LibreGraph Connect or an external Keycloak), and that Go 1.25.10 or newer is available if you intend to build from source.

## FAQ

### What are the benefits of using ownCloud Infinite Scale?

The README highlights a single binary or container that needs no external database and no external identity provider, and that can scale from a Raspberry Pi to a Kubernetes cluster by changing configuration and starting multiple services. It also exposes open APIs, WebDAV and CS3, so existing ownCloud clients work against it.

### Is ownCloud Infinite Scale free?

The repository is licensed under Apache-2.0, as shown in the README badge and the LICENSE file, so the source is available under those terms. The README does not describe commercial editions or paid plans, so pricing is not something this repository answers.

### How do I install ownCloud Infinite Scale?

The README quickstart creates $HOME/ocis/ocis-config and $HOME/ocis/ocis-data, runs owncloud/ocis init --insecure yes against those mounts, then starts the owncloud/ocis container with port 9200 published and OCIS_INSECURE=true. It then tells you to open localhost:9200 with the credentials printed during init.

### What is ownCloud Infinite Scale compared with the classic ownCloud server?

oCIS is a separate Go codebase rather than a version bump of the PHP server, described in the README as the new file sync and share platform. Moving from the classic server therefore means changing architecture, not upgrading in place.

### Which is better in 2026, Nextcloud or ownCloud?

The two differ architecturally: Nextcloud is a PHP application with a database behind it, while oCIS is a set of Go services that needs no external database or identity provider for a basic instance. Which fits depends on whether you want a PHP app ecosystem or compiled, separately scalable services.

## Sources

- [License: Apache-2.0](https://github.com/owncloud/ocis/blob/master/LICENSE)
- [owncloud/ocis on GitHub](https://github.com/owncloud/ocis)
- [Project website](https://doc.owncloud.com/ocis/)
- [README](https://github.com/owncloud/ocis/blob/master/README.md)
- [Releases](https://github.com/owncloud/ocis/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/owncloud-ocis