How Collabora Online editing reaches Moodle courses
A teacher or platform owner who wants students to edit documents inside a Moodle course, without leaving the browser, needs to understand one structural point first: Collabora Online is the editor, Moodle is the host, and the link between them is a WOPI connection made by a Collabora plugin for Moodle, not a feature built into Moodle core. Moodle stores the file and decides who may open it. Collabora Online receives the request over the WOPI protocol, renders the document, and returns the edits to Moodle. Because the connection depends on a third-party plugin, the design work starts with that plugin, not with the Moodle course settings.
Before any build work, confirm the exact plugin name, version and compatibility against Collabora's integration documentation and the Moodle version you run. The Moodle release line in use changes the answer: Moodle 5.1 and 5.3 set different PHP and database minimums, and the plugin must support the version you plan to keep for the life of the course. Also confirm which Collabora Online release line the plugin is tested against, since the server and the host integration must be matched. Collabora Online server code is licensed under the Mozilla Public License 2.0 (MPL-2.0), so the editor itself carries no per-seat licence fee for the software, but the Collabora plugin, its support terms and any subscription are separate items to confirm in writing.
Plan the WOPI path before the plugin is installed. The Moodle site must reach the Collabora server, and the browser of each student must reach the same Collabora server directly over HTTPS, so the URLs in both directions, the certificates they present and any reverse proxy in between need to be settled first. Record which Moodle roles can add editor activities and which can edit, and confirm with the plugin documentation how those permissions map onto Moodle's own course and activity roles. A teacher who can open a document in the browser but cannot save it will raise a support ticket on the first lesson, so test the full round trip with a student account before the course opens.
What a Moodle site and Collabora server need before setup
The Moodle site, the Collabora Online server and the plugin all have to agree before a teacher can add an editor activity. Check these four items first, because a mismatch on any one of them usually shows up as a blank editor or a failed document load in front of students.
Moodle release, PHP and database
Pick the Moodle release first, then match PHP and the database to it. Moodle 5.1 requires 64-bit PHP 8.2 or later, and the web server document root must point to the new /public directory rather than the main Moodle folder, or the site may show directory listings or errors. Moodle 5.3 requires 64-bit PHP 8.3 or later and PostgreSQL 17. Confirm the exact requirements in the release notes for the version you plan to run.
Support window for the chosen release
Moodle release support windows differ between major versions, with some receiving general support and others only security support for a set period. Check the Moodle releases page at the time of planning, not when this page was written, and choose a release whose security support will still cover the planned go-live and the first year of operation. Schedule any Moodle upgrade so the Collabora plugin is tested against it first.
Collabora server reachable over HTTPS
The Moodle server must reach the Collabora Online server, and students' browsers must reach it too, both over HTTPS. Confirm DNS names, certificate chains and firewall rules from the Moodle host, from a campus network and from a home connection. The Nextcloud guidance on matching the protocol of the editor URL to the host application applies here as well, so avoid mixing HTTP and HTTPS between the two systems.
Production edition, not CODE
The free CODE edition is a rolling release that Collabora describes as suited to testing, home use or small teams, and not recommended for production. A class-wide deployment that students depend on should run a supported Collabora Online release from a planned version line. Ask Collabora or your partner which edition, support terms and patch cadence apply to your school or campus before you choose.
Matching plugin version on both sides
The Collabora Online plugin for Moodle has to match the Moodle release it runs on and the Collabora server version it talks to. Record the plugin version, the Moodle version and the Collabora version in your change log before you deploy. Re-test the editor after any Moodle point release or Collabora update, since a change on either side can break the handshake without a visible error.
How to connect Moodle to Collabora in the right order
This sequence takes a Moodle site from a plugin install to a tested editor activity in which teachers and students open the same document with the access each role should have. Each step ends with a check so you know it is complete before the next one starts.
Confirm the Moodle version and web root
Before installing anything, the Moodle administrator records the exact Moodle version, the PHP and database versions it requires, and the web server document root. From Moodle 5.1, the document root must point to the new public directory rather than the main Moodle folder, or the site may show directory listings or errors. Confirm the Collabora Online server version you plan to run supports your Moodle release. The check: the site loads normally over HTTPS from a browser, and the version and document root are written into the change record.
Install the Collabora plugin through Moodle
A Moodle administrator installs the Collabora plugin through Moodle's plugin mechanism, following the plugin's own installation guide for your Moodle release. Moodle's plugin types documentation explains how each plugin type is placed and upgraded, which helps when you review the install. Complete the database upgrade that Moodle prompts for, and do not enable editor features yet. The check: the plugin appears in the list of installed plugins with its version, and the upgrade screen reports no pending actions.
Point the plugin at the Collabora server over HTTPS
In the plugin settings, enter the address of the Collabora Online server, using HTTPS and a certificate that Moodle's server and every user's browser trust. Confirm the exact setting name and whether the field expects a base URL or a discovery address in the plugin documentation for your version. Test the address from the Moodle server itself, not only from your workstation, because outbound routing and internal DNS often differ. The check: Moodle's server can fetch the Collabora discovery document over HTTPS, and the plugin's connection test reports success.
Restrict WOPI requests to the Moodle servers
Limit which hosts may send WOPI requests to the Collabora server so that only your Moodle web servers can reach it. Collect the outbound addresses of every Moodle node, including any NAT gateway or reverse proxy, because these are the addresses Collabora will see. Record the allow list in your configuration management so that a server change does not silently break editing. The check: a request from a Moodle node succeeds, and a request from a test host outside the allow list is refused by the Collabora server.
Enable the editor for the course and activity types
Turn on the Collabora editor only for the courses and activity types that need it, which is usually a short list agreed with academic and IT leads. Check the plugin settings for the activity types it supports and for any course-level or category-level switches. Leave the setting off for course types that hold sensitive records until a review has approved them. Confirm this with the plugin documentation for your release, because option names differ between versions. The check: in a sandbox course, a teacher can add an editor activity of the intended type, and an unsupported activity type does not offer it.
Set teacher and student capabilities
Set which roles can edit and which can only view documents. Map the plugin's capabilities to Moodle's role system, and review the default permissions for the teacher, non-editing teacher and student roles. Decide whether students should edit shared documents, edit only their own copies, or view only, and record that decision with the teaching team. Use Moodle's permission overrides for individual courses only where needed, so the rules stay easy to audit. The check: the permission review table for each role matches the written decision, with no role gaining edit rights by default.
Test with teacher and student accounts in a sandbox course
Create a sandbox course with one teacher account and one student account, add a test document, and open it as each user. The teacher should open the document in edit mode, and the student should open it in the mode the capability review set. Save a change as each user, reload the page, and confirm the change persists. Then have both users open the same document at the same time to confirm co-editing works across your server setup. The check: both users reach the expected mode, changes persist, and a student without rights cannot open the document in edit mode.
How Moodle roles and course permissions map to edit rights
This table lists the standard Moodle roles and the Collabora editor rights each one should receive: open, view, edit and create. Use it as a hypothesis to test, since the plugin's actual mapping must be confirmed in its own documentation and in a test course before any teacher or student relies on it.
| Moodle role | Expected editor access (to confirm) | Edit and create rights (to confirm) | What to verify in a test course |
|---|---|---|---|
| Site administrator | Open and view for any activity the administrator can reach | Edit and create expected, but confirm whether site-level roles bypass course settings | Log in as an administrator in a course where they are not enrolled and check the editor opens and what mode it uses |
| Course creator | Open and view for courses they create or are enrolled in | Create expected in their own courses only; confirm they cannot edit files in other courses | Create a course as a course creator, add an editor activity, and confirm no access to a second course's documents |
| Teacher (editing teacher) | Open, view and edit for editor activities in their courses | Edit and create expected; confirm whether they can add or replace the underlying file | Open an activity in edit mode, save a change, and confirm the change appears for a student in the same activity |
| Non-editing teacher | Open and view expected; confirm whether they can open in edit mode at all | Edit expected to be off by default; confirm the plugin does not grant edit through a generic teacher capability | Attempt an edit as a non-editing teacher and record whether the editor opens read-only or blocks the session |
| Student | Open and view for activities they are enrolled in, as set by the teacher | Edit only where the activity is set to allow it; confirm create rights are not granted | Open the same document as a student in edit and view modes, confirm save behavior, and confirm no access to other courses |
| Guest or unenrolled user | No access expected; confirm the WOPI access token does not grant rights outside enrolment | No edit or create expected | Share an activity link with an unenrolled account and confirm the editor refuses to open the document |
| Group-restricted access | Expected to follow group membership if the plugin honors Moodle group settings | Edit by group to be confirmed against the plugin's documentation | Create two groups, restrict an activity to one, and confirm the other group cannot open or edit the file |
| Plugin mapping source | Nextcloud limits which groups may use the editor and which may edit, a useful reference for questions to the plugin vendor | Ask the vendor whether Moodle capabilities, not only roles, control open, view, edit and create | Record the vendor's written mapping and compare it with the test course results before rollout |
Sizing the Collabora server for a class-wide session
A single small group working on one document is the lightest case for the Collabora server. Concurrency in Collabora Online is counted per document and per active user, so a handful of students editing one file creates one document session with a few connections. A small group usually sits comfortably within one pod, but the only way to know is to test with the document types your course uses. Treat the Helm chart's production figures as a starting point to validate rather than a sizing answer: the README recommends limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB.
- Concurrency unit: count active documents and active users per document, not enrolled students.
- Document weight: large spreadsheets and image-heavy presentations cost more memory than short text documents.
- Replica count: start with one pod and set replicas manually; do not rely on autoscaling.
- Routing: confirm the load balancer routes by the WOPISrc parameter so every editor of a file reaches the same pod.
- Test case: run a timed session with a realistic group and watch CPU and memory on the pod.
Before approving a small deployment, check that the ingress you plan to use (Nginx, HAProxy or OpenShift Router) keeps WOPISrc routing intact.
A whole class co-editing one shared document is the pattern that drives peak load on a single pod. Every student who opens the file adds an active user to the same document session, so the load concentrates in one place. Collabora's Helm documentation is explicit that horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste, so you cannot rely on the platform to add capacity mid-lesson. Plan the class size and the number of simultaneous documents in advance, then test that pod at the expected number of editors.
- Peak editors per document: test with the largest class you expect to co-edit one file at once.
- Pod headroom: watch memory as well as CPU, since the 8000 MiB limit is the number to validate against.
- Fixed replicas: scale up before the session by changing the replica count yourself, and scale down afterwards.
- Document isolation: place one class document on one pod through WOPISrc routing so editing stays consistent.
- Network path: confirm latency from student networks to the Collabora server, since many students on one document amplify delays.
Ask your Moodle administrator to schedule a rehearsal with a full class roster before the first graded activity.
Across a term, many classes edit many documents at different times, so the question shifts from peak editors on one file to total active documents across the server. Load is spread across pods by document, which means the number of pods you run matters more than the size of any one of them. Because replicas are set manually, a term-long plan has to pick a steady replica count for normal weeks and a higher count for assessment periods. Collabora's own guidance on scaling and the COOL Controller for large deployments is the next read when term-wide concurrency grows beyond a few pods.
- Timetable mapping: list which classes share assessment deadlines, since those create the overlapping peaks.
- Replica schedule: agree a baseline count and an exam-period count, and who changes them.
- Pod spread: confirm that new documents land across pods through WOPISrc routing rather than concentrating on one.
- Monitoring: track active sessions and resource use per pod over the first weeks of term.
- Upgrade windows: schedule Collabora updates outside busy assessment weeks.
Before the term starts, ask for a written capacity test that covers the busiest week in your calendar, not an average week.
Securing student document editing in Moodle
Student documents pass through three systems: Moodle, the Collabora Online server and the browser connection between them. The controls below cover transport, network trust, patching, roles, retention and audit, and each card names a check you can run before students use the editor.
HTTPS for both URLs
Serve Moodle and the Collabora Online server over HTTPS, and use the same protocol for both, as the Nextcloud administration manual recommends for its own WOPI setup. Check that the Collabora discovery URL and the WOPI host configured in Moodle both start with https, and that the certificate chain is valid from a student device on the campus network and from home. Mixed content or a plain HTTP discovery URL will break editing or expose document traffic.
Allow list for WOPI requests
Restrict the Collabora server so that only the Moodle host can send WOPI requests, and restrict Moodle's WOPI endpoint to the Collabora server addresses where your network allows it. Ask your Collabora contact which allow list settings apply to your release, then test from an address that is not on the list and confirm the request is refused. Review the list whenever the Moodle or Collabora hosts change IP addresses or move behind a new load balancer.
Patching against advisories
Subscribe to Collabora's release notes and security advisories, and schedule point releases for the branch you run, since advisories name the fixed build. Install packages from Collabora's signed repositories and confirm the package signing keys are current, because the 25.04 release notes record a key update for RPM and DEB users. Keep a record of the version running on each Collabora node and the date it was patched.
Least-privilege course roles
Moodle decides who can open an editor activity, so review the role each user holds in the course before a session. Give students the capability to edit only in activities designed for collaboration, keep view-only access for reference material, and check that teachers and non-editing staff cannot change activity settings they do not own. Test with a student account in a sandbox course and confirm the editor opens in read-only mode where you expect it to.
Retention and deletion settings
Decide how long student-edited files stay in Moodle after a course ends, and who deletes them. Moodle keeps uploaded and created files in course and user file storage until someone removes them, so set a written retention rule, configure the course backup and deletion steps, and check that backups do not keep copies beyond the rule. Confirm with your privacy office which regulation applies to your students, since that sets the required timeframe.
Logs of opens and edits
Record who opened or changed which file, because FERPA requires institutions to keep a record of disclosures from education records and that record must match the editing activity. Enable Moodle's standard logs for the editor activity, forward Collabora server and reverse proxy access logs to your log store, and correlate them by document ID and time. Run a test session with two students and one teacher, then confirm each open and save appears in both logs.
Why FERPA and COPPA shape the editor rollout
For US institutions that receive funds under a program administered by the US Secretary of Education, FERPA governs student education records, and that includes any document a student uploads, submits or receives through a course. The Collabora Online editor does not change that status. Once a teacher or student opens a file in a Moodle activity, the file's contents and its edit history may be education records. Before enabling editor activities, confirm with your counsel which parts of your Moodle site fall under FERPA, and whether the Collabora server, which receives document content through WOPI, counts as a service you would otherwise staff with your own employees. If you do use an outside party to run or maintain the server, the regulations allow it to act as a school official only while it stays under your direct control for the use and maintenance of those records and follows the redisclosure limits in 34 CFR 99.33(a). Write those controls into the contract and the administration runbook.
FERPA also expects access controls and an access record. Institutions must use reasonable methods to ensure school officials see only the records in which they have a legitimate educational interest, and must record each disclosure of personally identifiable information with the parties involved and their interests. In a Moodle rollout, the practical checks are which roles can add editor activities, which course groups can edit rather than only view, and whether your logs can show who opened a document through the editor. Those decisions sit on the Moodle and Collabora sides together, so review them in one session. Where students are under 13, the COPPA Rule (16 CFR Part 312) applies to operators that collect their personal information. Its amended text requires a written information security program with a designated coordinator, at least annual risk assessments, and a written retention policy with a deletion timeframe. Ask the Collabora operator and any hosting partner for their retention and deletion settings in writing.
If your institution is in the EU, GDPR and NIS2 may apply instead of, or alongside, the US rules, depending on your status and the data involved. This page does not give legal advice. Its purpose is to name the questions to put to counsel before the first class session: who is the controller and who is the processor, where document content is stored and logged, how long the Collabora server keeps temporary files, and who is responsible for incident notification. Counsel's answers determine the access model, retention settings and contract terms, so settle them before the sizing and routing work begins.
Common failures when Moodle cannot open or save a document
This table lists the failures most often seen when Moodle cannot open or save a Collabora document, with the likely cause and the first fix to try for each. Read it as a triage list: match the symptom, check the named cause, then confirm exact error text against the plugin and Collabora documentation before changing settings. Several failures trace back to URL, protocol or routing settings that must agree across Moodle, the plugin and the Collabora server.
| Symptom | Likely cause | First fix to try |
|---|---|---|
| Document opens blank or shows a connection error | The Collabora server URL in the plugin does not match the address the browser reaches, or the Moodle site and Collabora server use different protocols | Confirm the Collabora URL and discovery settings, use HTTPS on both sides, and check that the browser can reach the Collabora host directly |
| Editor refuses to load the document from Moodle | The WOPI allow list on the Collabora server does not include the Moodle server address, so the host is rejected | Add the Moodle server address to the WOPI allow list, then reload the activity and check the Collabora server log for the rejection |
| Students see read-only mode when editing was expected | The activity or course role does not grant edit rights, so the document opens in view mode by design | Check the activity setting for edit access and the student's role in the course, then test with a student account rather than a teacher account |
| Moodle shows directory listings or errors after an upgrade | On Moodle 5.1 or later the web server document root still points to the main Moodle folder instead of /public | Point the web server document root to the /public directory, reload the site, and confirm the upgrade notes for your Moodle version |
| Edits are lost or versions diverge across a session | The load balancer does not route by the WOPISrc parameter, so users editing one document reach different Collabora pods | Configure the load balancer to route by WOPISrc and keep replica counts fixed, then test co-editing with two accounts on a multi-pod setup |
| Save fails or the document reverts after editing | Mixed HTTP and HTTPS endpoints, or a WOPI host setting that blocks the save callback from Moodle | Confirm the callback address is reachable from the Collabora server, match protocols end to end, and verify exact error text in the Collabora and Moodle logs |
What buyers ask about the Moodle and Collabora integration
What does it cost to add Collabora Online to Moodle?
The cost has two parts: software licensing and the work to set it up. For Collabora Online, the published Business plan is 3 euros per user per month for up to 99 users, and it includes long term support, a service level agreement, signed security updates and customer portal access. Sites with 100 or more users are quoted by Collabora with volume discounts, and the Enterprise plan adds integration support, customization services and roadmap input. Licensing recurs monthly or yearly, depending on the agreement. Setup, testing and sizing are one-time effort, and they scale with the number of Moodle sites, the file types staff need, and how many concurrent editing sessions the server must handle. Ask for a quote that separates licensing, setup, testing and any ongoing support.
How long does a Moodle and Collabora setup take?
Duration depends on the state of the Moodle site, the hosting model and the testing you require. A site that already runs a current Moodle release, has a Collabora server reachable over HTTPS and needs only a single editor activity in a pilot course is the shortest path. Longer timelines come from a Moodle upgrade, from building the Collabora server in new infrastructure, from certificate and DNS work, from testing file fidelity across the formats your courses use, and from sizing for class-wide sessions. Because the Moodle plugin and Collabora server both have versions that must match, confirm compatibility early. DeployOpen agrees timelines in a written scope before work starts, so ask for the schedule as part of the quote.
What does the school need to provide for the integration?
The school needs to provide the access and decisions that the work depends on. In practice this means:
- Administrator access to the Moodle site, including the ability to install and configure plugins
- A server or cloud environment for Collabora Online that you control, with network reachability from Moodle and from users' browsers
- DNS records and TLS certificates for both the Moodle site and the Collabora server
- A test course with sample documents in the formats teachers and students use
- Staff time from teachers and an administrator to review editing behavior, permissions and file fidelity
- A named owner for upgrades and for the Collabora server after handover
Agree these responsibilities in writing so that delays do not appear midway through the project.
Can our in-house team set up Collabora Online for Moodle?
Often yes, if the team already runs Moodle and can operate a Linux server with a reverse proxy, TLS and container or package-based deployments. The work is not only installation. It includes matching plugin and server versions, configuring access so that only permitted groups can open or edit documents, sizing the server for class-wide sessions, testing document fidelity and keeping the server patched. Collabora's own product materials describe Docker, system packages and Kubernetes as deployment options, so your team should choose one it can operate for years. If staff capacity or Moodle upgrade work is already committed, a fixed-scope partner can take the build while your team keeps ownership of the running system.
Can DeployOpen take on the Moodle and Collabora work under a fixed scope?
Yes. Most DeployOpen engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts. For this integration, the written scope would normally cover the Collabora server build, the Moodle plugin configuration, access rules for teachers and students, testing with your sample documents, sizing for your expected concurrency and handover documentation. DeployOpen does not publish a price list, so the next step is to share your Moodle version, user numbers, hosting constraints and file types, and receive a quote built from that scope. Ongoing support, upgrades and testing are available as retainers.
How many users can one Collabora server handle in a class session?
The honest answer depends on the server's resources, the document types, the number of simultaneous editors and how the load balancer routes sessions. Collabora's Helm chart documentation recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB, which is a useful starting reference for Kubernetes deployments. It also states that horizontal pod autoscaling is disabled because scaling breaks collaborative editing, so replicas are set manually, and load balancers must route by the WOPISrc parameter so all users editing one document reach the same pod. Test with a realistic class load before go-live, and confirm sizing with your own measurements.
Which Moodle version should we run before adding the editor?
Choose a Moodle release that your hosting, database and PHP versions can support, and that receives security updates for the period you plan to run it. Moodle 4.5 is a long-term support release with security support until 4 October 2027, and Moodle 5.3, released on 5 October 2026, is the next long-term support release with security support until 1 October 2029. Moodle 5.1 requires 64-bit PHP 8.2 or later, and sites must be on Moodle 4.2.3 or later to upgrade. Moodle 5.3 requires PHP 8.3 or later and sites must run Moodle 4.4 or later to upgrade. Confirm the plugin version that matches your Moodle release before you plan the rollout.
How DeployOpen scopes, delivers and supports this integration
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure. For Collabora Online and Moodle, we start from a written scope covering your Moodle version, your Collabora server layout and the course activities your teachers need, then build and hand over the integration in your environment.
How we scope
- Review your current Moodle version, PHP and database versions, and web server document root before any plugin work starts.
- Confirm which courses and roles will open editor activities and whether students may edit or only view.
- Agree Collabora server count, network paths between Moodle and Collabora, and the expected number of concurrent editors per session.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.
How we build
- Install and configure the Collabora Online plugin and the WOPI discovery settings for your Collabora server in your environment.
- Restrict WOPI requests to known Collabora server addresses and align protocol and TLS between Moodle and Collabora.
- Test editor activities with teacher and student test accounts, including saving, copy and paste, and common Office file formats.
- Document the build, configuration values and sizing assumptions so your team can repeat or audit the setup.
How we hand over
- Deliver a runbook covering plugin configuration, routing rules, user access settings and rollback steps.
- Walk your Moodle administrators and course designers through creating editor activities and checking permissions.
- Record the Moodle and Collabora versions tested so later upgrades can be planned against them.
- Provide the test evidence and configuration records your compliance team needs for its own assessments.
How we support
- Ongoing support, Moodle and Collabora upgrades, and continuous testing are available as retainers.
- Plan Moodle release upgrades and Collabora point releases together, retesting editor activities after each change.
- Review Collabora security advisories against your deployed version and agree a patching window with your team.
- Confirm with your auditors or certification bodies which evidence they accept, since DeployOpen prepares evidence but does not issue audit reports.
