Collabora Online for universities and schools

Why Collabora Online for universities and schools starts with the term calendar

Collabora Online fits an education institution when document editing runs inside its own Moodle or Nextcloud, so students and staff open Writer, Calc and Impress from the platform they already use and files stay on infrastructure the institution controls. The decision starts with the term calendar, not the product list, because editing load in education is concentrated: many students open and change documents in the same hours before an assignment deadline, while staff editing is spread across the year. Before choosing a topology, the IT lead should pull the institution's real deadline and exam dates for the past two years and map concurrent editing against them. Those figures, not average daily use, decide how many Collabora Online servers must exist on the peak day and whether they can be added in advance, since the Helm chart README notes that horizontal pod autoscaling is disabled and replicas are set manually.

Three things change once editing runs inside the institution's own platform. Peak load follows the calendar, so capacity planning and any scaling window have to be agreed with the teaching calendar owners. Data protection tightens when the user base includes minors, because the institution must decide which accounts can open documents at all, which can edit, and how long files and access logs are kept. Licensing is the third decision: the free CODE edition is described by Collabora as suited to testing, home use or small teams and not recommended for production, so a production school or university needs to compare the Business plan (3 euros per user per month for up to 99 users, per the pricing page) with an Enterprise quote for 100 or more users. Ask the vendor which tier covers support, security updates and integration help for the platform you run.

Which education data rules shape the Collabora Online build

This table maps each education data rule to what it asks for, what it means for who can open documents, and how it shapes the Collabora Online build. Read each row as a design input: the rule sets the requirement, and the build consequence tells your team what to configure, log or ask a vendor to confirm. The main takeaway is that document access, editor permissions, retention and contractor access decide most of the design, so settle them before rollout.

Requirement	What it asks for	Build consequence for Collabora Online
FERPA school official and access control duties	Contractors may act as school officials only under direct institutional control, and institutions must use reasonable access controls so staff see only records they have a legitimate educational interest in	Limit document access through Nextcloud or LMS group membership, confirm who at the hosting vendor can reach the servers, and write the vendor's control and redisclosure limits into the contract
FERPA 45-day inspection window	Institutions must comply with a parent's or eligible student's request to inspect records within a reasonable period and no more than 45 days after receiving it	Make documents findable by student and course identifiers, and confirm that storage and backup layouts let staff retrieve every file a request covers within the window
FERPA access logging	Institutions must record each request for access to and each disclosure of personally identifiable information, with the parties and their interests, for as long as the records are kept	Enable file activity logging in Nextcloud and the web server, retain proxy and WOPI request logs, and confirm which editing events Collabora Online records
COPPA for children under 13	Operators collecting personal information from children under 13 need a written security program with a designated coordinator, annual risk assessments and a written retention policy with deletion timeframes	Set a deletion schedule for student uploads and temporary editing copies, document who coordinates the program, and schedule an annual risk assessment for the editing stack
GLBA Safeguards for Title IV institutions	Institutions in federal student aid programs must keep a written information security program, require multi-factor authentication for anyone accessing an information system, and notify the FTC within 30 days of a qualifying event	Enforce MFA at the identity provider in front of Nextcloud or the LMS, cover Collabora Online hosts in the written program, and agree a notification path with the hosting vendor
ADA Title II web accessibility (28 CFR Part 35 Subpart H)	Public entities must make web content and mobile apps accessible under the Subpart H technical standard	Test the editor interface with assistive technology, confirm keyboard operation and document accessibility checks, and ask the vendor for its accessibility documentation before rollout

Choosing the host platform: Moodle, Nextcloud or both

Moodle is the learning platform most schools and universities will already run, so the question is usually whether its document editing can reach Collabora Online in the way teachers and students expect. Moodle is licensed under GPL-3.0 and can be self-hosted or run through managed hosting. Its version requirements are strict, and they change between releases, which affects how long an installation can stay in place.

PHP and database requirements: Moodle 5.1 requires 64-bit PHP 8.2 or later, with PHP 8.3 and 8.4 supported, and PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later. Moodle 5.3 requires 64-bit PHP 8.3 or later, PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later.
Upgrade entry points: Sites must be on Moodle 4.2.3 or later to upgrade to 5.1, and on Moodle 4.4 or later to upgrade to 5.3.
Document root change: From Moodle 5.1, the web server document root must point to the new /public directory instead of the main Moodle folder. Otherwise the site may show directory listings or errors, so web server configuration must be changed as part of the upgrade.
Support windows: Moodle 4.5 is an LTS release with security support until 4 October 2027, and Moodle 5.3 is the next LTS with security support until 1 October 2029. Confirm which branch your institution plans to run.

Before relying on Moodle as a WOPI host, confirm the current integration steps for your exact Moodle and Collabora versions in the Moodle documentation and Collabora's documentation.

Settings that matter most for student and staff editing

Most education rollouts succeed or fail on a handful of settings: who can reach the Collabora server, who can edit versus view, how people sign in, and how co-authors are routed. Each card below is a decision to make and verify before the first term begins.

Lock down WOPI allow lists

Nextcloud's administration guidance recommends restricting WOPI requests to the IP addresses of your Collabora servers, so that only your Nextcloud or Moodle front end can request document sessions. Use the same protocol on both ends, preferably HTTPS, for the Collabora server URL and the Nextcloud installation. Check that the allow list includes every address your ingress or NAT actually presents, because a missing address shows up as an editing failure for students who have no way to diagnose it.

Limit editing by cohort

In Nextcloud Office, administrators can restrict which groups may use the editor and which groups may edit rather than only view. For a university, this lets you map groups to course cohorts, staff roles and visiting researchers, so that a graduate cohort can edit a shared thesis folder while undergraduates in a lecture group only read published materials. Agree the group model with the registrar and course owners before the group sync runs, since changing it mid-term affects live coursework.

Use institutional sign-in

Students and staff should sign in with the credentials the institution already issues, not with separate local accounts. Nextcloud's LDAP app lets LDAP and Active Directory users appear in Nextcloud and log in with directory credentials, and Nextcloud also documents OpenID Connect and SAML backends. Confirm how leavers, withdrawals and alumni are handled in the directory, because accounts that outlive enrolment keep access to documents they should no longer reach.

Match Moodle login to campus identity

Moodle core ships authentication plugins for LDAP, Shibboleth, OAuth 2 and LTI, among others, and these determine how learners reach the course pages where Collabora editing is embedded. Pick one primary method for each user population, and test the path a student takes from a course activity into the editor, including the case where the session has expired. Confirm with your identity team which attributes the sign-in returns, since the editing permissions you set in the host platform depend on them.

Route co-authors to one pod

Collabora's Helm chart documentation states that horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste, so replica counts are set manually. Your load balancer must route by the WOPISrc parameter so that everyone editing one document reaches the same pod. During term peaks, plan replica counts ahead of the assignment deadlines you know about, and test routing with two students editing the same file from different networks before relying on group projects.

Test coursework formats before term

Collabora Online supports Microsoft formats including docx, xlsx and pptx, alongside OpenDocument, PDF and other formats. Coursework often arrives as files built in Microsoft Office with embedded charts, tracked comments, fonts and macros. Build a test set from real past submissions, open and save each file in the editor, and compare layout, formulas and presentation timings with the originals. Record the failures and decide with course owners whether they are acceptable, rather than discovering them during marking.

How term peaks change sizing and where the Helm limits apply

Peak concurrency, not average use, should set the size of your Collabora Online deployment. A school or university may sit near idle for most of the year and then see every student and staff member open documents within the same hour during an exam week, a coursework deadline or the first week of term. Those short windows decide whether the editor feels responsive or stalls, so the sizing exercise starts from the busiest hour you expect, not from the monthly average. Confirm with your Moodle or Nextcloud administrators which academic calendar events generate the heaviest document activity, because assignment submission deadlines and exam-period coursework often differ by faculty.

The official Collabora Online Helm chart disables horizontal pod autoscaling, because scaling breaks collaborative editing and copy and paste between sessions. Replica counts are therefore set by hand in the chart values, and the load balancer in front of the pods must route by the WOPISrc parameter so that everyone editing one document reaches the same pod. The chart's README recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. Treat these as the reference ceiling for a single pod, not as a sizing result. Your replica count is a decision you revisit before each term, and an unplanned surge cannot be absorbed by the cluster adding pods on its own.

Before you choose a replica count, measure real concurrency from your own logs. Pull the number of active WOPI sessions per hour from the reverse proxy or Collabora logs for the last full academic year, identify the highest-load week, and compare it with the pod resource usage you observe at that point. Then plan a load test around that week's profile, with the same document types and session counts your students use, and confirm that editing stays responsive and that sessions do not drop when you scale replicas up or down. Ask your Collabora Online support provider to review the test results and the chart values before the peak arrives.

How a school or university rollout moves from pilot to term start

The sequence turns an untested editing service into one that has been checked against real coursework, sized for the busiest term week, and handed to the team that will run it after go-live. Each step ends with a written check, so the cut-over decision rests on evidence rather than on the pilot feeling successful.

Confirm the host platform and versions
Start by recording which learning or file platform will host the editor, which version it runs, and which Collabora Online branch you intend to deploy against it. Moodle and Nextcloud both publish their own supported version ranges and upgrade rules, so the team checks those against the chosen Collabora branch before any installation work begins. The IT lead and the platform owner sign off on this compatibility record. The step is complete when the versions, the WOPI integration method and the named owner for each component are written down in one document that everyone is working from.
Run a limited pilot with one group
Choose one faculty, department or year group and give them access through a non-production instance. CODE, the free edition, suits testing and can be used here, but Collabora does not recommend it for production, so the pilot is a test of fit, not the service you will run for students. The learning technology team selects the users and collects feedback on opening, saving, commenting and co-editing. The pilot is complete when the group has used the editor across a full set of realistic tasks and the team has a list of problems ranked by how many users they affect.
Verify format fidelity on real coursework
Take a representative sample of actual assignments, templates, spreadsheets with formulas, and presentations with embedded media, and open them in the editor. Compare the layout, fonts, tracked changes, comments and charts against the copies opened in Microsoft Office or LibreOffice. Record every difference and decide which ones are acceptable for teaching and which need a workaround, such as a template fix or a font installed on the server. The step closes with a signed list of accepted differences that the academic owners have reviewed.
Set group permissions and audit logging
Configure who may open the editor and who may edit, using the group controls your host platform provides. In Nextcloud Office, administrators can limit editor access by group and separate view rights from edit rights, so students in a course can be given edit access to their own work while staff templates stay read-only. Confirm which events your platform logs for opened and edited documents, and check that the log retention matches your institution's records policy. The step is done when a test account from each role has been checked against the expected permissions and the logs show those actions.
Load test against the term peak
Build a load test that matches the busiest realistic week, such as the days before an assessment deadline, with concurrent editing sessions in the same documents. Watch CPU, memory, response times and connection errors on each Collabora server, and confirm that users editing one document are routed to the same pod or server. The Helm chart documentation states that horizontal autoscaling is disabled and replicas are set manually, so capacity is planned as a fixed number. The step is complete when the test results show headroom at the peak target and the team has written down the replica count and resource settings it will run with.
Cut over before term with a rollback plan
Schedule the production switch-over well before the first teaching day so there is time to fix problems. Before the change, write the rollback steps: which configuration to restore, how to point the platform back to the previous setup, and who makes that call. Announce the change to students and staff with a short guide that covers opening documents and the known format differences from the pilot. The cut-over is complete when the production integration works with a test account, the rollback has been rehearsed, and the support contact is published to users.
Hand over monitoring and patching
Transfer the running service to the team that will operate it, with a written runbook covering monitoring, log review, backup scope, and the process for applying Collabora security updates and point releases. Confirm who receives Collabora security advisories and who approves each patch window, and agree how that fits with the host platform's own release schedule. If the institution chooses a supported subscription for production, confirm what the support tier includes using the pricing page before the handover, since the scope of that support determines who responds to incidents. The step closes when the operations team has run one monitoring check and one patch cycle on the service.

Questions education IT teams ask before hiring a partner

What drives the cost of Collabora Online for a school compared with a university?

The main drivers are user count, the plan you need, where the servers run, and how much integration work the platform requires. Collabora's pricing page lists a Business plan at 3 euros per user per month for up to 99 users, with long term support, a service level agreement, signed security updates and customer portal access. The Enterprise plan applies to 100 or more users and is quoted with volume discounts, and it adds integration support, customization services and roadmap input. A small school may fit the Business plan, while a university with thousands of accounts will usually be quoted on Enterprise. Hosting in your own cloud or data center, the Moodle or Nextcloud integration, and testing against your document library all add one-time labor. Ask for a quote that separates the one-time work from the recurring subscription and states the user count it is based on.

Does Collabora offer an education price for schools and universities?

No education price is published in the sources available for this page, so confirm it directly with Collabora before you budget. The public pricing page lists the Business plan and the Enterprise plan with volume discounts, and it does not describe a separate education tier. Ask Collabora whether any discount applies to your institution type, how user counts are measured for students and staff, and whether accounts used only by temporary or guest users are counted. Ask whether the free CODE edition is acceptable for your use, since Collabora describes CODE as suited to testing, home use or small teams and not recommended for production. Your partner can help you prepare the question list, but the pricing answer must come from Collabora.

How long does a Collabora Online rollout take in a school or university?

The timeline depends on how ready your host platform is, how many document types you must test, and how many change windows your team can use. In practice, the longest steps are usually confirming the host integration, testing the document formats your staff and students actually use, and agreeing on access groups. Those steps are set in the written scope, so the duration should appear there with named milestones rather than as a general estimate. Ask any partner to show which tasks depend on your Moodle or Nextcloud version, your reverse proxy and your identity system, and which tasks depend on your own staff making decisions. Plan for a pilot with a small user group before the term peak, and ask whether the scope includes that pilot and the rollback steps.

What does the institution need to provide for a Collabora Online project?

The institution normally provides the platform owners, the accounts and directory access, the test documents, and the change windows for production work. Expect to name a contact for the Moodle or Nextcloud host, a contact for identity and single sign-on, and someone who can approve access groups. The team also needs realistic sample files, including old Microsoft Office documents, spreadsheets with formulas, and any templates used in coursework or administration, so that fidelity can be checked. Confirm who owns the reverse proxy, TLS certificates and DNS records, and when the systems can be changed without disrupting exams or enrollment. Ask the partner to list these inputs in the written scope so that delays can be traced to a named dependency.

Can a small IT team run Collabora Online without an outside partner?

A small team can run Collabora Online if it has someone comfortable with Linux, containers or packages, a reverse proxy, and the administration of its host platform. The first deployment is where most effort goes, because the host must be configured to trust the Collabora server and the connection must work over HTTPS. Ongoing work includes applying point releases, watching security advisories, and checking that updates to Moodle or Nextcloud still work with the editor. Collabora publishes security advisories, and its 25.04 release notes record a fix in point release 25.04.7.5 that was released on January 29, 2026, which shows why patch time matters. Decide whether your team will own monitoring and upgrades, and whether a retainer for support and upgrades would cover the gaps during term peaks.

How is data about minors protected under COPPA and FERPA?

Under FERPA, a school or university that uses an outside service must keep the vendor under its direct control for education records and must limit access to officials with a legitimate educational interest. The institution must also keep a record of disclosures of personally identifiable information from student records, and it must respond to parent or eligible student access requests within 45 days. For children under 13, the COPPA Rule requires operators that collect personal information to maintain a written information security program with a designated coordinator and at least annual risk assessments, and it limits retention to what is reasonably necessary. Collabora Online runs on your infrastructure, so the main questions are where documents and logs are stored, who can read them, how long they are kept, and how the document servers are logged. Ask your counsel which role each party holds, and document the answer in your data protection records.

How do we check that Collabora Online is accessible to students and staff?

Start by naming the accessibility standard your institution must meet and the people who will test. For US public institutions, the Department of Justice's web and mobile accessibility rule in 28 CFR Part 35 Subpart H applies to state and local government services, and you should confirm with counsel whether it covers your institution. Accessibility of the editor depends on the browser, assistive technology and the host page around it, so test those together. A reasonable plan tests keyboard navigation, screen reader behavior, zoom and contrast with the document types your users actually open, and records the results. Ask any partner whether the scope includes a documented accessibility test, what it covers, and who fixes issues found in the host integration versus the editor itself.

Compliance duties education teams must map to the deployment

Education teams answer to more than one regime at once, and each one lands on a different part of a Collabora Online deployment: who can open documents, what gets logged, where files are kept and how long they stay. The cards below set out the duties to map before go-live. DeployOpen prepares systems, controls and evidence for these assessments, but independent auditors and certification bodies issue the audit reports and certifications.

FERPA disclosure recordkeeping

Under 34 CFR 99.32, an institution must record each request for and disclosure of personally identifiable information from a student's education records, including the parties and their legitimate interests. For Collabora Online, map which document stores and WOPI hosts can expose student files, and confirm that access events are logged where they can be retrieved. A contractor running the editing service may only receive records as a school official under 34 CFR 99.31(a)(1)(i)(B), so the institution must keep direct control of use and maintenance. Confirm that contract terms reflect this.

FERPA access limited to legitimate interest

Under 34 CFR 99.31(a)(1)(ii), an institution must use reasonable access controls so school officials see only the education records in which they have a legitimate educational interest. In a Collabora Online rollout this means group rules in the host platform decide who may open, edit or view a document, not only who can log in. Test the rules with a staff account from a department that should not see a given course folder, and record the result as evidence.

COPPA written security program

The COPPA Rule in 16 CFR Part 312 applies when an operator collects personal information from children under 13. It requires a written information security program with a designated coordinator and at least annual risk assessments. Schools that run an editing service for younger pupils should confirm who is the named coordinator, when the last risk assessment was completed and whether the hosting platform's logs and document stores fall inside that assessment. Ask the vendor whether it treats its own role as an operator.

COPPA retention and deletion

Under 16 CFR 312.10, operators may keep a child's personal information only as long as reasonably necessary for the purpose it was collected, and they must maintain a written retention policy with a deletion timeframe. For documents, this covers the file itself, its autosave or lock traces, and any backups taken by the host or the Collabora server. Ask the platform team to state the deletion timeframe for student-created files, and confirm that backups inherit the same deletion rule.

GLBA Safeguards for Title IV institutions

Institutions in the Title IV federal student aid programs agreed to comply with the GLBA Safeguards Rule in 16 CFR Part 314. That rule requires a written information security program and multi-factor authentication for anyone accessing any information system. If student aid data could be attached to, or discussed in, documents edited in Collabora Online, the editing path falls within scope. Confirm that the identity provider enforces multi-factor authentication for every account that can reach the editor, including administrator and service accounts.

NIS2 and GDPR for EU institutions

Where an institution operates in the EU, GDPR under Regulation (EU) 2016/679 governs the processing of student and staff personal data, and NIS2 under Directive (EU) 2022/2555 may apply depending on the institution's sector and size and on national transposition. Map the Collabora Online servers, the host platform and the storage locations to a processing record, and confirm where documents and logs are physically held. Confirm with counsel which NIS2 obligations apply to your institution, since the directive's reach depends on national implementation.

Accessibility under 28 CFR Part 35

Subpart H of 28 CFR Part 35 sets web and mobile accessibility requirements for state and local government entities, which include many public universities and schools. An editor that students must use for coursework falls within the accessibility of services they provide. Before rollout, test keyboard navigation, screen reader behavior and high-contrast modes in the editor as it appears inside your chosen host, and record the findings with the remediation plan.

Keeping Moodle, Nextcloud and Collabora supported across academic years

The core task in this section is matching each platform's release cadence to the academic calendar, because the three components do not move on the same schedule. Moodle ships major releases in April and October and minor point releases every two months. 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 LTS with security support until 1 October 2029. Nextcloud publishes a new major version every four months and supports each one for one year through monthly maintenance releases, so Nextcloud 33 is supported until February 2027 and Nextcloud 34 until June 2027. Nextcloud does not allow skipping major releases, so a site that falls behind has to step through each one in turn.

Collabora Online adds a different pattern. The 25.04 branch was still receiving point releases in 2026, and 25.04.13 was released on 21 September 2026. Advisories matter here: the 25.04 release notes record that 25.04.7.5, released on 29 January 2026, fixed CVE-2026-23623, and that package signing keys were updated for RPM and DEB users. Confirm which branch your servers run, check that your package manager trusts the current signing keys, and decide who receives advisories for the Collabora servers, since these are often managed by a different team from Moodle and Nextcloud. Also confirm which branch your Collabora Online edition is on, as CODE follows a rolling release rather than a support branch.

Plan upgrades for the summer or the gap between terms, never the week before exams. Build a staging copy of Moodle, Nextcloud and Collabora with a representative set of course documents, test every upgrade step there, and check that editing still works through the WOPI connection after each change. Back up before every step, and disable third-party apps and plugins until their compatibility is confirmed. Ask your Moodle, Nextcloud and Collabora contacts for the upgrade path and the minimum PHP and database versions each release requires, since these change between majors and may force a database or web server change before the platform upgrade itself.

How DeployOpen scopes and delivers education deployments

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the institution's own infrastructure. For Collabora Online in a university or school, that means agreeing the platform host, the user groups, the peak term load and the data protection duties in writing before any build starts, then handing over a system the institution's own staff can run.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
The written scope names the host platform, such as Moodle or Nextcloud, and which user groups may edit or only view documents.
Scope records how peak term load was estimated, the hosting location and the data protection roles of each party.

How we build

We deploy Collabora Online in your cloud accounts, data centers or restricted networks, with routing that keeps each document on one server.
We configure WOPI host allow lists, HTTPS between the host and the Collabora server, and group-based access in the host platform.
We test document fidelity for the formats your students and staff actually use, and check editing under a load profile agreed in scope.

How we hand over

Deliverables include configuration records, runbooks for restarts, upgrades and certificate renewal, and the access and logging settings used.
We document the records needed to answer a FERPA or GDPR access request for the parts of the stack we configured.
Your staff receive a handover session covering monitoring, the update process and the support arrangements agreed in the quote.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
Retainers can cover Collabora Online point releases and host platform upgrades, including checks that WOPI integration still works afterward.
Ask for the support tier, response expectations and the Collabora subscription terms in writing before you commit to a support plan.