Collabora Online logging and audit setup

Collabora Online logging and audit configuration for security teams

A security or compliance team that needs to show who opened or edited a document through a WOPI host needs two things from Collabora Online: a log configuration that records document sessions without recording document content, and a way to join those records to the host's own access logs. The configuration controls how coolwsd writes its logs (level, destination and any audit features the installed branch offers), and that output is what a SIEM can ingest. Collabora Online is built on LibreOffice technology and reaches users only through WOPI calls from a host such as Nextcloud, so the host keeps the record of who requested a file, while Collabora holds the record of the editing session. Neither side answers the audit question alone.

Start by inventorying what each side writes. On the Collabora side, confirm against the documentation for your installed branch which log levels exist, where output goes (files, the system journal or standard output in a container), whether a separate audit or session event stream exists, and which event names it uses. Do not build parsing rules from field names you have seen in a forum post or an older branch. On the host side, confirm which WOPI requests and file identifiers appear in the access log and whether the host logs the user identity. The shared key is the document identifier and the timestamp, so decide early which identifier format your SIEM will index and whether clock sources are synchronized across both servers. Time skew is the most common reason correlation fails.

The second decision is what must stay out of the logs. Debug output at verbose levels can include request details, and an operator who raises the level during an incident may capture more than intended. Set a standing log level for production, restrict who can change it, and test with a sample document containing a known marker string to confirm that the marker never appears in any destination. Plan for the retention and access rules that apply to the SIEM copy of the logs, since those copies become a new store of personal data if identifiers are present. Ask your implementation partner or the Collabora support channel to confirm these behaviors for your version before you rely on them in an audit.

Logging options and when each one fits

This table compares the logging and audit choices an operator makes for Collabora Online, from coolwsd log levels to proxy access logs and WOPI host audit trails. Read each row for what it records, what it can leak, how it affects storage and retention, and who should own it. Feature availability and settings differ by release branch, so confirm each option on the exact version you run before writing it into your standard.

Option	What it records and what it can leak	Storage, retention and ownership
coolwsd log level	Keep normal operations at a low level to record startup, errors and connection events. Higher levels add detail about document sessions and can expose internal request content, so raise them only for a defined investigation.	Volume grows quickly at higher levels. Platform team sets the level and reverts it after the investigation window ends.
Local log file destination	Holds coolwsd output on the host. Access is limited to whoever can read the host, which makes file permissions the main control over leakage.	Needs rotation and size limits configured on the host. Platform team owns rotation, and retention must match the policy agreed with security.
System journal or syslog forwarding	Sends coolwsd output to the host journal or a syslog endpoint. Records may reach other hosts or collectors, so the transport and the receiving system become part of the leak surface.	Central collector stores copies with its own retention. Ownership is shared between platform and SOC teams, and the forwarding path needs its own review.
Reverse proxy access logs	Record request paths, status codes, client addresses and timing for the WOPI and WebSocket endpoints. Document identifiers and query strings may appear in paths, so confirm what the proxy writes.	Typically the largest access volume. Owned by whoever runs the proxy, often the network or web team, with retention set by that team.
coolwsd logs	Record server-side events, errors and session details from the Collabora Online process. They show the Collabora side of a request but not what the WOPI host sent, so they rarely prove who did what.	Platform team owns them. Their usefulness depends on the log level and destination chosen above.
WOPI host audit logs	Record file operations, user identity and access decisions on the host, such as Nextcloud. These are usually the primary evidence for who viewed or edited a document.	Owned by the application team running the WOPI host. Retention and export must be confirmed in that host's own settings.
Audit or event features in the installed release	Some branches may expose audit or event output that the Collabora Online documentation describes for that version. Availability, format and settings depend on the release branch, so confirm them on the version you run.	Confirm retention, storage location and owner against the release documentation and your own configuration before relying on them as evidence.
Document content in logs	Must be kept out of every destination. Verify that no log level, proxy setting or host audit configuration writes document text, and test this with a known sample file.	Owned jointly by security and the platform team. Review after each upgrade, since log formats and levels can change between branches.

Keeping document content out of logs

Document content, cell values, sensitive file names and WOPI access token values should never reach a log file, and the most common way they get there is an operator choosing a verbose setting and forgetting to change it back. Debug-level logging in coolwsd is the first place to check, because it is the level most likely to record request detail that a production operator would never intend to store. Keep production log levels at the lowest setting that still gives your team the events it needs for troubleshooting, and record who changed the level and when. Verbose request dumps at a reverse proxy are the second source. A proxy access log that records full request lines can capture the WOPI query string, which carries the access token and the WOPISrc parameter that identifies the document. Confirm your proxy's log format before go-live, and check the same logs on both the Nextcloud side and the Collabora side.

Several controls reduce that risk, and each one needs verification in your environment rather than an assumption that it works. Mask or drop query strings that carry tokens at the proxy so the access token never lands on disk or in a shipped stream. Restrict read access to log directories and to the log shipping agent so that only the roles that need troubleshooting access can open them. Host platform logs also deserve attention: systemd journal entries, container runtime logs and Kubernetes events can record file paths that include client or project names, so review what the host and orchestrator retain. Set retention on every log store, including any SIEM index, and confirm that deletion actually runs on the schedule you set.

Test the whole chain with a sample document that contains a known, unique string, such as a made-up phrase that appears nowhere else. Open the document in the editor, make an edit that inserts the string, save, then trigger the normal range of actions your users take, including reconnects and a forced error if you can produce one safely. Afterward, search every log location and the SIEM for the string and for a fragment of the access token, and record the result as evidence. Repeat the test after any change to log level, proxy configuration or shipping pipeline, because a single upgrade or added debug flag can reopen a path that was closed.

Collabora Online logging and audit configuration steps

This sequence takes you from an inventory of log sources to a tested pipeline that records document open, edit and close events in your SIEM without capturing document content. Each step ends with a check so you can confirm the output before moving on.

Inventory log sources on both sides
Map every place that records activity for a document session: the WOPI host (for example Nextcloud), the reverse proxy in front of it, the Collabora Online server (coolwsd) and the host or container that runs it. Note where each writes, who can read those files, and how long they are kept. Confirm the exact file locations and service names for your installation in the Collabora Online documentation for your version. Done means you have a written list with one row per source, its owner and its retention period.
Record the installed branch and deployment method
Capture the Collabora Online version, the release branch, the install method (system packages, Docker image or Kubernetes) and the host or container image tag. Log formats and key names can change between branches, so the SIEM parsing rules you write later must match this record. Store it in your configuration management system or change record. Done means anyone on the team can state the exact version running on each Collabora server and point to where that is recorded.
Set coolwsd log level and destination under change control
Edit the coolwsd logging settings in your managed configuration, not directly on the host, so the change is versioned and reversible. Start with a level that records WOPI requests and errors without verbose debugging output, and set a destination the collector can read, such as a file or the system journal. Confirm the configuration key names and accepted values for your version before editing. Restart the service through your normal change process. Done means the change is merged, the service restarts cleanly and the chosen destination receives entries.
Confirm proxy access log format and token handling
Review the access log format on the reverse proxy in front of Collabora Online. Confirm it records the timestamp, client address, method, path, status code and response time, and that it does not write full query strings that carry access tokens. If a field containing a token must be logged for correlation, hash or truncate it at the proxy. Test with a request that includes a token and check the logged line. Done means a sample log line shows the required fields and no usable token value.
Forward logs to a collector
Install or configure a log shipper or syslog forwarder on the Collabora host and on the proxy so both streams reach one collector. Use an encrypted transport where the network requires it, and keep the collector's own logs separate from application logs. Set the shipper to send only the files or journal units identified in step one. Done means events from the Collabora server and the proxy appear on the collector within a few minutes of a test request.
Onboard the collector into the SIEM
Connect the collector to your SIEM. For a Wazuh deployment, the choice is between installing a Wazuh agent on the Linux host that runs Collabora Online and collecting the proxy's logs through syslog, or a combination of both, depending on where the parsing and agent management should sit. Wazuh supports both agent-based monitoring and syslog collection from devices that cannot run an agent. Confirm the current agent and syslog settings in the Wazuh documentation for your release. Done means the SIEM shows recent events tagged with the correct source host.
Build parsing and alert rules
Write decoders that extract the timestamp, source, WOPI host, HTTP status and document identifier from each event type. Then create rules for failed WOPI requests (repeated authorization or status failures from one source) and for unusual access volume compared with a baseline you establish from normal traffic. Tune thresholds during a short observation period, and document each rule with its owner and response step. Done means a deliberately failed test request triggers the failure rule and the volume rule fires on a controlled burst in a test environment.
Test with a sample document and verify content stays out
Using a non-sensitive test document with a unique marker string, open it, edit it and close it through the WOPI host. Confirm that the expected open, edit and close events arrive in the SIEM with the document identifier and user context. Then search the logs, the collector and the SIEM index for the marker string and confirm it does not appear. Repeat the search after any change to log level. Done means the events are present and the marker string returns no results anywhere in the pipeline.

Security risks in Collabora Online logs and audit trails

Logs for Collabora Online are useful for troubleshooting and investigations, but they can expose document content, session identifiers and personal data if they are left at default settings. The cards below pair each risk with a control to set or check before logs leave the server.

Document content in debug logs

Debug and trace output can record request details that include parts of document data or user text while an operator is chasing a fault. Keep the production log level at a lower verbosity, and enable higher levels only for a bounded window with a named owner. Review a sample of log lines after any debug session before the file is shared or retained.

WOPI tokens in proxy logs

A reverse proxy in front of Collabora Online often logs full request URLs, and WOPI request paths carry document identifiers and access tokens. Anyone who can read the proxy logs could replay those values while they remain valid. Configure the proxy to omit query strings from access logs, and confirm that the same rule applies to the Nextcloud side.

Unauthorized reads of host log files

Log files on the host are often readable by any account in an administrative group or by a monitoring agent with broad permissions. Those files can reveal file names, user activity and internal hostnames. Restrict ownership and file modes to the service account and a short list of administrators, and confirm who can read logs in each environment.

Actions that cannot be attributed to users

Collabora Online usually sees a WOPI request and an access token, not a directory identity, so the user who acted is recorded on the WOPI host. If the host does not log the same events, an investigation cannot tie an edit or download to a person. Match timestamps and document identifiers across both systems, and decide which system is the system of record for user actions.

Log loss when containers restart

In a container, logs written to the local filesystem disappear when the container is replaced during an upgrade, crash or rescheduling. Gaps in the record then look like normal operation. Send logs to a collector outside the container as they are written, and test that a restarted pod still produces a continuous stream in the SIEM.

Log volume that fills disks

Verbose logging on a busy editing server can grow quickly, and a full disk can stop the service before anyone is alerted. Set rotation and size limits for every log destination, and alert on free space before it reaches a critical level. Plan the retention period with the security team so that rotation does not remove records needed for an investigation.

How logging differs by deployment method

Docker deployments, whether from the free collabora/code image or a dedicated image you build, send server output to the container's standard streams by default. The first place to look is the container log stream, not a file inside the image. Confirm how the image tag you run handles logging, because defaults and the environment variables that control verbosity can change between releases. Treat the container filesystem as temporary.

Standard output by default: Run docker logs against a running container and confirm that server messages appear. Record the image tag next to the sample so you can match it later.
Persistence: Container logs are removed when the container is removed. Configure the Docker logging driver or forward stdout to a collector before any restart or image update.
Lifecycle: Recreating a container during an upgrade replaces its writable layer, so any log file written inside the container is lost unless it sits on a mounted volume.
Shipping agent: A log shipper on the Docker host that reads the container log output fits well. A syslog logging driver can also send entries directly to a central receiver.
Verbosity: Set log level through the environment or configuration passed at container start, then restart and confirm the change took effect.

Before you change any logging setting, confirm the behavior of the exact image tag in a staging container.

On Kubernetes, the pod is the unit of logging. Container output goes to the node through the container runtime, and a cluster-level collector reads it from there. The official Helm chart README is the reference for chart values, so check the chart version in use before setting any logging option. The same README states that horizontal autoscaling is disabled and replicas are set manually, so plan collection for a known set of pods.

Standard output by default: Run kubectl logs against a pod and confirm server output appears. Check the chart values for any option that writes to files inside the pod.
Pod lifecycle: Logs for a deleted or rescheduled pod go with it. A node-level or cluster-level collector must ship them before the pod is removed.
Multiple replicas: Each replica writes its own stream, so filter by pod and deployment labels when you investigate an event that touches several editing sessions.
Collector choice: A node-level agent such as Fluent Bit, or a syslog forwarder, fits most clusters. Choose the collector the platform team already operates to avoid a second pipeline.
Controller logs: If you use the Collabora Online Controller, confirm where its own logs go and ship them separately from the server pods it manages.

Check the chart version, its logging values and the Controller documentation before you change anything, then restart a test pod to confirm the shipped logs still arrive.

Collabora Online logging and audit configuration questions answered

How much effort does Collabora Online logging and audit configuration take?

The effort depends mainly on how many Collabora hosts feed logs, whether a SIEM already exists, how long logs must be kept, and how much identity context the audit trail needs. A single server writing to local files with a short retention rule is a small task. Several Kit hosts behind a load balancer, a new SIEM, and audit events that must name the user, document and WOPI host involve more parsing, testing and sign-off. Ask for the scope to list each of these factors separately so you can see which ones drive the quote. Effort also grows with the number of Nextcloud or other WOPI host integrations whose logs must be correlated with Collabora's.

Can our team configure Collabora Online logging without a partner?

Yes, a team with Linux administration and SIEM experience can change coolwsd log settings, set destinations and forward files without outside help. The harder part is proving that document content stays out of the logs and that the audit trail answers the questions your security team asks. Teams often underestimate the test work: they need sample documents, a list of expected events, and a review of what each log line contains. If your team has no one who has run a log pipeline before, a partner can take on the design and testing while your staff keep operating it.

What does the client need to provide for a logging engagement?

The work needs access and people more than hardware. Typically you provide:

Administrative access to the Collabora Online hosts and the Nextcloud or other WOPI host servers that call them
An owner for the SIEM who can approve parsers, retention and alert rules
A test document set that covers the formats you use, so logging can be checked against real editing sessions
Change windows for restarting coolwsd and reloading the reverse proxy
A written list of events, fields and retention periods your compliance and security teams require

How long does Collabora Online audit logging take to set up?

Duration depends on scope, so no fixed figure applies. The schedule follows from the number of hosts, the SIEM work needed, the number of test cycles and how quickly your change windows and approvals arrive. Engagements at DeployOpen are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for a timeline that lists each phase, its entry and exit criteria, and the client tasks that could delay it. Be cautious of any timeline quoted before someone has reviewed your host count and SIEM setup.

Do we have to use Wazuh to ship Collabora Online logs to a SIEM?

No. Wazuh is one option, not a requirement. Wazuh is distributed under the GNU General Public License version 2, with an exception that permits linking with the OpenSSL library, so review that license with your legal team. Wazuh documents deployment through an all-in-one or step-by-step install, a prebuilt OVA, an Amazon Machine Image, Docker, Kubernetes, Ansible, Puppet and an offline installation guide. If you already run another SIEM or log platform, the Collabora logs can usually be forwarded there instead. Confirm the parsing and retention features of your chosen platform before deciding.

Do Collabora Online audit logs prove we are compliant?

Audit logs support compliance evidence but do not prove compliance on their own. Independent auditors and certification bodies decide whether controls meet a standard, and DeployOpen does not issue audit reports, attestations or certifications. What DeployOpen can do is configure logging, document what each log records, and prepare the evidence that an assessor will ask to see. Before the work starts, ask your auditor which events, fields and retention periods they expect, and record those requirements in the written scope.

What should we ask for in a logging and audit quote?

A quote should follow from a written scope and show what each line item covers. Ask for:

The list of Collabora and WOPI host systems in scope, and the log sources for each
Which log levels, destinations and audit features are configured, and why
How document content is kept out of logs, and how that will be tested
The SIEM work included, such as parsing, dashboards or alert rules
Retention, access control and backup of the log store
Client tasks, change windows and acceptance criteria
Which costs are one-time and which recur, such as log storage growth and ongoing maintenance

DeployOpen does not publish a price list, so the quote will come from that written scope.

Limits to confirm in your environment

Logging and audit design depends on what your installed Collabora Online branch exposes, how your package or image writes logs, and what your SIEM can ingest. Confirm each limit below against your own environment before you fix the design.

Audit features in your branch

Check whether the Collabora Online branch you run exposes the audit or event features you plan to rely on. Feature availability can differ between branches and packaging methods, so do not assume a setting from documentation for another release applies to yours. Test the setting on a staging server, confirm the exact configuration key in the installed configuration file, and record the output you expect to ship.

Log destinations for your package

Confirm which log destinations your installation method supports before you design the pipeline. A system package, a Docker image and a Kubernetes deployment usually route standard output, log files and syslog differently. Ask whether logs can be written to a file your collector reads, whether the container runtime captures them, and whether rotation is handled for you or must be configured.

Version support window

The 25.04 branch was still receiving point releases in 2026, while 26.04 is the newer branch. Confirm the branch you run, the date of its latest point release, and whether your plan includes signed security updates for it. Logging changes that depend on a specific branch become a maintenance risk if you later upgrade or fall behind on patches.

User identity in WOPI host logs

Collabora Online sees the WOPI request, but it may not see the end user identity in the way your audit trail requires. Confirm that your WOPI host, such as Nextcloud, records the user, file and action for each request, and that the identifiers match across both systems. Without a shared identifier, correlating a document event with a person in the SIEM will be slow or impossible.

SIEM licensing and log volume

Estimate the log volume from a representative test period before you connect a commercial SIEM, because many products price or size ingestion by volume. Confirm the ingestion license, retention tier and indexing cost with the vendor, and check whether your storage can hold the retention your policy requires. Ask whether the quote covers parsing content for the Collabora Online log format.

Wazuh release line and deployment fit

If you plan to use Wazuh, confirm that the release line you deploy matches the plan. The current line in the supplied facts is 4.14, with patch releases throughout 2026. Check the agent and server version compatibility, the offline installation path if your network is restricted, and whether the Wazuh server, indexer and dashboard can be sized for the expected event volume.

How DeployOpen scopes and delivers Collabora Online logging and audit work

DeployOpen plans, configures and documents Collabora Online logging and audit settings inside your own infrastructure, so log levels, destinations and SIEM forwarding are agreed before anything changes. We test that document content stays out of logs and hand over runbooks your operators can maintain.

How we scope

Engagements are fixed-scope, with the logging targets, log levels and SIEM endpoints agreed in writing before work starts.
The written scope lists which coolwsd and reverse proxy logs are covered, and where each one is sent.
Scope records which audit features are in use, and which retention and access rules your compliance team needs.
We ask you to confirm your SIEM platform, its ingestion format and the people who will own alert rules.

How we build

We configure log levels and destinations on a staging Collabora Online server before changing production.
Log shipping to your SIEM is built and tested with sample events, including parsing and field mapping.
We run checks that confirm document names, text and user content do not appear in log output at chosen levels.
Configuration changes are kept in version control so each setting can be reviewed and rolled back.

How we hand over

You receive written documentation of every logging setting, file path, destination and forwarding rule delivered.
Test results show which events were sampled, what was found and how each finding was resolved.
Operator runbooks explain how to change log levels safely, rotate logs and confirm SIEM ingestion is working.
A handover session walks your operators through the configuration, the test evidence and the open items.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, covering logging changes after each Collabora Online update.
Retainers can include periodic checks that log output still excludes document content after upgrades.
Evidence prepared for compliance assessments is provided, though independent auditors issue any audit report or certification.
Ask for a written quote that separates one-time configuration work from any recurring support terms.

Collabora Online logging and audit configuration