LMS in air-gapped networks

The assessor typically asks for proof of what was installed, how it got across the boundary, what plugins and versions run, where training records live, and how changes were made over time. Each item maps to a component of the platform. DeployOpen prepares this evidence inside your environment, but it does not issue audit reports or certifications. Independent auditors and certification bodies make that determination, and the assessor's specific request list should be confirmed with them before the review starts.

The install bill of materials is the list of every package, container image, language dependency, plugin and content file staged for the isolated network, with its version and cryptographic hash. It shows the assessor exactly what was installed and lets them confirm that nothing was altered after it was verified. Keep it under change control alongside the signed release packages from the platform vendor. Confirm with your assessor how they expect hashes to be recorded and which signing keys they will accept.

Transfer logs record each import into the isolated network: the date, the media or transfer method, the operator, the files moved, and the hash check result before and after. Each import should be a separate entry so the assessor can trace any plugin or content item back to a specific transfer. Store the logs inside the boundary or in a controlled system, and confirm with your security team how media handling and scanning steps are documented. The Wazuh and Security Onion airgap guides describe offline update processes that can feed these records.

Keep a current inventory of every Moodle core component and third-party plugin, with the installed version, source, license, and the date it was approved and installed. Version history should show each upgrade and rollback. Moodle plugins can change behavior across core releases, so the inventory must match the core version in use. Moodle core already ships several authentication plugins, which should be listed as enabled or disabled. Confirm with your change board how unapproved plugins are detected and removed.

Completion records, assessment results, enrollment history, and acknowledgments of policy or security training must be retained within the isolated network under the retention rules your program requires. Records should include learner identity, course version, completion date, and the assessor or system that recorded it. Confirm the retention period with your compliance lead and the applicable standard, since it varies by program. Export or reporting processes should also be logged so the assessor can see who accessed the data and when.

Each upgrade should have a change record covering the target version, the reason, the approval, the test results in a staging environment, the rollback plan, and the post-upgrade verification. Moodle publishes its release support windows and minimum requirements for PHP and database versions in its release notes, so the record should show that prerequisites were checked before the transfer. Upgrade media should pass through the same import and hash steps as the original install. Confirm with your change board how long records are kept and who signs off.

Yes, many organizations assemble this evidence with their own staff, provided they have a clear owner for each record and a process that captures it at the time of each change. The work usually splits into a one-time setup, such as the baseline bill of materials and logging design, and a recurring effort, such as logging each import and upgrade. DeployOpen can plan the evidence model, configure the records, and document the procedures under a fixed written scope, and it can run ongoing support under a retainer. Ask any partner to show a sample record set before agreeing on scope.

Ask which records the partner will produce, in what format, and where they will be stored after handover. Confirm who keeps the signing keys, how hashes are generated and verified, and whether transfer logs can be audited independently. Ask how plugin and upgrade records link back to the bill of materials, and how the partner handles evidence gaps found during testing. Request the scope in writing, including which items are the partner's responsibility and which remain with your team or your assessor.

Moodle is licensed under GPL-3.0, so there is no license fee for the core platform, but an air-gapped deployment still has costs. You pay for the hardware or cloud capacity inside the boundary, the staff or partner time to install and configure it, the plugins and themes you select, and the upkeep that follows. Those costs are one-time for the build and recurring for hosting, patching and support. Ask any partner for a written scope that separates setup, content migration, plugin vetting, upgrades and support so you can compare quotes line by line. DeployOpen does not publish a price list, and a quote follows from that written scope.

The biggest effort drivers are how many components must be moved across the boundary and how many of them depend on outside services. Expect the work to grow with:

• The number of plugins, themes and LTI tools, since each needs a vetted offline copy and a test cycle.
• Identity integration with an internal directory, such as LDAP or SAML2, which must be tested without external calls.
• Video and SCORM content that must be served locally rather than from a public host.
• Database, PHP and web server prerequisites that must be mirrored internally.

The more of these you have on day one, the more setup and testing you should plan for in the written scope.

The timeline depends mostly on accreditation and boundary review, not on the install itself. Before any system goes live, many defense and critical sites require a security authorization, a boundary review and sign-off on how software enters the network. Those steps can run in parallel with build work, but they often set the critical path. Ask for a schedule that names each approval gate, who owns it and what evidence it needs. A written scope should state durations only where they are agreed, and any timeline you receive should be tied to your authorization calendar rather than to a generic install estimate.

A partner cannot complete an offline deployment alone. Your side typically supplies:

• Named staff who can approve access, accept the boundary design and sign off on test results.
• The identity source, with directory schema, group structure and the authentication method the network already uses.
• A documented transfer procedure for moving installers, plugin updates and content across the gap, including who scans and approves each import.
• Hardware or virtual capacity inside the boundary, and access to your change process.

Confirm each item in the written scope, because gaps here are a common reason for delay.

Some organizations do, provided they have skilled Linux, PHP, database and web server administrators, a tested offline update path and a clear owner for security patches. The Moodle 5.1 release notes require 64-bit PHP 8.2 or later and specify database versions, and the web server document root must point to the new /public directory. Upgrades must start from supported versions, so your team needs to track release dates closely. Decide early which tasks stay in-house, such as daily operations, and which you outsource, such as major upgrades, plugin validation and boundary documentation. Put that split in writing before procurement.

A retainer covers recurring work after go-live, such as applying point releases, validating plugins against a new core version, rehearsing offline upgrades and keeping documentation current. Moodle ships minor point releases every two months and major releases every six months, and Moodle 5.3 is the next long-term support release with security fixes until October 1, 2029, as stated in the Moodle releases page. Because each transfer across the gap needs verification, ask whether the retainer includes checking every package and documenting the chain of custody. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and the exact scope is set in writing.

Recurring costs usually include infrastructure inside the boundary, staff time for administration, the upgrade cycle, plugin and theme maintenance, backup testing and any vendor support subscriptions you choose to keep. Security software that updates from offline media may also need periodic staff time. The NERC CIP-013-2 standard requires supply chain procurement processes to address verification of software integrity and authenticity of vendor software and patches, so budget time for those checks each time you bring updates in. Ask any partner to itemize these recurring items in the quote so you can see what continues after the one-time build ends.

Not for Moodle or Open edX, which are open source and can be self-hosted without an edition fee. Other tools in a learning stack often treat air-gapped deployment as a paid feature. For example, Mattermost lists air-gapped deployment in its Enterprise Advanced plan, and Rocket.Chat excludes it from its free Starter plan. Check every adjacent tool, such as chat, analytics or video, against its vendor pricing page before you commit to an architecture, because an LMS that works offline can still be blocked by a companion product that does not.