Why OpenCloud looks promising and what still holds me back

[tamis-laan]

I’d like to explain why I’m considering a move from Nextcloud to OpenCloud.

Why OpenCloud is appealing

First, there are some fundamental architectural reasons.

Nextcloud is built on PHP, which makes it feel slow and heavy in practice. Performance tuning helps, but the baseline remains bulky.
OpenCloud, by contrast, is written in Go. It’s lean, fast, and predictable in resource usage.

Second, Nextcloud tries to be many things at once. Over time it has grown into a broad application platform, which adds complexity and dilutes focus away from its core role as a file sync and sharing system.
OpenCloud feels more opinionated and focused on doing one thing well.

Finally, OpenCloud’s file-based storage model is a major plus. It’s transparent, easy to reason about, and straightforward to back up without special tooling or database gymnastics.

What’s blocking migration

That said, there are still a few blockers that make a full migration difficult.

CalDAV and CardDAV support are missing. While OpenCloud can integrate with Radicale, that means introducing an extra Python service. At that point, the question becomes: why migrate away from Nextcloud just to reintroduce comparable complexity elsewhere?

The Collabora integration also raises questions. Needing a separate “collaboration” service container feels like an internal implementation detail leaking into the deployment model. Why isn’t this more tightly integrated, or at least abstracted so users don’t need to reason about it?

Lastly, the Docker Compose setup is problematic from an ergonomics point of view. Requiring users to clone a repository and run a composite Compose project makes the setup opaque and hard to customize. A set of clear, standalone example docker-compose.yml files would be far preferable—pick what you need, adapt it, and move on.

[404invalid-user]

i agree with the docker compose/config it so complicated been trying for 3 days now to get Oauth2 working with authentik and an ldap outpost working.

but i do like Collabora is a separate container i dont ever see myself using that so its nice to have it disabled outright

[tamis-laan]

but i do like Collabora is a separate container i dont ever see myself using that so its nice to have it disabled outright

This might be a misunderstanding, in order to get collabora working the current implementation needs 3 containers. OpenCloud, Colaboration and Colabora.

The collaboration container should be merged with the OpenCloud container. The collaboration process could run or not just based on the environment variables being set or not. There is really no need to have an extra container running, it could all be done in a single OpenCloud container hiding the complexity and simplifying the setup process for the user.

[butonic]

It should be possible to use the START_ADDITIONAL_SERVICES="collaboration" env var and add the collaboration related env vars to the opencloud container itself. It should also be possible to move the collaboration service behind the opencloud proxy ... that would get rid of the additional wopiserver subdomain. Ping me in a PR if you need a review.

[tamis-laan]

Oh yes! Do you have an example docker compose using START_ADDITIONAL_SERVICES="collaboration" for me? I have never been able to get this running trying to dissect the docker compose files. This would simplify things a lot. This is what I have right now:

services:
  opencloud:
    image: opencloudeu/opencloud-rolling:latest
    user: 0:0
    entrypoint:
      - /bin/sh
    command: ["-c", "opencloud init || true; opencloud server"]
    ports:
      - 80:9200
    environment:
      PROXY_HTTP_ADDR: "0.0.0.0:9200"
      IDM_ADMIN_PASSWORD: "admin"
      FRONTEND_ARCHIVER_MAX_SIZE: "10000000000"
      FRONTEND_CHECK_FOR_UPDATES: true
      PROXY_TLS: false
      PROXY_ENABLE_BASIC_AUTH: false
      OC_INSECURE: true
      OC_PROXY_HTTP_ADDR: "0.0.0.0:9200"
      OC_URL: https://files.mydomain.com
      # Collabora
      COLLABORA_DOMAIN: office.mydomain.com
      NATS_NATS_HOST: 0.0.0.0
      GATEWAY_GRPC_ADDR: 0.0.0.0:9142
      FRONTEND_APP_HANDLER_SECURE_VIEW_APP_ADDR: http://collaboration:9300
      GRAPH_AVAILABLE_ROLES: "b1e2218d-eef8-4d4c-b82d-0f1a1b48f3b5,a8d5fe5e-96e3-418d-825b-534dbdf22b99,fb6c3e19-e378-47e5-b277-9732f9de6e21,58c63c02-1d89-4572-916a-870abc5a1b7d,2d00ce52-1fc2-4dbc-8b95-a73b73395f5a,1c996275-f1c9-4e71-abdf-a42f6495e960,312c0871-5ef7-4b3a-85b6-0e4074c64049,aa97fe03-7980-45ac-9e50-b325749fd7e6"
    volumes:
      - /srv/opencloud/config:/etc/opencloud
      - /srv/opencloud/data:/var/lib/opencloud
    restart: always

  collabora:
    image: collabora/code:25.04.7.1.1
    restart: always
    environment:
      aliasgroup1: https://files.mydomain.com
      DONT_GEN_SSL_CERT: "YES"
      extra_params: |
        --o:ssl.enable=false \
        --o:ssl.termination=true \
        --o:welcome.enable=false
      username: admin
      password: admin
    ports:
      - 9980:9980
    cap_add:
      - MKNOD

  collaboration:
    image: opencloudeu/opencloud-rolling:latest
    user: 0:0
    environment:
      COLLABORATION_HTTP_ADDR: 0.0.0.0:9300
      COLLABORATION_GRPC_ADDR: 0.0.0.0:9301

      MICRO_REGISTRY: nats-js-kv
      MICRO_REGISTRY_ADDRESS: opencloud:9233

      COLLABORATION_WOPI_SRC: https://files.mydomain.com
      COLLABORATION_APP_NAME: CollaboraOnline
      COLLABORATION_APP_PRODUCT: Collabora
      COLLABORATION_APP_ADDR: https://office.mydomain.com
      COLLABORATION_APP_ICON: https://office.mydomain.com/favicon.ico

      COLLABORATION_APP_INSECURE: "true"
      COLLABORATION_CS3API_DATAGATEWAY_INSECURE: "true"

      OC_URL: https://files.mydomain.com
    volumes:
      - /srv/opencloud/config:/etc/opencloud
    entrypoint: ["/bin/sh"]
    command: ["-c", "opencloud collaboration server"]
    depends_on:
      opencloud:
        condition: service_started
    restart: always

To much containers, to much complexity and to many settings. Makes it hard to debug and I eventually gave up on it.

[butonic]

Lastly, the Docker Compose setup is problematic from an ergonomics point of view. Requiring users to clone a repository and run a composite Compose project makes the setup opaque and hard to customize. A set of clear, standalone example docker-compose.yml files would be far preferable—pick what you need, adapt it, and move on.

Well, we are getting FLAK for the way we structured the compose files, regardless of how we do it. It is hard to build a set of compose files that play well together without them being tied to each other like we did it. You compose the deployment according to your needs. With the current compose files you can use one .env file to configure what you need. Problems with using authentik or authelia are being worked on, but in principle you can configure an external IDP.

The dependencies of opencloud are many, and that complexity can only be hidden to a degree. We try to describe the compose setup in the docs. How would you document the installation with just a set of example docker compose files? Unfortunately, there are already too many variations in configuration for it to be simple.

We could be even more opinionated and maintain only two flavors of the compose stack. We need at least one that contains all features and integrates keycloak, tika, collabora, antivirus ... everything. And one where we let users integrate external services. Then when something changes we have to update both. 😞 The current compose stack combines the two flavors by using a default configuration that represents our idea of a fully working OpenCloud deployment. It can be customized to accomodate several use cases ...

Maybe we should add more example .env files? Any ideas are welcome.

[404invalid-user]

id love an update too I also use authentik currently using opencloud with it's built in Auth which is good enough but id love to add OIDC

[micbar]

The server change #2072 is ready to be merged.

Then we need 4 pull requests and releases on every client.

[tamis-laan]

The problem is that the example is very opinionated, which in a sense is good because it allows some people to get started without having to know much about docker and docker compose. But most of the time you need to integrate things in your own stack and streamline it with how things are done locally. And it's at this point in the majority of cases where all these layers of abstraction start to work against you.

If we just have a couple of docker compose files as examples with comments it becomes way easier to integrate into our own stack.

Or a single docker compose file that integrates everything that I can strip down if there are things I don't want to use would be great.

[BrodyCloud]

Maybe a bash builder file that has the full config as default but can strip down parts and leave the necessities. Then it's user configurable on setup. Then future add-ons/additions can keep the separate but compatible idea without becoming a bloated compose to self build.

[micbar]

Like I said, there will be an UI based wizard to create compose files.

[dragonchaser]

@tamis-laan I agree with you on the compose issue. This is IMHO way to opinionated and locks out people using certain deployment environments (e.g. portainer). I hand-crafted my own compose setup from the dev examples in the main repo.

[micbar]

We have a concept for adding a low barrier web config wizard in an upcoming new feature for our compose project.

[tamis-laan]

Indeed most of the time one needs to write it's own docker compose if it's part of a larger deployment.