Illustrative example: Imagine a small team whose Nextcloud files are hosted at https://cloud.example.com. Its administrator wants a separate Collabora Online Development Edition (CODE) server at https://office.example.com. This is a hypothetical setup for explaining the steps, not a report of a real installation. Replace both example hostnames with domains you control.
CODE runs as a separate service beside Nextcloud. Docker starts the Collabora service; a TLS reverse proxy publishes it; and the Nextcloud Office integration connects the two. Your browser must be able to reach the public office URL, and the servers must be able to reach the relevant Nextcloud and Collabora endpoints. The current Nextcloud Office installation manual describes Docker as one deployment option and notes that a dedicated server commonly needs a reverse proxy.
Before you start
For the example, assume a Linux host can run Docker, Nextcloud already works over HTTPS, and DNS records for both hostnames point to the correct servers. Obtain a valid TLS certificate for office.example.com. Plan to expose the Collabora service through that hostname, rather than opening its Docker port directly to the public internet.
- Confirm that the CODE host can resolve and connect to
cloud.example.com.
- Confirm that browsers can reach
https://office.example.com on HTTPS.
- Choose whether the reverse proxy runs on the Docker host or elsewhere. A proxy on the same host can use a loopback-published container port; a proxy in another container needs a reachable shared Docker network or another private route.
- Check the current CODE and Nextcloud documentation for compatibility and proxy requirements before production use. CODE is the Development Edition; teams that need vendor-backed stability or support should assess a supported Collabora Online offering.
The commands below use the official collabora/code image name and a single Nextcloud origin. The examples do not pin a release tag, so an administrator should decide on a versioning and update policy rather than treating latest as a production change-control strategy.
1. Point the office hostname to your server
Create a DNS A or AAAA record for office.example.com that points to the host or load balancer serving Collabora. Configure the reverse proxy to terminate HTTPS with a certificate valid for that name and forward the Collabora application paths and WebSocket traffic to the CODE container. Collabora’s official reverse-proxy documentation provides proxy-specific examples; use the section for your actual proxy software and current CODE release.
Do not copy a generic proxy snippet blindly. The proxy must support WebSocket upgrades, preserve the required host and forwarded-protocol information, and pass Collabora routes such as /browser, /hosting/discovery, and /cool. The exact directives differ between Apache, NGINX, Traefik, and other gateways. If the proxy runs on the Docker host, forwarding to 127.0.0.1:9980 is a common private target. If it is a separate container, that loopback address refers to the proxy container itself, not the CODE host.
2. Start the CODE Docker container
On the Docker host, pull and start the container. In this example the port is bound to loopback so it is not directly exposed on every host network interface:
docker pull collabora/code
docker run -d --name collabora -p 127.0.0.1:9980:9980 -e 'aliasgroup1=https://cloud.example.com:443' --restart always --cap-add MKNOD collabora/code
The aliasgroup1 value authorizes the Nextcloud origin that is expected to use this CODE service. Keep the scheme and hostname aligned with the URL people use to access Nextcloud; include a nondefault port if the public Nextcloud service uses one. If multiple Nextcloud instances will use the service, configure the additional allowed host groups according to the current CODE image documentation instead of broadly allowing arbitrary hosts.
This command assumes that the reverse proxy is on the same machine and forwards to the loopback port. If you are using Docker Compose, a containerized proxy, or a remote proxy, adjust networking and port exposure deliberately. Avoid exposing port 9980 publicly just to make a proxy connection work; use a private Docker network, firewall rule, or other restricted path. For the CODE Docker image’s current options, consult Collabora’s CODE Docker guide.
3. Configure the reverse proxy and check CODE
After the proxy is configured, reload it using the method for your software and check its configuration before applying changes. Then request the public discovery endpoint from a machine that can reach the domain:
curl -fsS https://office.example.com/hosting/discovery | head
A successful response should contain XML discovery information rather than a proxy error page. This check confirms that the public URL reaches a Collabora endpoint; it does not prove that Nextcloud authorization, WebSockets, or document editing work yet. Also inspect the container if the endpoint fails:
docker ps --filter name=collabora
docker logs --tail=100 collabora
In the hypothetical setup, a refused connection to the public URL points first to DNS, TLS, firewall, or proxy routing. A 502 response usually means the proxy cannot reach the container’s configured upstream. If discovery works but the editor later fails during loading, check WebSocket forwarding and whether the proxy reports an upgrade or upstream error.
4. Connect Nextcloud to Collabora
In Nextcloud, open the Apps area and install or enable the office integration offered for your version. The app label may be “Nextcloud Office” or “Collabora Online,” depending on the release and installed app catalog. Then open the administration settings for Office and enter:
https://office.example.com
Save the setting and review the connection status. Nextcloud’s Office configuration documentation identifies this field as the URL and port of the Collabora server and recommends HTTPS. Use the public Collabora URL that browsers can reach. In split-DNS, NAT, or segmented-network installations, Nextcloud may also need an internal route to that service; consult the advanced connection options for your installed app version rather than assuming public DNS works from the server.
For the example, Nextcloud sees cloud.example.com as the allowed WOPI host, and users’ browsers open the editor from office.example.com. If your Nextcloud administration page offers a WOPI request allow list, restrict it to the expected Collabora server addresses after confirming the correct addresses in your network. Nextcloud advises limiting WOPI requests to expected Collabora hosts; do not add broad ranges without a specific network reason.
5. Test with a sample document
Sign in as a regular Nextcloud user, create a small text document or open a disposable test file, and choose the browser editor. Confirm that the editor toolbar loads, make a harmless change, wait for the save indicator, close the file, and reopen it to verify that the change persisted. If the installation supports simultaneous editing, open the same test file in a second user session and confirm that presence or edits update as expected.
These checks separate the main layers: the discovery request tests public routing; the Nextcloud status tests the configured server connection; opening the editor tests browser access and WOPI exchange; and reopening the file tests the save path. Do not use an important document for the first test. CODE is a development edition, so a successful test is not a substitute for evaluating availability, resource capacity, backups, and support needs for your organization.
Common problems and what to check
Nextcloud reports that the server is unreachable
Check the Office URL for a typo, valid certificate chain, and matching HTTPS scheme. Test the discovery URL from both a browser and the Nextcloud host. If public DNS resolves differently inside the server network, configure a suitable internal route or use the advanced server URL settings supported by your connector.
The page opens, but the document editor hangs
Inspect the reverse-proxy access and error logs for WebSocket upgrade failures. Confirm that the proxy forwards the current Collabora routes and keeps long-lived WebSocket connections open. Browser developer tools can show whether the WebSocket request is rejected, redirected to HTTP, or blocked by a certificate error.
Collabora rejects the Nextcloud host
Compare the actual Nextcloud origin, including scheme, hostname, and port, with the configured alias group. A mismatch between a public URL, an internal hostname, and a proxy rewrite can cause host authorization or WOPI failures. Add only the intended Nextcloud hostname to the allowed configuration.
CODE starts and then exits or becomes unhealthy
Review docker logs collabora, available disk and memory, container permissions, and the runtime requirements for the image tag you deployed. Avoid copying flags such as privileged mode from unrelated examples unless the current official instructions for your environment call for them.
Updates and operational care
Keep the container image updated for security and compatibility, but schedule and test upgrades instead of pulling an unreviewed new image during business hours. Record the version you are using, read relevant release notes, and keep a rollback path. Review proxy configuration after major Collabora or Nextcloud changes because endpoint and WebSocket requirements can evolve. Also monitor the host’s memory, CPU, storage, and container logs as the number of active editors grows.
For the hypothetical team, the installation is ready for limited use only after the discovery endpoint responds, Nextcloud reports a connection, the sample document opens in a browser, and a saved edit remains after reopening. If one of these checks fails, troubleshoot that layer before inviting users to depend on the service.
Official references
Documentation reviewed October 6, 2026. Nextcloud’s stable manual was labeled version 35 when checked; the linked Docker walkthrough is version 28, so use it as an installation example and verify proxy syntax against the Collabora guide and versions you actually run.