ownCloud Infinite Scale (oCIS): a single Go binary that becomes a file sync and share platform
:atom_symbol: ownCloud Infinite Scale
At a glance
- What is it?
- oCIS replaces the classic PHP ownCloud server with a set of Go services built on reva and the CS3 APIs. The repository gives you one binary that can run a full stack on a laptop or be split into separate services, and the trade-offs sit in the deployment details rather than the feature list.
- Who is it for?
- Adopt oCIS if you want a self-hosted sync and share platform whose storage and identity layers are decoupled, and you are prepared to run it as a container or a Go build rather than a PHP application on shared hosting. Do not adopt it if you need a drop-in upgrade of an existing PHP ownCloud instance, since oCIS is a different platform with a different service model.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem oCIS solves is architectural, not feature-level
The classic ownCloud server was a PHP application with a database behind it. oCIS is a rewrite in Go that the README describes as the foundation of a data management platform, and the difference shows up in how the pieces are separated. File access is expressed through WebDAV and the CS3 APIs rather than through a monolithic application layer. That matters if you have ever tried to grow a PHP-based file service past the point where one database and one web server carry everything. The README states that Infinite Scale is delivered as a single binary or container that scales from a Raspberry Pi to a Kubernetes cluster by changing configuration and starting multiple services as needed. So the intended audience is administrators who want the same product surface (sync clients, sharing, web editing) but a deployment model where storage, identity and the front end can be sized independently. It is not aimed at someone who wants to install a package and forget it. The README pushes readers toward the prerequisites and deployment documentation before they start, which is a fair signal about where the effort goes.
reva and CS3 sit between the clients and the storage
The README names reva as the scalable server backend and lists WebDAV and CS3 as the open APIs involved. The client list is the existing ownCloud family: web, Android, iOS and Desktop. That combination is the core of the design. The clients keep speaking the protocols they already speak, and behind them reva mediates access to file spaces. Because CS3 is an API rather than a plugin interface, the services that implement it can be run together in one process or split apart. The README describes this as a multiservice architecture that allows tailoring functionality and reusing services that may already be in place, with Keycloak given as the example. Authentication follows the same pattern: users are authenticated via OpenID Connect using either an external IdP like Keycloak or the embedded LibreGraph Connect identity provider. Collaborative editing is handled separately, through a WOPI application gateway, with Collabora Online, OnlyOffice Docs and Microsoft Office Online Server named as the integrations. The data flow implied by the README is therefore: client to proxy, proxy to reva services, reva to storage, and a separate WOPI path for browser-based editing. What the README does not describe is the storage backends themselves. If the choice of backing store is what you need to evaluate, that detail is not in this material and you would need the deployment documentation.
Running it: the Docker path and the source path
The README gives two routes. The Docker route creates two host directories, changes their ownership to UID 1000, pulls owncloud/ocis, and runs an init step with --insecure yes before starting the runtime container. The runtime container binds port 9200, mounts the same two directories at /etc/ocis and /var/lib/ocis, and sets three environment variables: OCIS_INSECURE=true, PROXY_HTTP_ADDR=0.0.0.0:9200 and OCIS_URL=https://localhost:9200. The README says to use localhost:9200 as the URL and the user and password printed by the init step. The source route requires Go 1.25.10 or newer and a C compile environment, because some dependencies, including reva, need C-Go libraries and toolchains. On Debian-based systems the README gives sudo apt install build-essential. The sequence is git clone, cd ocis, make generate, make -C ocis build, then ./ocis/bin/ocis init, then IDM_CREATE_DEMO_USERS=true ./ocis/bin/ocis server, and finally opening http://localhost:9200. The README notes this source method is recommended for development purposes only. Two details are worth flagging. The ownership change to 1000:1000 is not optional decoration; the container runs as that user and will fail to write if the bind mounts are owned by someone else. And OCIS_URL is set to https while OCIS_INSECURE is true, which is the combination the README uses for a local evaluation, not a production posture.
The init step is a real gate, and the README does not enumerate its output
The Docker quickstart separates ocis init from ocis server, and the source quickstart does the same. The init run is what produces the credentials the README tells you to use, and it is also the step that writes configuration into /etc/ocis. That means the configuration directory is state, not a throwaway. If you delete $HOME/ocis/ocis-config between runs, you lose the generated credentials and the instance you start will not match the one you initialised. The README does not list which configuration keys init writes, nor does it describe how to rotate the generated credentials afterwards. It also does not say what happens if you run init against a directory that already contains configuration. Those are gaps you should expect to fill from the admin documentation rather than from the repository. The --insecure yes flag on the init command is likewise unexplained here beyond its name; the README pairs it with OCIS_INSECURE=true at runtime, so the two belong together, but nothing in this material describes what is actually relaxed when they are set.
Where oCIS is the wrong tool
The source build is the clearest limitation. It needs Go 1.25.10 and a C toolchain, which rules out environments where you cannot install build-essential or an equivalent. The README itself scopes that path to development. The second limitation is deployment shape. The README is explicit that before setting up an instance you should read the prerequisites, the deployment section, and the general information page that applies to all deployment types. A project that tells you to read three documents before you begin is telling you that the defaults are not the whole story. The third is identity. If you already run an IdP that does not speak OpenID Connect, the README offers no bridge; the two options it names are an external OIDC provider or the embedded LibreGraph Connect. The fourth is scope of integration. Web office editing depends on a separate WOPI application gateway, so the office suite is not part of the oCIS deliverable. Nothing in this material suggests oCIS is a drop-in replacement for an existing PHP ownCloud installation, and treating it as one would be a mistake.
How this differs from the PHP ownCloud server
The comparison that matters is with ownCloud's own previous generation, because that is what the README positions oCIS against. The old server was a PHP application you deployed onto a web server with a database. oCIS is a Go program that ships as a binary or a container and, according to the README, needs no external database and no external IdP for a minimal run. The README states this directly after the source quickstart: no external database, no external IDP needed. The API surface also differs. The old server exposed its own interfaces; oCIS is built on reva and CS3 and speaks WebDAV, which is why the existing desktop and mobile clients can be pointed at it. The practical consequence is that the operational skills change. You are no longer tuning PHP and a MySQL instance; you are managing a container, a configuration directory, and possibly a set of separately started services. If your team's experience is in PHP hosting, that is a real cost. If your team already runs Go services and Kubernetes, the same design is the reason oCIS fits.
Maintenance, versioning and the licence
The repository shows v8.0.8 and v8.2.0 released within about two weeks of each other, with v8.0.7 before them. That pattern indicates parallel maintenance lines rather than a single moving target, so an operator on 8.0.x is not automatically pulled onto 8.2.x. The README does not describe an upgrade procedure, a database migration step, or a compatibility guarantee between minor lines, so the cost of upgrading is not something this material lets you estimate. On licensing, the repository carries Apache-2.0 and the README links to the Apache 2.0 text. Apache-2.0 permits commercial use and modification and includes a patent grant. The README also mentions an End User License Agreement section and a Copyright section, which suggests there is more than one document governing use of the project. This is not legal advice; if you are redistributing oCIS or bundling it into a product, read the EULA linked from the README alongside the Apache-2.0 terms, because the presence of both is worth understanding before you ship.
Editorial conclusion
Adopt oCIS if you want a self-hosted sync and share platform whose storage and identity layers are decoupled, and you are prepared to run it as a container or a Go build rather than a PHP application on shared hosting. Do not adopt it if you need a drop-in upgrade of an existing PHP ownCloud instance, since oCIS is a different platform with a different service model. Before committing, verify three things from the documentation: the prerequisites page, the general information page that applies to all deployment types, and whether your identity provider can speak OpenID Connect or you intend to use the embedded LibreGraph Connect.
Community notes