Collabora Online admin console: users, documents and access

What the Collabora Online admin console shows and who needs it

The Collabora Online admin console lists every connected user, every open document, the resource use of each document, and graphs of recent resource usage over time. It can also feed live information to external monitoring, so the same figures can appear in the dashboards your team already watches. Operators who run Collabora Online for Nextcloud or another WOPI host need this view when they have to answer practical questions quickly: how many sessions are active right now, which documents are consuming the most resources, and whether a slow editing session is caused by a busy server or by one heavy file.

Teams usually reach for the console in three situations. The first is a capacity check before a busy period, such as a planned rollout of document editing to a new department, when the administrator wants to see peak concurrency and the trend leading up to it. The second is troubleshooting, when users report sluggish typing or dropped sessions and the operator needs to confirm whether the load was high at that moment. The third is investigating a specific document, where the per-document figures show whether one large spreadsheet or presentation is absorbing most of a server's capacity. Confirm with your Collabora Online version how far back the history graphs reach in your environment, since that determines whether you can review an incident after the fact.

The console is an operator view of one Collabora Online server. It does not replace infrastructure monitoring of CPU, memory, disk, network and certificate expiry on the host, nor the logs of your reverse proxy and WOPI host. Decide before go-live which system is the source of record for alerts, and make sure the figures you feed to external monitoring are reviewed by the people on call. Because the console exposes which users are editing which documents, plan who may open it and how that access is granted, and treat that access as a control in its own right.

Which views the console gives an operator

The admin console gives operators four views that answer different questions: who is connected, what is open, how much each document costs in resources, and how usage changes over time. Read them together, and confirm the layout and metric names on the Collabora Online version you run, since the console changes between releases.

Connected users

This view lists every user currently connected to the server. Operators use it to answer who is active right now and whether a load problem is tied to a spike in sessions. Before drawing conclusions, remember that a connection is not the same as an active editing session, and that several connections can come from one integration host or proxy address. Check the source of connections against your reverse proxy and WOPI host configuration before blaming the server for load.

Open documents

This view lists the documents currently open on the server. It answers which files are in use and how many people share each one. Because all users editing one document must reach the same server process, a document with many sessions is a sizing and routing signal, not only a usage count. Check whether the same document appears more than once, and whether documents stay open after users leave, since idle sessions can hold memory until they close.

Per-document resource use

For each open document, the console shows the resources that document consumes. Use it to find the few large or heavy documents that drive memory and CPU use, rather than tuning the whole server for them. Compare figures against the per-pod limits in your deployment, and confirm which metrics are reported on your version, such as memory, CPU or process details. Treat a single snapshot with caution and look at trends before changing capacity.

History graphs

The history graphs show recent resource usage over time, so operators can see whether a problem is steady, periodic or a one-off spike. They answer whether the server was under pressure at a given time, which matters when users report slow editing. Confirm the time range the console keeps before you rely on it for an incident review, and export or record values elsewhere if you need longer history for capacity planning or audit.

Live feed to external monitoring

The console can feed live information to external monitoring, so the same figures appear in the tools your operations team already uses. This answers whether alerting and dashboards match what administrators see in the console. Before relying on it, confirm which values are exposed, how the feed is enabled and secured, and how it behaves when the server restarts. Keep the monitoring system's own retention and access controls in your plan, since the feed moves operational data out of the console.

How the console fits into a Collabora Online deployment

The admin console sits on the Collabora server itself, so it shows only what that server is handling. In a single-server setup, the WOPI host (Nextcloud, for example) sends users to one Collabora Online instance, and the console lists every connected user and open document there. The WOPI host keeps its own record of who may open a file and which group may edit, as described in the Nextcloud administration manual. The console does not manage those permissions. It reports what the Collabora process is doing at that moment, so a user who appears in the console is a session that reached the server, not a confirmation that the WOPI host approved the access. Your load balancer or reverse proxy sits between the two and decides which server each request reaches, which is why its configuration matters when you read the console.

Once you run more than one server, or Kubernetes pods, the picture changes. Load balancers must route by the WOPISrc parameter so that everyone editing one document lands on the same pod, and the official Helm chart documents this requirement. Each pod therefore has its own console with its own list of open documents and its own resource graphs. A view taken from one pod shows only the documents pinned to that pod. Before you rely on the console for capacity or troubleshooting, confirm your ingress routes by WOPISrc and record which pod or server holds each document. Then read per-document usage and history graphs from every server or pod, and aggregate them in your monitoring system. Ask your deployment team how the external monitoring feed is configured for each instance.

How console access differs across deployment models

On a single server running the built-in CODE app, the admin console is served by the same Collabora Online instance that handles editing sessions, so there is one console to open and one set of connections to look at. This is the simplest model to inspect, and it suits evaluation, home use or a small team. Collabora describes CODE as not recommended for production, so treat this model as a test layout and confirm the console path and login behavior against the version you install.

Where it is reached: Confirm the console URL and administrator sign-in for your CODE version in the Collabora documentation before you share it with anyone.
What it covers: A single instance, so connected users and open documents shown are those on that server.
Resource history: Check whether the graphs of recent resource use appear in your build, since the console behavior should be verified on the installed version.
Access: Limit who can reach the console address, because the CODE app is often exposed on a test network with default settings.
Upgrades: CODE is a rolling release, so re-check the console location after each update.

Before relying on this layout, confirm the console location, the sign-in method and the access restrictions on the exact build you are running.

Console access and feed options and when each fits

This table compares three ways to expose the Collabora Online admin console and its live data: restricting it to an administrative network, publishing it only through an internal reverse proxy, and forwarding live information to an external monitoring system. Read each row for the situation it suits, the exposure it reduces, and the operational cost it adds. The main takeaway is that the console shows sensitive session data, so access control should be settled before the console is reachable from anywhere.

Option	When it fits	What it protects against	Trade-off
Administrative network only	Small or single-server deployments where administrators already work from a fixed management network or VPN	Casual or external discovery of the console and the list of users and open documents	Administrators need VPN or jump host access, and remote troubleshooting takes longer
Internal reverse proxy access	Organizations with an internal proxy that already handles authentication for administrative tools	Direct access to the console port, and unauthenticated requests reaching the admin pages	Proxy rules must be kept in step with the Collabora version, and misrouted paths can expose or break the console
Live feed to external monitoring	Teams that already run a monitoring platform and want resource trends alongside other services	Reliance on manual console checks during incidents, and gaps in history when no one is watching	The monitoring system becomes another component to secure, patch and back up, and the feed must be kept off public networks
Console and feed combined	Regulated environments that need documented access control plus retained operational history	Unauthorized viewing of session data and loss of evidence about resource use during an event	Highest setup and review effort, with separate access rules for the console and the monitoring stack
Console disabled or unexposed	Deployments where administrators manage the server only through configuration files and logs	The largest exposure surface, since no admin page is reachable at all	Less visibility into connected users and per-document resource use during problems

How to turn on and check the admin console

This sequence confirms the installed version, exposes the admin console only on the interface you intend, locks it down, and then proves with real usage data that it shows what you need before anyone relies on it for monitoring.

Confirm the installed Collabora Online version
The administrator checks which Collabora Online release is running on each server before doing anything else, because the console and its feature set depend on the version. Compare the reported version with the branch you intend to support, and confirm it is a release still receiving point updates, such as the 25.04 or 26.04 branches described in the release notes. Record the version in your change ticket. Done when every server in the deployment reports the same version and you have written it down.
Reach the console on the intended interface only
Open the admin console from the network location you plan to use for administration, typically a management subnet or a jump host, and confirm it loads. Then test from a user network and from outside your perimeter, where it should not respond. The console is served by the Collabora Online server itself, so the check is whether the listening address and any reverse proxy rules match your design. Done when the console loads from the admin path and fails from every path that should be blocked.
Restrict access before exposing the console
Before the console is reachable beyond the server, put it behind controls your organization already uses, such as an allow list of administrator addresses at the reverse proxy, a separate admin hostname, and authentication at the proxy layer. Confirm the admin credentials are unique and stored in your secrets process. Ask your vendor or your own configuration documentation which admin credential settings apply to your installation method, since these differ between packages, Docker and Kubernetes. Done when an unauthenticated request from a non-admin address is refused and an authorized administrator can still log in.
Open a test document and confirm it appears
Have a test user open a non-sensitive document from the host platform, such as a Nextcloud test file, and keep it open while an administrator watches the console. The document and the connected user should appear in the open documents and connected users views, with resource figures attached. Close the document and confirm it leaves the list. Done when you can match the test session to a document and a user in the console, which proves the WOPI path and the console are working together.
Review history graphs over normal use
Leave the server in normal use for a representative period, then open the history graphs and read CPU, memory and session activity across it. Look for peaks that line up with known working hours, batch jobs or large document sessions, and note the baseline you see. Compare the observed peaks with the per-pod limits in your sizing plan so you know whether your current capacity has headroom. Done when you have a written baseline with the peak periods identified and reviewed by the person who owns capacity.
Connect the live feed to monitoring
If your operations team uses external monitoring, configure the console's live information feed to reach it, then confirm the metrics arrive in your dashboard with timestamps that match the console. Set an alert on a fault you can reproduce safely, such as a stopped test session or an unreachable server, and confirm the alert fires and clears. Check who receives the alert and that the feed endpoint is itself access controlled. Done when a deliberate test event appears in the monitoring system and the alert routes to the right team.

Protecting the admin console from unauthorized use

Treat the Collabora Online admin console as a sensitive system from the first day, because it shows who is connected, which documents are open and how much each one consumes. Document names and user activity can reveal business plans, personnel matters or deal timing even when no document content is visible. The first decision is therefore network placement: the console should be reachable only from the administrator network, a jump host or a VPN segment, and never from the open internet. Confirm with your own network team which addresses and paths will reach the console, and test that a request from an end-user network is refused before you go live.

Keep the console off the same public path that serves end-user editing. The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers and using HTTPS for the Collabora server URL, with the same protocol as the Nextcloud installation. Apply the same discipline to administrative access: give the console its own hostname or internal route, terminate TLS on it, and do not expose it through the reverse proxy rule that handles editing sessions. Use separate administrative credentials that are not shared with the integrating platform's accounts, rotate them on staff changes, and record who holds them. Confirm in the release notes for your version whether the console has its own authentication options and how they are configured, rather than assuming the defaults are sufficient.

Log administrative access at the reverse proxy and in your central logging system, capturing source address, time, account and requested path for every request to the console. Review those logs on a schedule and alert on access from unexpected networks. Also decide who may read the live feed that the console can expose to external monitoring, since that feed carries the same user and document information. Plan these controls as part of the deployment design, document them in your runbook, and ask any partner to include them in the written scope so that they are verified during acceptance testing.

Security and operational risks of console access

The admin console shows who is editing what and how hard the server is working, which makes it useful and sensitive at the same time. The cards below cover the risks that follow from that: exposure of data, network reach, misleading per-replica views, noisy alerting and running an unsupported release.

Exposure of document names and users

The console lists connected users and the documents they have open, so the names of files and the identities of the people editing them can leak to anyone who reads the page. Treat that list as personal and confidential data. Restrict console access to a named administrator group, and confirm with your data protection lead whether the console view falls under your records of processing. Review who holds the admin credential at least once each quarter and remove access that is no longer needed.

Console reachable from untrusted networks

If the console address is published through the same reverse proxy as the editing traffic, anyone who can reach the editing service can also try to reach the console. Publish the console only on an internal management interface or behind a VPN or allow list, and keep it on a separate hostname from the public WOPI endpoint. Confirm the exact path and access rules in the Collabora Online documentation for your version before you change the proxy configuration.

Stale data from per-replica views

Each Collabora Online server reports only the users and documents it holds, so a view taken from one replica can miss activity on another. For an illustrative two-replica setup, a count read from one console may show fewer open documents than the cluster actually has. Before you act on a number, check every replica or read the combined monitoring feed, and record which replica the figure came from in your incident notes.

Alert fatigue from raw graphs

Resource graphs change constantly, and a chart that is read only by eye produces either missed spikes or constant false alarms. Set thresholds on sustained CPU and memory use over a time window instead of single samples, and route the alerts through the monitoring system your operations team already watches. Agree with your operators which graph values trigger a page and which only appear in a daily review.

Running an unsupported release

Security fixes reach Collabora Online through point releases on supported branches, so an old version can miss a patch that a newer one already contains. The 25.04 branch shows the pattern: 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623, and the branch continued to receive point releases with 25.04.13 released on September 21, 2026. Record the running version in your change calendar, subscribe to the release notes, and apply security point releases on a fixed schedule.

Questions teams ask before setting up the admin console

Is the Collabora Online admin console enough for production monitoring?

On its own, usually not. The console shows connected users, open documents, per-document resource use and graphs of recent resource usage, which is useful for watching a live server and investigating a spike. It keeps only recent history in view, so it does not replace long-term retention, alerting or capacity reporting. The Collabora FAQ notes that the console can feed live information to external monitoring, so the production question is which monitoring system you will connect and who receives the alerts. Confirm the retention window and export options against the version you run, since these details change between releases.

How much effort does a basic admin console setup take?

The console is part of the Collabora Online server, so there is no separate product to license or install. The effort lies in protecting it, confirming it is reachable by the right staff, and wiring it to monitoring. Effort rises with the number of Collabora servers, the number of teams that need read access, and whether you must integrate with an existing alerting pipeline. Ask any partner for a written scope that lists the servers, the monitoring target, the access model and the handover documents, because those items set the duration far more than the console itself.

Can our team set up the admin console without outside help?

Many teams can, provided they already run Linux servers, reverse proxies and monitoring. The steps are to decide who may open the console, restrict that path at the proxy, confirm the admin credentials are stored securely, and point your monitoring at the data you need. Teams without these skills, or teams running several servers behind a load balancer, often gain more from a short fixed-scope engagement. Outside help is also useful for an independent review of the access controls before an audit. Either way, write down who owns the console after go-live.

What does the admin console setup require from our environment?

Plan for three things before the work starts:

Network access: a path from administrator workstations to the console, restricted to an admin network or VPN, and a route from the monitoring system to the server.
Monitoring tools: an existing system that can receive the live information, along with an owner for dashboards and alert thresholds.
A staging environment: a non-production Collabora Online server where you can test access rules, proxy configuration and upgrades before they reach production.

Also confirm how the console is reached through your reverse proxy and whether your Nextcloud or other WOPI host restricts requests to known Collabora addresses.

Does the free CODE edition include the admin console?

CODE is the free edition of Collabora Online. Collabora describes it as suited to testing, home use or small teams, and not recommended for production. Because the console belongs to the Collabora Online server, you should check the CODE page to confirm which features the edition includes before you rely on it. The Business plan, listed at 3 euros per user per month for up to 99 users, adds long term support, a service level agreement, signed security updates and customer portal access, according to the Collabora pricing page. The Enterprise plan for 100 or more users is quoted with volume discounts and adds integration support, customization services and roadmap input. Ask Collabora which of these terms apply to your deployment.

How should we handle access requests from auditors?

Treat auditor access as a named, time-limited role that is granted through your identity system and removed after the review. Give auditors read-only views where your setup allows it, and log who opened the console and when. Avoid sharing administrator credentials or a single generic account. The console shows operational state, not a full audit trail, so pair it with your proxy and access logs. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification. Agree the evidence list with your auditor before the review opens.

How do we restrict who can open the admin console?

Restrict the console path at your reverse proxy so that only an administrative network or VPN reaches it, and require strong authentication for each administrator. Keep the console off public routes, avoid exposing it on the same hostname as user-facing editing, and rotate the admin credentials on a schedule your policy sets. Review the list of administrators at each change of staff. Test the restriction from outside your network after every proxy change, because a rule that works on the internal address may still leave a public path open.

What drives the ongoing cost of running the console?

Setup is largely one-time, but operation recurs. The main ongoing items are staff time to review the console and alerts, monitoring storage and retention, and the work to keep Collabora Online current with its point releases and security advisories. Support terms also recur if you buy a subscription. Costs rise with the number of servers, the length of history you keep, and the number of users billed under a per-user plan. Ask any partner to split the quote into one-time setup, a recurring retainer for support or testing, and any pass-through licensing.

What to confirm with Collabora before relying on the console

Before you build monitoring, reporting or access decisions on the admin console, confirm its behavior on the exact Collabora Online release you run. The console's reach is documented in the Collabora FAQ, which states that it shows all connected users, open documents, their resource usage and graphs of recent resource usage, and that it can feed live information to external monitoring. Read that answer alongside the product documentation and the Collabora FAQs for your release line, because release notes can change what is shown and how. Record the release number, the date you checked and the source of each statement in your runbook, so an auditor or colleague can see what you based the design on.

Test the two behaviors you are most likely to depend on in staging before production. For history graphs, find out how far back the console keeps data, whether the window survives a restart of the server, and whether the graphs reflect every process that serves documents in a multi-server setup. For the external feed, list every field your monitoring stack will read, confirm each field name and unit on your release, and check that values are returned for a document that has been open for a long time. Run a short, controlled test with a known number of test users and documents so you can compare what the console reports with what you expect. Label these tests in your own records as staging evidence, not as vendor assurance.

How DeployOpen scopes and supports admin console access

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and that includes how administrators reach the Collabora Online admin console. We agree the scope in writing before work starts, then build access controls, monitoring hooks and runbooks that your team can operate after handover.

How we scope

Written scope lists which administrator groups need console access and which network paths they will use.
We confirm whether live console data will feed your existing external monitoring tools.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.

How we build

We restrict console access to a dedicated admin path and keep it off public routes.
We test that the console shows the users, open documents and resource graphs your operators expect.
We verify that monitoring integrations carry the data your team needs without exposing document content.

How we hand over

Runbooks explain who may open the console, how sessions are approved and how access is reviewed.
Handover documents record the access design, network rules and monitoring configuration as built.
Your administrators walk through the console and the runbooks before the engagement closes.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
Retainer work can re-check console access rules after Collabora Online upgrades or infrastructure changes.
Ask your DeployOpen contact to confirm which console data your monitoring stack depends on before any change.

Collabora Online admin console