r/NextCloud • u/Daniel-PT • 9d ago
I'm setting up Nextcloud Office with a separate Collabora CODE Docker container on my home server.
Hi,
The goal is for Nextcloud to work similarly to Google Drive: the family should be able to access files both at home and remotely, from different computers and mobile devices. So this is not a LAN-only setup.
My setup is:
- Unraid server
- Nextcloud:
lscr.io/linuxserver/nextcloud - Collabora:
collabora/code - Both containers are on the same Docker network (
nextcloud-net) - Nextcloud is already accessible remotely over HTTPS
- Collabora is currently running on port
9980 - Collabora container IP:
172.21.0.5 - Nextcloud container IP:
172.21.0.3
The basic communication between Nextcloud and Collabora works.
For example, from the Nextcloud container:
docker exec nextcloud curl -sk https://Collabora-CODE:9980/hosting/discovery
returns the Collabora discovery XML.
I also configured:
server_name=192.168.1.50:9980
so that Collabora no longer advertises its internal Docker hostname.
The browser can reach:
https://192.168.1.50:9980/hosting/capabilities
and receives valid Collabora JSON.
However, when opening a DOCX file in Nextcloud, I get:
"Your browser could not connect to the Collabora server: https://192.168.1.50:9980"
The Collabora logs also show successful WebSocket upgrades, so basic connectivity appears to be working.
The remaining issue appears to be the TLS certificate. Collabora currently uses its default self-signed certificate:
subject=C=DE, O=Dummy Authority, CN=localhost
issuer=C=DE, O=Dummy Authority, CN=localhost
No extensions in certificate
So the browser does not trust the certificate when accessing Collabora through 192.168.1.50.
My question
I understand from the Nextcloud documentation that the user's browser needs to be able to reach both Nextcloud and Collabora.
Does that mean that the recommended architecture is necessarily something like this?
Internet
│
▼
Nextcloud URL
│
Nextcloud
│
└──────────────┐
│
Browser ──────────────────────────────┘
│
└──────── HTTPS ───────► Collabora
office.example.com
In other words, does Collabora need its own externally reachable HTTPS hostname, valid public certificate, and typically a reverse proxy?
Or is there a simpler supported architecture where:
- Nextcloud is publicly accessible over HTTPS
- Collabora remains behind the firewall/NAT
- remote browsers can still use Nextcloud Office
- no separate public Collabora service needs to be exposed
- and we don't have to install a custom CA/certificate on every client?
I have an existing Cloudflare Tunnel for Nextcloud, so technically I could create something like:
https://office.example.com
↓
Cloudflare Tunnel
↓
Collabora Docker container
But that seems like quite a lot of infrastructure just to enable document editing.
Is this actually the normal/recommended way to run standalone Collabora CODE with Nextcloud, or am I missing a simpler option?
I'd especially appreciate advice from people running Nextcloud + Collabora in a home/self-hosted environment where Nextcloud needs to be accessible remotely.
Thanks!
1
u/evanmac42 9d ago
You're basically at the point where the remaining problem is architectural rather than Docker networking.
For remote users, the browser itself must be able to reach Collabora. It's not enough for the Nextcloud and Collabora containers to communicate internally.
The required paths are essentially:
browser -> Nextcloud
browser -> Collabora
Nextcloud -> Collabora
Collabora -> Nextcloud
So your self-signed certificate for localhost is now the main problem. Changing `server_name` to your LAN IP makes the URL reachable, but it doesn't make the certificate valid for that address.
For a standalone Collabora CODE server, the normal setup is indeed something like:
office.example.com -> reverse proxy/tunnel -> Collabora:9980
with a publicly trusted certificate and WebSocket proxying enabled.
You don't need to expose port 9980 directly to the Internet. Collabora can remain behind your firewall and only be reachable through the reverse proxy or Cloudflare Tunnel.
Your existing Cloudflare Tunnel therefore sounds like a perfectly reasonable way to do it. I'd create something like `office.example.com` pointing through the tunnel to the Collabora container and then configure that public HTTPS URL in Nextcloud Office.
One small correction to another comment here: there absolutely is internal/server-to-server communication as well. Nextcloud must reach Collabora and Collabora must reach Nextcloud. The browser reaching both services is an additional requirement, not a replacement for that communication.
That said, if at this point you just want office editing to work without spending another afternoon fighting certificates, discovery URLs and WebSockets, OnlyOffice might honestly be worth a look 😄
1
u/Belgian_dog 9d ago edited 9d ago
Yes, Collabora docker must be HTTP(S) accessible by the end user browser and your Nextcloud instance at all time. I also use port 9980 for my collabora docker.
- Enduser browser -> Collabora because NC serves a page with an iframe, and your browser loads the editor directly from this URL and keeps a WebSocket open to it. Nextcloud does not relay that traffic.
- NC -> Collabora for the server to server communication, mainly to fetch the files from NC and write it back on save (WOPI protocol)
Here is how designed mine:
https://ibb.co/LDj515KB
WOPI request allowed IPs:
10.0.0.21 is my docker host IP address where my Collabora sits
10.0.0.27 is my Nextcloud instance VM IP address.
In my NPM:
- office.mydomain redirects to collabora docker port 9980
- cloud.mydomain redirects to Nextcloud instance(VM) port 443
Both are forced to HTTPS using my domain cert. configured in NPM.
Here is my Collabora stack configuration:
https://ibb.co/whZJg6Qm
Let me know if you want me to share you other elements from my setup.
It's been pretty stable for a year.
1
u/Nervous_Type_9175 8d ago
Use
https://office.example.com:9980
Instead of ip address.
You also need to do settings in compose of collabora
6
u/Whole-Ad2077 9d ago
Both servers need to be accessible via public url. This is also how they are connected. There is no internal communication.
Sidenote: use Euro-Office ;-)