How to Disable Telemetry and External Connections in Collabora CODE

Short answer: Collabora Online Development Edition (CODE) does not provide a general telemetry switch that administrators must turn off for routine analytics. Collabora says self-hosted Online does not require telemetry or analytics callbacks. The outbound activity worth controlling is separate: periodic update checks, optional integrations, monitoring endpoints, and document features that fetch remote data. Disable the optional features you do not use, then enforce an egress allowlist while preserving the WOPI connection to your storage server.

This applies to self-hosted CODE, such as an instance integrated with Nextcloud or ownCloud. Fully blocking outbound traffic can break document loading and saving because CODE needs to reach its WOPI host. Configuration names below were checked against Collabora's upstream template on October 6, 2026; packaging and defaults can vary by release.

What counts as telemetry or an external connection?

Telemetry usually means product usage or diagnostic data sent to a vendor. Collabora states its self-hosted Online product does not require telemetry, analytics callbacks, or external service connectivity. The upstream coolwsd.xml template does not show a global telemetry collector or “phone home” switch.

It does show a periodic version check: fetch_update_check defaults to 10 hours. Set it to 0 to turn off that check. allow_update_popup controls whether update notices appear in the editor; setting it to false hides the notification but is not a substitute for disabling the check itself. If your release supports both options, set both.

Other connections are feature-driven. They can include a configured external monitor, remote spelling or grammar services, DeepL translation, AI providers, remote font configuration, and external data requested by a document. The upstream template says remote LanguageTool or Duden APIs are disabled by default; DeepL is disabled by default too. Use the settings shipped with your exact CODE release when reviewing AI or integration options.

Step 1: Identify essential and optional destinations

Map how editing works before changing the network. For example, suppose Nextcloud is at cloud.example.com and CODE is at office.example.com. The browser loads the editor from CODE, while the CODE server also communicates with Nextcloud through WOPI to fetch and save the document. Preserve that server-to-server route, the scheme and port used by your installation, and whatever DNS or proxy services your deployment requires.

Then inventory optional services in your effective configuration. Look under <monitors> for explicitly configured monitoring addresses. Check remote spell-checking, DeepL, AI, remote font configuration, and remote configuration URLs. Remove custom endpoints that are not part of an approved workflow. If one is needed, document its hostname and purpose before creating the corresponding network exception.

Also examine lok_allow. It controls which hosts edited documents may use as external data sources, including URLs used for inserted graphics or spreadsheet functions such as WEBSERVICE(). It is not a universal firewall. The upstream configuration notes that allowed WOPI and POST hosts may also be treated as permitted data sources, so keep this policy distinct from network egress controls.

Step 2: Disable periodic update checks

For the Collabora CODE container, set the options through its extra_params environment variable. Merge them into the existing value; retain any current TLS termination, reverse-proxy, or host settings your installation depends on. Pin a CODE image tag approved for your environment instead of relying on a moving latest tag.

services:
  collabora:
    image: collabora/code:<approved-tag>
    environment:
      extra_params: >-
        --o:fetch_update_check=0
        --o:allow_update_popup=false

This is an illustrative Docker Compose fragment, not a complete deployment. Preserve your existing domain restrictions, admin credentials, TLS settings, and proxy configuration. In Kubernetes, the upstream Helm chart exposes collabora.extra_params and supports custom coolwsd.xml content; use the values file and instructions for the chart version you installed.

If you manage the XML file directly, put the values inside its main <config> element:

<fetch_update_check>0</fetch_update_check>
<allow_update_popup>false</allow_update_popup>

Do not rely on a manual edit inside a running container unless that file is persistent. A restart, image update, or orchestration rollout may replace it. Change the persistent Compose, Helm, or mounted configuration source and recreate or roll out CODE using your normal procedure.

Step 3: Turn off unused integrations and restrict document fetches

Leave <monitors> empty if you do not use an external monitoring service. The upstream file contains a commented sample monitor; a commented entry is an example, not an active connection. Remove active monitor entries that were added locally if they are no longer needed.

Keep remote spelling and grammar checking, DeepL, and AI provider features disabled unless users rely on them. Remote language checking can send selected document text to the configured service, so enabling it has both a connectivity and a data-handling consequence. If an integration is required, allow only its approved endpoint through the egress policy.

For remote content requested by documents, remove public hosts from <lok_allow> and retain only destinations your users need. Do not remove the WOPI route to achieve this. WOPI is the storage connection required for normal editing. Also note that broad private-network entries can permit document fetches to more internal hosts than intended; narrow them where your network layout and CODE release allow.

Step 4: Enforce outbound rules outside CODE

Application settings disable particular behaviors; they do not guarantee that the operating system or process cannot open any other connection. For a stronger boundary, apply outbound rules at the host firewall, container network, Kubernetes NetworkPolicy, or an external firewall. Use deny-by-default for CODE, then allow only the WOPI destination and explicitly approved dependencies. Permit DNS through the network service your platform uses.

In the example above, CODE might be allowed to reach cloud.example.com on the scheme and port configured for WOPI while unrelated public destinations are denied. Avoid relying on a hard-coded IP when the storage host sits behind a load balancer or has changing addresses. A maintained destination group or controlled egress proxy is easier to manage. Ensure any proxy is configured consistently for the container.

Keep inbound and outbound paths separate. The browser must be able to reach the published CODE endpoint, and the storage server may need to reach CODE for discovery or document sessions. An egress policy that permits CODE to call WOPI does not establish those inbound routes. Likewise, changing lok_allow does not disable every type of outbound connection.

Step 5: Restart and verify the policy

Restart or roll out CODE so the effective configuration is loaded. Check startup logs for the loaded configuration values and warnings about ignored settings. Then open an editable test document through the normal storage integration, make a change, save it, close it, and reopen it. The document should retain the change.

• Review firewall, proxy, or network-policy logs during startup and editing. The expected WOPI traffic should be allowed.
• Confirm the external destinations you intended to block are denied. A quiet log alone does not prove every possible route is blocked.
• After the former update-check interval has passed, check whether the CODE container attempted an update lookup. Confirm the update popup is absent if that was also disabled.
• Test any features users need, including remote fonts, translation, language aids, document links, and formulas that retrieve external data. Restore only the specific approved destination that a required feature needs.

If documents fail to open or save, check DNS and the server-to-server WOPI route first. If only an external image or spreadsheet formula fails, review lok_allow separately from the firewall policy. Blocking a public data source while WOPI continues to work is the intended result; blocking saves means the egress policy is too broad.

What disabling these connections can and cannot guarantee

Turning off the update check and unused integrations reduces the expected outbound activity from CODE. A deny-by-default network policy provides the enforcement boundary. Neither one governs separate traffic from your host, container runtime, orchestration platform, reverse proxy, or monitoring agent. If the requirement covers the whole server, audit those components too.

Configuration defaults can change between releases, and integrations may add settings. Compare the template shipped with your pinned image against the current upstream template before rollout, and test in staging. The primary references are Collabora's upstream coolwsd.xml configuration template, its official Helm chart values, and its statement on self-hosted deployments and external services.