Open source digital workplace suite for education

Why a campus workplace suite is different from a corporate one

A university IT leader or school authority running a self-hosted workplace has a problem most corporate buyers never face: staff, students and, in schools, minors all sign in with one identity, and the records they create fall under education law rather than general privacy rules alone. A self-hosted suite can cover files, office editing, chat, video and a wiki under one campus identity layer. Which platforms fit depends on the age groups served, the volume of teaching delivered live, and whether the institution participates in US Title IV federal student aid, since that participation brings the GLBA Safeguards Rule into scope alongside FERPA. This page covers only what changes for education. General suite selection, sizing and sovereignty are covered on the sibling pages.

The first decision is who counts as a school official. Under FERPA, a contractor such as an implementation partner may receive education records only if it performs a service the institution would otherwise use employees for, works under the institution's direct control, and respects redisclosure limits (34 CFR 99.31(a)(1)(i)(B)). Institutions must also use technical access controls so that staff see only the records tied to their legitimate educational interest (34 CFR 99.31(a)(1)(ii)). In practice, this means the directory groups that feed the workplace must reflect enrolment and role data accurately, and that a file share or wiki space holding student records is not open to every staff account by default. Confirm with your counsel how these rules apply to your institution before you map groups to spaces.

Age and teaching load shape the rest of the design. If the suite serves learners under 13, the COPPA Rule (16 CFR Part 312) applies to operators collecting their personal information, and it requires a written information security program, a designated coordinator, at least annual risk assessments and a written retention and deletion policy (16 CFR 312.8 and 312.10). For live teaching, BigBlueButton or Jitsi Meet become core services rather than occasional meeting tools, so you should confirm the server sizing, network ports and recording storage with your video platform before term starts. Ask your partner to document which components hold records, how access requests are logged under 34 CFR 99.32, and who answers a parent's request to inspect records within 45 days (34 CFR 99.10(b)).

Which education rules shape the build

This table maps the US education and sector rules most likely to apply to a self-hosted workplace and states what each one means for access scoping, logging, retention, identity and contractor control. Read each row as a design input to settle before tenant design begins, and confirm applicability with counsel and your compliance office.

Rule	What it requires	What it means for the build
FERPA school official and access control (34 CFR 99.31)	Outside contractors may receive education records as school officials only under direct institutional control, and the institution must limit each official to records with a legitimate educational interest through access controls.	Scope file shares, mail folders and chat rooms by role and course or department, and place the hosting provider under contract with direct control terms and redisclosure limits.
FERPA inspection window (34 CFR 99.10)	Access requests from parents or eligible students must be met within a reasonable period and not more than 45 days after receipt.	Confirm that student records can be located across files, mail and chat by a single identifier, and that an export procedure can meet the 45-day ceiling.
FERPA disclosure record (34 CFR 99.32)	Each request for and disclosure of personally identifiable information must be recorded with the parties and their legitimate interests, kept as long as the records are kept.	Enable audit logging in each component, forward logs to a central store with retention matched to the record lifecycle, and test that a disclosure can be reconstructed.
FERPA enforcement exposure (34 CFR 99.67)	The Secretary may withhold payments, issue a cease and desist order or terminate funding eligibility for non-compliance.	Treat FERPA controls as a funding risk, so assign an owner for each control and keep evidence of configuration and access reviews.
COPPA for children under 13 (16 CFR Part 312)	Operators collecting personal information from children under 13 need a written security program with a designated coordinator, at least annual risk assessments, and a written retention policy with deletion timeframes.	Apply to K-8 or youth programs using accounts in the workplace suite. Limit child accounts, disable unneeded collection, and set automated deletion for accounts and attachments.
GLBA Safeguards Rule for Title IV institutions (16 CFR Part 314)	Institutions in Title IV programs must maintain a written information security program, require multi-factor authentication for anyone accessing any information system, and notify the FTC within 30 days of a notification event affecting at least 500 consumers.	Enforce MFA in the identity layer for every login path, including web, mobile and API clients. Build an incident runbook that meets the 30-day FTC notice clock.
HIPAA technical safeguards (45 CFR 164.312), only where a medical school or affiliated clinic is in scope	Protect ePHI sent over electronic networks against unauthorized access, and keep audit controls that record and examine activity in systems holding ePHI.	Separate clinical data into dedicated spaces and encrypt transport. Keep audit logs for ePHI systems. Do not extend this scope to general campus services unless ePHI is stored there.
SEC Rule 17a-4(b)(4) (17 CFR 240.17a-4), only where a broker-dealer function runs on campus	Broker-dealers must preserve communications relating to the business, including inter-office messages, for not less than three years.	Applies to finance or trading programs with broker-dealer status. Route their mail and chat into a separate archive with write-once retention, and confirm the scope with counsel.

Which platforms fit a campus and why

openDesk is a Kubernetes-based open-source digital workplace suite provided by ZenDiS GmbH, a federally owned German company that took over development in January 2024. It bundles Element with Nordeck widgets for chat, CryptPad with diagrams.net, Nextcloud for files, OX App Suite for groupware, XWiki, Nubus for portal and identity, OpenProject, Jitsi and Collabora as the web office. Universities that want one platform under one identity layer, and that have Kubernetes operations capacity, will evaluate it first. Each bundled component keeps its own license, so the openDesk deployment code is Apache-2.0 while Nextcloud and Nubus are AGPL-3.0 and OpenProject is GPL-3.0.

Kubernetes prerequisite: openDesk requires a CNCF-certified cluster at v1.33 or later, an ingress controller, cert-manager and an RWO volume provisioner.
Production services: the project expects external PostgreSQL 15, MariaDB 10, Redis 7, object storage, an SMTP relay, ClamAV over ICAP and a TURN server.
Enterprise edition: ZenDiS recommends openDesk Enterprise Edition for production, adding SLA-backed 2nd and 3rd level support and patches.
Release cadence: major releases are planned annually in Q3 and minor releases monthly, so upgrade rehearsal is a standing task.
Campus fit: confirm whether bundled chat, office and wiki components cover the teaching and research workflows your faculties already use.

Confirm the Kubernetes and operations model with your platform team before selecting openDesk for the full campus.

Deployment patterns for term-time load and student data

Term-time teaching load and student records shape the workplace suite more than the software list does. The cards below cover the decisions that come first: how to size the virtual classroom server, how to get through campus firewalls, what openDesk needs before production, how to separate student and staff tenants, and how to keep the records that FERPA requires.

BigBlueButton server sizing

The BigBlueButton 4.0 install guide asks for at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 500 GB of disk for recordings (50 GB without recording) and 250 Mbit/s symmetrical bandwidth. Plan one server for the peak concurrent sessions in a term, not the average week. Recording is the disk decision: confirm with faculty whether lectures will be recorded before you size storage. Upgrades from 2.6, 2.7 or 3.0 are not supported, so plan a clean install.

Campus firewall ports and TURN

BigBlueButton needs TCP ports 80 and 443 and UDP ports 16384 to 32768 reachable, a valid hostname for SSL, and Docker for sandboxed document conversion. Restrictive campus networks, guest Wi-Fi and some student residences often block UDP media, so the install guide recommends a TURN server for users behind those firewalls. Ask the network team to test media from student networks during a pilot, not only from staff offices.

openDesk production external services

An openDesk evaluation can run on a small cluster, but production expects external, production-grade services: PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Each of these needs an owner, backup policy and patch window. Confirm with the university IT team who operates each service, and whether ZenDiS support for Enterprise Edition covers the production stack in your contract.

Separate student and staff tenants

Students and staff have different records, retention and access rules, and student accounts often need to be shorter lived than staff accounts. Consider separate realms, groups or instances for each population, with identity federated from the campus directory and attribute mapping that prevents students from reaching staff-only spaces. Test the boundary with a sample student account before term starts, and document which group may access which shared drive or course space.

Backup and logs for FERPA disclosures

FERPA requires institutions to record each request for, and each disclosure of, personally identifiable information from education records, with the parties and their legitimate interests, for as long as the records are kept. Logs from the suite, identity provider and file server must be retained, protected from tampering and restorable together with backups. Ask your vendor and partner which audit events each component emits, where they are stored, and how a disclosure record is reconstructed for a parent's inspection request.

How a campus rollout runs, phase by phase

The sequence moves from agreeing what student and staff data may go where, through identity and a faculty pilot, to a term-time load test, so the campus opens the suite only after each control has been checked. Each phase closes with a named artifact that the registrar, general counsel and IT leadership can sign off.

Map records and access with the registrar and counsel
Before any platform is configured, the registrar, general counsel, the data protection lead and IT agree which record types are education records, which staff roles are school officials with a legitimate educational interest, and which vendors or hosting partners will hold that data. DeployOpen facilitates the workshops and drafts the data map, but the institution owns the decisions. The phase is done when a signed data map lists each data category, its location, its retention period and the access groups allowed to see it. Ask for this map to be treated as the controlling input for every later configuration choice.
Federate campus identity and map attributes
The campus identity provider becomes the single source for sign-in, and the suite receives only the attributes the data map permits. The team confirms how staff and student roles are derived from directory attributes, how departments and course groups are mapped, and how leavers lose access. Multi-factor authentication is enforced at the identity layer for every account that reaches an information system, which the institution's GLBA Safeguards obligations also expect. The phase closes with a test matrix showing that a sample of staff, students, alumni and departed users receive exactly the access the data map describes. Confirm the directory product and connector details with the implementation partner before the pilot starts.
Run a pilot with one faculty group
A single faculty group uses files, office editing, chat and video for their real coursework and committee work for a limited period agreed in advance. The pilot exposes gaps in sharing defaults, external guest handling, storage quotas and support routes that a lab test rarely shows. Support staff log every ticket by category so the team can see which problems are configuration and which are training. The phase is complete when the pilot owner signs a short acceptance report listing open defects, accepted risks and the changes made to the design. Changes that touch the data map return to the first phase for re-approval.
Embed BigBlueButton in the LMS on a clean install
For teaching, BigBlueButton is installed on a fresh Ubuntu 24.04 64-bit server, because the 4.0 release does not support direct upgrades from 2.6, 2.7 or 3.0. Where the institution already runs 3.0, the team plans a migration to a new server rather than an in-place upgrade. The server is sized against the published minimums: 16 GB of RAM with swap, 8 cores with high single-thread performance, storage for recordings or 50 GB without recording, and 250 Mbit/s symmetrical bandwidth. Ports 80, 443 and UDP 16384 to 32768 must be reachable, and a TURN server is recommended for students behind restrictive networks. The phase is done when a test course in the LMS launches a session, a recording is stored or intentionally disabled, and the API secret is confirmed to stay server-side.
Onboard students in waves outside exam periods
Students are added in cohorts rather than all at once, with each wave timed to fall outside examination and assessment windows so that account problems do not coincide with graded work. Each wave runs the same checklist: confirm identity sign-in, confirm course membership, confirm storage access, and confirm that a short training session has been delivered. The help desk tracks login failures and mailbox or storage errors per wave and feeds them back to the identity team. The phase is complete when every cohort has passed the checklist and the open defect list is either closed or formally accepted. Ask the partner to show how wave scheduling interacts with the academic calendar your institution publishes.
Test term-time load and restore from backup
Before the full term opens, the team runs a load test that simulates peak concurrent video sessions, file synchronization, document co-editing and chat activity at the expected maximum. Results are compared with the sizing assumptions for the Kubernetes or virtual machine hosts, storage, database tiers and bandwidth. The same window includes a restore rehearsal from backup into a separate environment, timed and documented, because an untested restore does not count as a recovery control. The phase closes with a signed capacity report, a restore record and a go-live decision by the service owner. Ask for the test scripts and the acceptance thresholds in writing before the test begins.

Evidence a registrar, auditor or state reviewer will ask for

This table maps the records a registrar, external auditor or state reviewer commonly requests to the component or process that produces them in a self-hosted education workplace. Use it to decide which systems must be configured to generate evidence from day one. DeployOpen prepares these systems, controls and records for an independent assessment; it does not issue audit reports or attestations.

Evidence item	Produced by	What the reviewer checks
Access review records for student and staff data	Campus identity provider and group sync into Nextcloud, OX or Mattermost	Who holds access to which education records, and whether access was reviewed and removed when roles ended
Disclosure log for student records	Audit logging in the file, mail and chat components, plus records of contractor access	Each request and disclosure of personally identifiable information, with the parties and their legitimate interest
Retention policy and deletion timeframes	Written policy plus retention settings in Nextcloud, mail and chat, and backup rotation	Records kept only as long as the policy allows, with proof that deletion runs and covers backups
MFA configuration for all system access	Identity provider (for example Keycloak) enforcing second factors for staff and admin accounts	Multi-factor authentication applied to every information system, with exceptions documented
Written information security program	Organization-owned document, supported by configuration baselines and hardening records	A named coordinator, defined controls for each component, and the scope covering every system holding student data
Annual risk assessment	Organization-owned process, fed by scan results and security test reports	Yearly review that covers each platform, its data flows and its open findings with owners and dates
Audit logs and monitoring evidence	Web server, identity, database and application logs forwarded to a central store	Logs exist for administrator and data access, are protected from change and are reviewed on a defined schedule
Contractor and service provider agreements	Signed contracts with implementation partners and hosting providers, referencing data handling duties	The contractor works under the institution's direct control and follows agreed redisclosure and deletion limits
Incident and notification records	Incident ticketing and log evidence from the security operations process	Notification events are identified, recorded and reported within the timeframes the applicable rules set

What education buyers ask before hiring an implementation partner

What drives the cost of a self-hosted workplace suite for a university?

The biggest drivers are the number of components in scope, the number of identity sources to federate, the number of learning management systems that need video integration, and the expected recording volume. Each component adds configuration, testing and documentation work, and each identity source adds attribute mapping and login testing. Recording volume affects storage, which is a recurring infrastructure cost. Ask any partner for a quote that lists each component, each integration and each identity source as separate line items, with one-time implementation work separated from recurring operations work. Infrastructure is usually billed by your cloud or data center provider, not by the partner, so ask for that split explicitly.

How should an implementation fit around the academic calendar?

Plan the heaviest cutovers outside term start, exams and enrollment peaks, and build the rollout so that staff and students are not moved onto a new platform in the same weeks they need it most. A typical sequence starts with identity federation and a pilot group, then moves staff file and mail workloads, and only then opens teaching tools to students. Video for teaching deserves its own load test before term, because BigBlueButton 4.0 has specific server minimums and needs open UDP ports for media. Ask the partner to show a dated plan that places go-live windows against your registrar and exam calendar, and to name the freeze periods they will respect.

What does the university need to provide before implementation starts?

Three inputs decide whether the project stays on schedule: sign-off from the registrar on which student records may be stored or processed, administrative access to the identity provider the campus already runs, and named data owners who can approve migration and retention decisions. Under FERPA, the institution remains responsible for education records, and a contractor may act as a school official only under the conditions in 34 CFR 99.31(a)(1)(i)(B). Ask the partner to produce a written list of these inputs, with an owner and a due date for each, before the statement of work is signed.

Can our IT team run the workplace suite after the partner leaves?

Yes, if the staff who will operate it are included in the build and have the skills to run it. A self-hosted suite needs people who can handle container or Kubernetes operations, certificates, backups, monitoring and identity administration. For openDesk, the deployment is Helmfile and Helm based and requires a CNCF-certified Kubernetes cluster at v1.33 or later, so confirm that your team already runs that platform or budget for training. Ask the partner which runbooks, handover sessions and documentation they will deliver, and whether ongoing support is handled through a retainer.

How are upgrades handled when openDesk ships monthly minor releases?

Upgrades need a defined cadence and a test environment, because openDesk plans major releases annually in Q3, minor releases monthly and patch releases on demand. Only the latest minor version is supported, in-place upgrades between majors are not guaranteed, and skipping several minor versions may require intermediate steps. Ask the partner how they will stage each release in a non-production environment, how long a rollback takes, which person approves production changes during term, and whether upgrades are included in a retainer or quoted separately. Check the release management documentation before agreeing to a schedule.

How many learning management systems can video integration cover?

BigBlueButton is embedded in Canvas, Moodle Cloud, Sakai, Jenzabar, D2L and Schoology, and the project says these represent over 75% of the worldwide LMS market. Each LMS integration still needs its own configuration and testing, and any LMS not on that list needs a separate integration plan. Ask the partner to list each LMS in use on campus, state whether each one is supported by a documented BigBlueButton integration path, and identify which integrations need custom work. Also confirm whether Greenlight or LTI will be installed on the same server, since the install script supports both.

Which identity and student records checks should the engineering team verify?

Engineers should confirm that every system accepts logins from the campus identity provider, that only staff with a legitimate educational interest can reach student records, and that access and disclosures are logged. FERPA requires reasonable access controls under 34 CFR 99.31(a)(1)(ii) and a record of disclosures under 34 CFR 99.32. For video, confirm that API checksums are generated server-side and that no shared secret appears in a web page, as the BigBlueButton API documentation warns. Ask the partner for a test plan that covers these checks in each component, with evidence kept for the compliance file.

What load should we plan for during term time video sessions?

Sizing depends on concurrent sessions, recording use and bandwidth, and the partner should base the design on your own usage data rather than a generic number. For BigBlueButton 4.0, the install documentation lists at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 500 GB of disk for recordings or 50 GB without recording, and 250 Mbit/s symmetrical bandwidth on a single server. Larger deployments may need multiple servers, which is where Scalelite can help distribute meetings. Ask for a load test report using your expected peak class sizes before term starts.

Questions to ask a partner before signing a fixed-scope agreement

Start with FERPA, because it decides who may touch student records in the workplace stack. Ask the partner how they would qualify as a school official under 34 CFR 99.31(a)(1)(i)(B): which services they perform that staff would otherwise do, how the institution keeps direct control over the use and maintenance of records during the engagement, and how redisclosure limits are written into the contract. Then ask how access to education records will be restricted in Nextcloud, OpenProject and the chat service through group and role design that enforces the legitimate educational interest test in 34 CFR 99.31(a)(1)(ii). Ask who maintains the disclosure log that 34 CFR 99.32 requires and where it lives. A partner who answers these with general statements about security has not yet done the compliance design.

Next, test the identity and video work against the campus you actually run. Ask for named examples of OpenID Connect or SAML federation with a campus directory, and ask how they would map affiliation attributes such as staff, student and guest onto roles before any user logs in. For teaching, ask whether they have installed BigBlueButton 4.0 on a clean Ubuntu 24.04 server, since direct upgrades from 2.6, 2.7 or 3.0 are not supported, and how they would handle an existing 3.0 deployment. Ask them to size for peak concurrent sessions rather than the average, using the published minimums as a floor: 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, and 250 Mbit/s symmetrical bandwidth. Confirm who opens UDP ports 16384 to 32768 at the campus firewall, and whether a TURN server is in scope.

Finally, ask how the partner proves the system works under term-time load and who owns each data obligation afterward. Request their load test plan for exam weeks and enrollment peaks, including the scenario, the tool, the target concurrency and the pass criteria, and ask whether the test runs against the production-like environment. For children under 13, ask who acts as the written information security coordinator and who deletes personal information under the retention policy required by 16 CFR 312.10, and get that split in writing. Ask how audit evidence is packaged for an external assessor, such as configuration baselines, access reviews and logs, and whether the partner will walk the assessor through it. DeployOpen prepares evidence for assessments but does not issue the audit opinion, so confirm that the assessor's requests are scoped into the fixed-scope agreement.

How long does a campus deployment take and what does it need from staff

How long does a university workplace deployment take?

No duration can be stated responsibly until the scope is written down, because the timeline follows from which components are in scope, how many identity sources must be federated and how much data must migrate. A campus that needs only file sync and video teaching moves much faster than one that also replaces mail, chat, a learning platform integration and a student portal. Ask for a fixed-scope proposal that lists each component, each integration and each acceptance test, with a timeline tied to those items. Treat any single number offered before that document exists as a placeholder.

What factors make a campus rollout take longer?

Timing is driven mostly by decisions and dependencies outside the build itself. The main drivers are:

Identity federation with the campus directory, which depends on attribute mapping and the directory owner's availability
Data migration from existing file shares, mail archives and learning tools, especially where retention rules apply
Sizing and hardware procurement for term-time peaks, including lead times for servers or Kubernetes capacity
Approval of the data protection impact assessment and records of processing, which the registrar and legal office must sign off
The number of user groups trained and moved in waves

Identifying these early and scheduling them in the written scope usually matters more than the technical installation.

How much time do registrar staff need during a deployment?

Registrar staff are needed mainly to define which records are education records and who may access them, and to approve the access model. Expect time for workshops on legitimate educational interests, review of how student records are handled in file and mail workloads, and sign-off on disclosure logging. The FERPA regulation requires institutions to record access and disclosure requests and to keep school official access limited to legitimate educational interests, so these decisions need documented owners. Ask the implementation partner to list the registrar decisions and the meeting count in the scope before work starts.

What does the IT team need to commit to a campus deployment?

The IT team owns the hosting platform, the identity integration, network reachability and day-two operations. Core tasks include providing the Kubernetes or server platform, opening the required network ports for video conferencing, supplying TLS hostnames, connecting the directory and running backup and restore tests. Staff with Kubernetes, directory and mail administration skills will be needed for the build and then for upgrades, which for openDesk arrive as monthly minor releases. Ask the partner to name which tasks transfer to your team and which remain under a support retainer, and to confirm the skills each handover requires.

How much faculty time does a teaching platform rollout require?

Faculty time is concentrated in pilot testing, LMS integration checks and training before term starts. Teachers need to test virtual classroom features such as breakout rooms, shared notes, polling and recordings, and confirm that course embedding works in their learning management system. The time depends on how many course designs are affected and how often recordings are used. Ask for the test scripts and acceptance criteria in the scope, and schedule faculty testing outside the weeks when grading and course starts peak.

Does a campus need a pilot before the full rollout?

A pilot is not a legal requirement, but it is the most reliable way to test identity federation, sizing and support load before the whole campus depends on the platform. A common approach is to pilot with one faculty or a set of administrative users, then move students in waves outside peak term periods. Whether a pilot is needed depends on the number of user groups, the directory complexity and the tolerance for disruption during teaching. Ask the partner to define the pilot exit criteria in writing and to show how the pilot results will change the production scope.

Can the university's own IT team run the deployment without a partner?

A capable in-house team can build parts of a deployment, but the usual gaps are security hardening, identity federation, load testing for term-time peaks and evidence for compliance reviews. Decide which tasks your team owns, which go to a partner under fixed scope and which move to an ongoing support arrangement. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms inside the client's own infrastructure, and most engagements are fixed-scope, with the scope and timeline agreed in writing before work starts. Ask any partner to show who staffs each task and what remains with your team after handover.

What should a written scope include to set a realistic schedule?

A written scope should list the components, identity sources, integrations, data migrations, sizing assumptions and acceptance tests, with named owners for each. It should also state the staff time expected from the registrar, IT and faculty, the training sessions and the pilot exit criteria. Ask for milestones that tie payment and sign-off to delivered items rather than calendar dates alone. If a proposal omits any of these, request it before comparing prices or timelines across vendors.

How DeployOpen scopes, builds and supports education workplaces

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the institution's own cloud accounts, data centers or air-gapped networks. For a university or school authority, that means the workplace runs under the institution's control, with the identity, teaching tools and evidence it needs for FERPA and other education obligations.

How we scope

Engagements are fixed-scope, with components, user groups and deliverables agreed in writing before work starts.
The written scope names which staff, student and teaching workloads move, and which stay on existing systems during transition.
We confirm term-time peak load, expected recording volume and the campus network conditions that BigBlueButton or Jitsi will face.

How we build

We deploy files, office, chat, video and wiki components in your environment, wired to one campus identity provider.
We size and test video and file services against the peak concurrency and recording needs captured during scoping.
We configure access controls and audit logging so school officials see only the education records their role requires.

How we hand over

Handover includes architecture, configuration and runbook documentation for each component, written for your own administrators.
We prepare compliance evidence such as access reviews, retention settings and disclosure logging for your auditors to assess.
Backup, restore and upgrade procedures are rehearsed with your operations team before the workplace opens to students.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after the initial handover.
Upgrade planning follows each component's release cadence, with test environments used before term-time changes.
Security testing covers applications, APIs and infrastructure, and can be repeated as new services or integrations are added.