Why a self-hosted course platform for government training is different
If your agency must deliver training to citizens or staff on a platform it controls, Open edX fits open public courses and Moodle fits staff training and mixed audiences, and both can run inside government infrastructure. The harder decisions, though, are not which software you pick. Learner records, government login and the accessibility deadlines under ADA Title II change the build far more than the choice between the two platforms. Plan those requirements first, then select the platform that meets them.
Accessibility is the first constraint to size. The DOJ rule under ADA Title II requires state and local government web content and mobile apps, including content delivered through contracts or licenses, to meet WCAG 2.1 Level AA. Compliance dates are April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities and special districts. A course platform bought from a vendor or built by a partner is still your public content, so confirm in writing who tests the themes, custom plugins and video players against WCAG before launch. Also confirm which authoring and player components your staff will use, because those are where accessibility gaps usually appear.
Identity is the second. Open edX third-party authentication supports SAML 2.0, Shibboleth, OAuth2 and LTI, while Moodle core ships Shibboleth, LDAP, OAuth 2 and LTI authentication plugins. Map your government login protocol to one of these early, and decide which role attributes drive instructor, staff and public learner access. Learner records also need an owner. Confirm with your records office how completion and transcript data is retained and who can export it. DeployOpen prepares controls and evidence for compliance assessments but does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments.
Which rules shape a public sector course platform
This table compares the rules most likely to shape a government or public training platform, from accessibility deadlines to security baselines and EU directives. Read each row for what it changes in the build, then confirm applicability with your counsel and assessors, since scope depends on your entity type, data and jurisdiction.
| Rule | What it means for the build | Confirm with |
|---|---|---|
| ADA Title II web and mobile rule (WCAG 2.1 AA) | State and local government web content and mobile apps must meet WCAG 2.1 Level AA. Entities serving 50,000 or more people face an April 26, 2027 date, and smaller entities and special districts face April 26, 2028. Course content, LMS theme and any contracted hosting count. | Agency counsel and an accessibility auditor |
| NIST SP 800-53 Rev. 5 baselines | SP 800-53B selects 149 controls for a low baseline, 287 for moderate and 370 for high. Agencies often map a training system to a baseline by data sensitivity, so the baseline choice drives logging, access control and hardening scope. | Agency security office and authorizing official |
| FISMA context | Under FISMA, Inspectors General independently assess agency system security and report to OMB. Expect the platform to appear in system inventories and to need a documented authorization package and continuous monitoring evidence. | Agency CISO and Inspector General liaison |
| FedRAMP scope for cloud hosting | FedRAMP covers cloud products that process federal information on behalf of an agency. A self-hosted platform run only for one agency on its own cloud account may fall outside scope, but a shared or vendor-run service usually does not. | Agency authorizing official and FedRAMP PMO guidance |
| CJIS Security Policy v6.1 | If criminal justice information appears in training records, such as case details in law enforcement modules, v6.1 (effective June 26, 2026) requires FIPS 140-3 validated modules or AES-256 for data in transit and at rest outside secure locations, and vulnerability scanning at least monthly. | CJIS Systems Officer and state DOJ |
| NIS2 for EU public administration | NIS2 covers central government entities regardless of size and lists public administration as high criticality, with member states able to extend it to local bodies. It excludes entities working in national security, defense, public security or law enforcement, so the exclusion must be checked per program. | National NIS2 authority and legal counsel |
| Controlled unclassified information (NIST SP 800-171) | When a federal agency sets requirements for CUI on non-federal systems, NIST SP 800-171 is the default safeguard set unless the CUI category specifies otherwise. Contractor-run training for agencies may inherit these requirements. | Contracting officer and agency security office |
Open edX or Moodle: which fits which government training
Open edX suits agencies publishing open courses to the public, where the learner base is large, external and mostly unauthenticated or self-registered. The platform is licensed under AGPL-3.0, which governs how modified versions are distributed and made available over a network, so legal review should happen before any custom code is written. Deployment is usually handled with Tutor, the official Docker-based distribution, which also supports Kubernetes and plugins. Bare-metal installation is discouraged by the maintainers, so plan for container operations from the start.
- Release policy: Only the latest named release is supported. Verawood, published on 30 July 2026, is the current release, and Willow (December 2026) and Xylon (June 2027) are planned.
- Deployment model: Tutor on Docker for smaller estates, with Kubernetes for higher availability and scale.
- Authentication: OAuth2 providers, SAML 2.0, Shibboleth and LTI are supported for third-party login.
- Analytics: Aspects captures xAPI statements and presents them in Superset dashboards, which needs its own hosting plan.
- Dependencies: Development requires Python 3.12, MySQL 8.0, MongoDB 7.x and Memcached, and multi-node deployments need a shared cache such as Redis or Memcached.
Confirm with the vendor and your implementation partner which production database and cache versions the chosen Tutor release expects, and who will perform upgrades each time a new named release ships.
Moodle fits agencies that mix staff training, mandatory compliance courses and some citizen-facing content on one system. Its code is licensed under GPL-3.0 and it is maintained by Moodle HQ, which also offers managed hosting through MoodleCloud and partners. Moodle's release model is more predictable for long-running estates because it publishes long-term support releases, which is the main reason many agencies with internal training needs prefer it.
- LTS track: Moodle 5.3 is the designated next long-term support release, with bug fixes until 4 October 2027 and security fixes until 1 October 2029.
- Core authentication: Manual accounts, email self-registration, external database, LDAP, LTI, OAuth 2, Shibboleth and web services ship in core.
- Database and PHP for 5.3: 64-bit PHP 8.3 or later (8.4 supported), PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later.
- Upgrade path: Sites must be on Moodle 4.4 or later to upgrade to 5.3.
- Document root: From Moodle 5.1, the web server must point to the /public directory.
Before committing, confirm the Moodle version your staff courses will use, the database engine your infrastructure team already supports, and whether the LDAP or Shibboleth configuration matches your directory setup.
Identity integration often decides between the two platforms more than course features do. Both platforms can connect to federated or directory-based sign-in, but the supported protocols and the maturity of each connector differ. Confirm the exact protocol your agency login service exposes, then test the chosen platform's connector against it before the platform is selected.
- Open edX options: OAuth2 providers, SAML 2.0, Shibboleth and LTI are supported, with older provisional support for CAS and SSL client certificates.
- Moodle options: LDAP, Shibboleth and OAuth 2 are core plugins, and a SAML2 single sign-on plugin is available from the Moodle marketplace as a third-party addition.
- Plugin review: Any marketplace plugin adds a maintenance and security review obligation that should appear in the support scope.
- Attribute mapping: Learner and staff roles, department codes and training records must map consistently from the directory into the platform.
- Testing: Verify sign-out, session timeouts and account deprovisioning, not only sign-in.
Ask your identity team which protocol and attribute schema they will provide, and ask the implementation partner to show a working test of that exact connection.
Canvas LMS by Instructure is licensed under AGPL-3.0, the same license family as Open edX. It is a serious learning platform, but its fit for government training depends on factors that have to be verified for your situation rather than assumed from its license. Treat it as a candidate to evaluate, not a default choice, and check the points below before adding it to a shortlist.
- License review: AGPL-3.0 obligations apply to any modified version offered over a network, so confirm your legal position with counsel.
- Hosting model: Confirm how the self-hosted distribution is supported, updated and operated, and what the support path is for a government estate.
- Standards and integrations: Check LTI, SSO and reporting needs against your agency's systems.
- Accessibility: Request the vendor's current accessibility documentation and test it against WCAG 2.1 Level AA.
- Operating skills: Confirm your team or partner has the skills to run the platform's technology stack.
Ask for a written statement of what the self-hosted edition includes, who maintains it, and how security fixes reach your environment.
Deployment patterns inside government infrastructure
An agency's deployment pattern decides which security controls, approvals and evidence apply before a learner ever logs in. The cards below cover the common hosting options for Open edX or Moodle, the shared services they depend on, and the separation the agency should expect from its other systems.
Agency data center
The platform runs on hardware and virtual machines the agency already operates, under its own change control, physical access rules and network segmentation. This keeps learner records inside the agency boundary, but the agency carries patching, backup and capacity work that a managed provider would otherwise handle. Confirm with the security office which control baseline applies to a learning system holding staff and citizen identities, and who signs the authorization to operate.
Government private cloud
A government-operated private cloud can host Tutor on Kubernetes or a Moodle cluster while the agency keeps administrative control of the tenant. The main decisions are which cluster services are shared with other agency workloads and where backups are stored. Confirm with the security office whether the private cloud already holds a current authorization that covers an education application, and which logging and key management services it provides.
Air-gapped network with mirrored images
On a disconnected network, container images, Python packages, Node packages and plugin archives are copied in through an approved transfer process before installation. Every upgrade then needs a fresh import, and vulnerability scanning must run on the mirrored content. Confirm with the security office how software is accepted into the enclave, who approves each transfer, and how scan results are retained as evidence.
Shared cache and session tier
A multi-node Open edX deployment needs a shared Django cache backend, such as Redis or Memcached, so that all application nodes see the same sessions and cached data. The cache holds session state, so it belongs in the same security boundary as the learning platform. Confirm with the security office whether the cache may run on a shared service, how it is encrypted in transit, and whether its memory contents count as learner data for retention purposes.
Cloud account and FedRAMP scope
If the agency runs the platform in its own cloud account for a single agency use, FedRAMP scope generally does not apply because the service is not offered as a shared service. Scope changes if a vendor or hosting provider runs the same platform for multiple agencies. Confirm with the security office and the contracting officer whether the hosting arrangement makes the service a cloud offering for federal information, and document the answer before procurement.
Separated learner records
Learner records, course completions and certificates should sit in a dedicated database and identity scope, not in the agency's HR, case management or citizen service systems. Integrations should pass only the fields a course needs, through a documented interface. Confirm with the security office which records the agency treats as personal data, which systems may query them, and how long completion data is kept.
How government login and accessibility work in the build
Government login is the first integration decision, and it should be designed before anyone configures a login button. Open edX third-party authentication supports SAML 2.0, Shibboleth, LTI and OAuth2 providers, with older provisional support for CAS and SSL client certificates. Moodle core ships LDAP, LTI, OAuth 2 and Shibboleth authentication, and the SAML2 authentication plugin on the Moodle marketplace covers agencies whose identity provider speaks SAML. Confirm with the agency's identity team which protocol their identity provider supports, which attributes it releases (for example, a stable learner identifier, email and an organizational unit), and whether a test identity provider is available in a non-production environment. Map those attributes to learner profiles and decide, in writing, which attribute is the account key, because changing it later breaks enrollments and certificates.
Deprovisioning needs the same care. A public servant who changes department or leaves the agency should lose access to training records they should not keep, and a citizen account should follow the agency's retention rules rather than live forever in the LMS. Agree with the identity team how disabled accounts are detected, whether through just-in-time login checks, scheduled synchronization or a provisioning feed, and what happens to completed course records and certificates when an account closes. Test a disabled account against a live session before launch. Accessibility is the second half of the build. The ADA Title II rule requires state and local government web content and mobile apps, including those provided through contracts or licenses, to meet WCAG 2.1 Level A and AA, with compliance dates of 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts. Theme templates, login pages and the instructor dashboard are the platform's responsibility, but uploaded course videos, PDFs and interactive exercises are usually authored by the agency's course teams. Scope in writing who fixes which layer, and who runs the accessibility testing and keeps the evidence.
How a public sector course platform rollout runs
The sequence turns a training requirement into a hosted, hardened and supported Open edX or Moodle platform inside the agency's own infrastructure, with each phase closing on a written output the agency can approve before the next phase begins.
Scope the platform and review legal applicability
The agency and DeployOpen agree the audiences (citizens, public servants, open courses), the platform choice between Open edX and Moodle, and the hosting boundary. Legal and compliance owners confirm which regimes apply, such as the ADA Title II web rule, state records rules, CJIS-style data handling or NIS2 where the agency falls within scope. The output is a written scope with a list of applicable obligations and open questions. Ask for a fixed-scope schedule and deliverables before work starts.
Classify identity and data
The team maps every learner and staff population, the identity source each one uses, and the categories of data the platform will hold, including training records, certificates and any personal or sensitive fields. It decides what stays out of the learning platform and which records must remain separate. The output is an identity and data classification register that the security and privacy owners sign off, which sets the controls used in later phases.
Design and harden the environment
DeployOpen designs the target environment inside the agency's cloud account, data center or isolated network, covering network zones, database and cache tiers, backups, logging and key management. Hardening follows the baseline the agency has selected, mapped to control IDs in NIST SP 800-53 where the agency uses it. The output is an architecture document and hardening standard, reviewed by the agency's security team before any production resources are created.
Build the platform with government login and theming
The team installs the chosen platform, configures the identity integration (SAML 2.0, Shibboleth, OAuth2, LDAP or LTI, depending on the agency's directory), and applies the agency's branding and course structures. Authentication is tested with real directory accounts in a non-production environment. The output is a working staging platform with a documented configuration and a list of any custom plugins, each with its own support owner.
Test accessibility against WCAG 2.1 AA
Accessibility testers check the theme, course templates and authoring workflows against WCAG 2.1 Level AA, combining automated scans with manual testing using assistive technology. Findings are logged by severity with fixes assigned to build owners, and content authors receive guidance on accessible course material. The output is an accessibility test report and a remediation log. Because the ADA Title II rule applies to content provided through contracts, the agency should confirm which deliverables it must cover.
Run security testing and vulnerability scanning
DeployOpen runs application and infrastructure security tests against staging, including authentication, authorization, session handling and exposed services, and sets up recurring vulnerability scanning. Critical and high findings are fixed and retested before go-live. The output is a test report, a scan schedule and a list of accepted risks signed by the agency. If the agency handles regulated data, it should confirm the scanning frequency and encryption requirements in its own governing policy.
Pilot with training owners and cut over to production
A small cohort of real learners and training owners runs a defined set of courses on staging or a pilot production instance. Feedback covers sign-in, course completion, certificates, reporting and support requests, and each issue is resolved or accepted before launch. The production cutover then moves configuration, data and DNS under a written rollback plan. The output is a signed pilot report and a cutover record showing the production environment is live and verified.
Hand over runbooks, upgrade plan and support
DeployOpen delivers operational runbooks for backups, restores, monitoring, incident response and identity changes, along with an upgrade plan tied to the platform's named release and support dates. The agency's operators are trained and the handover is recorded. Ongoing patching, upgrades and testing can be covered by a support retainer agreed in writing. The output is an accepted handover package and a support agreement that names who operates the platform after launch.
Evidence agencies and assessors ask for
This table maps each piece of evidence an agency or assessor typically requests to the platform component it comes from and the question it answers. Use it to plan evidence collection before an assessment starts, not after. DeployOpen prepares this evidence, but independent auditors, assessors and the agency's authorizing official make any determination.
| Evidence item | What it shows | Where it comes from and what to confirm |
|---|---|---|
| System security plan and control mapping | How each required control in the chosen SP 800-53 baseline is implemented for the course platform | Written with the agency's control baseline (low, moderate or high, which selects 149, 287 or 370 controls and enhancements). Confirm the baseline with the authorizing body first. |
| Encryption configuration | Which cryptographic modules protect learner and staff data in transit and at rest | Web server, database and backup settings. Where CJI may be present, confirm FIPS 140-3 validated modules or AES with 256-bit keys with the assessor. |
| Vulnerability scan reports | Scanning coverage of the OS, application stack, Open edX or Moodle core, and plugins | Scanner output retained by month. Confirm the scan frequency your policy requires, such as the monthly cadence in CJIS Security Policy v6.1 where it applies. |
| Accessibility test results | Conformance of learner-facing pages, course content tools and admin screens to WCAG 2.1 Level AA | Automated and manual test records, with a remediation log. Compliance deadlines under the ADA Title II rule depend on population size, so confirm your entity's date. |
| Identity configuration and access reviews | How government login is integrated and who holds instructor, staff and admin roles | SAML 2.0 or OAuth2 configuration exports, role assignments and periodic review sign-offs. Confirm which identity protocol your government login provider supports. |
| Upgrade and patch records | That the platform runs a supported release and that fixes were applied on schedule | Change tickets referencing the current Open edX named release or Moodle LTS line, with test results. Open edX supports only the latest named release, so plan upgrades early. |
| Backup and restore test logs | That backups exist and that restores have been tested on the platform's database and media stores | Dated restore test records covering the LMS database, course media and configuration. Confirm the recovery targets with the agency before testing. |
What agencies ask before hiring an implementation partner
What drives the cost of a government course platform?
Scope drives most of the cost: how many identity integrations are needed, how much accessibility remediation the existing course content and theme require, where the platform is hosted, and which support tier the agency chooses. Implementation work, such as installation, hosting setup, identity configuration, theming and data migration, is usually one-time. Hosting, patching, upgrades, monitoring and support recur every year. Ask any partner for a quote that separates these lines, names who pays for each cloud or data center resource, and states what is excluded. DeployOpen does not publish a price list, and a quote follows from written scope.
How long does a government course platform rollout take?
The timeline depends on scope, not on a fixed template. The main variables are the number of identity sources to connect, the number of courses to migrate or author, the accessibility work needed before launch, and the approval cycles inside the agency's security and procurement processes. Approval steps often take longer than the technical build, so agencies should plan for them early. Ask the partner for a written schedule tied to named milestones, and confirm which dependencies sit with the agency rather than the partner.
What does the agency's team need to provide?
The agency needs to provide three groups of people. Identity owners must supply the government login details, attribute mappings and test accounts for the identity provider. Training content owners must approve course material, subject matter accuracy and accessibility sign-off for their courses. Security and risk approvers must review the hosting design, access model, data classification and any control evidence before go-live. Confirm early who holds each role, how decisions are recorded, and how quickly approvals can be given, because these steps usually set the pace of the project.
Can the agency run an Open edX or Moodle platform without a partner?
An agency with an in-house platform team can run either platform, but the operating load is real. The Open edX maintainers recommend running production through a service provider or with Tutor, and note that bare-metal installation is complex and receives limited community support. Moodle requires ongoing attention to PHP and database versions, web server configuration and plugin compatibility. Many agencies keep day-to-day operation in house and buy specific help for upgrades, security testing or incident response. Ask the partner which operating tasks are included, which stay with the agency, and what the handover looks like.
How does procurement work for an implementation partner?
Most DeployOpen engagements are fixed-scope. The scope, deliverables and timelines are agreed in writing before work starts, and DeployOpen does not publish a price list, so a quote follows from that written scope. Ongoing support, upgrades and continuous testing are available as retainers. Agencies should check that the agreement defines acceptance criteria, change control for scope additions, data handling terms, and who owns the hosted environment and its credentials at the end of the engagement. Procurement teams can compare proposals on these terms rather than on headline day rates.
How are upgrades handled on Moodle LTS or Open edX?
Upgrades follow each platform's release policy. Moodle 5.3 is the next long-term support release, with bug fixes until October 4, 2027 and security fixes until October 1, 2029, so agencies on it have a defined support window. Open edX supports only the latest named release, currently Verawood, with Willow planned for December 2026 and Xylon for June 2027. That means an Open edX site must move to each new named release on a schedule. Ask the partner how test environments, plugin compatibility checks, backups and rollback plans are handled for each upgrade, and who approves production changes.
What happens to learner records during a platform migration?
Learner records, enrollments, completion data and certificates should be exported, mapped and validated as a defined migration task, not copied informally. The agency should decide which records must be kept, how long they are retained, and who can access them after cutover. Plan a reconciliation step that compares record counts and sample transcripts between the old and new platforms, and keep the source data until the agency signs off. Confirm how certificate identifiers and course references will be preserved, since learners and employers may rely on them later.
Questions to ask an implementation partner for government training
Ask the partner to show, in writing, how every platform setting maps to the control baseline your agency has to meet before you sign. For a government training platform, that usually means the NIST SP 800-53 Rev. 5 control catalog and the baseline your authorizing official has selected under SP 800-53B. Request a control matrix that names the Open edX or Moodle component, the hosting layer and the owner of each control, and ask who keeps that matrix current after each named release. Ask also whether the partner has mapped controls before for a system like yours, and what evidence they hand over for each one. Confirm with your own compliance team whether FedRAMP, FISMA or state-level rules apply to the hosting provider, because the answer changes which cloud services are in scope.
Ask how encryption is handled for learner records and course data that the agency treats as sensitive. Ask whether the partner will use FIPS 140-3 validated modules for TLS termination, database encryption and backups, and where the cryptographic module certificates are recorded. Ask for the identity design in detail: which protocol connects the agency login to the platform (SAML 2.0 and Shibboleth are supported for Open edX, and Moodle core includes Shibboleth and OAuth 2 authentication plugins), how just-in-time account creation maps agency roles to course staff and learner roles, and how a departing employee's access is removed. Ask how the platform is tested against WCAG 2.1 Level AA before launch, which tools and manual checks are used, and whether the written scope includes remediation of defects found. Agencies covered by the ADA Title II rule should confirm the compliance date that applies to them.
Ask who operates the platform after go-live, in writing, with named responsibilities for patching, monitoring, backups, incident response and user support. Ask how named releases are upgraded: Open edX supports only the latest named release, while Moodle 5.3 is the current long-term support release with security fixes until October 1, 2029. Ask how the partner tests an upgrade in a staging environment before it reaches production, and whether that testing is part of the fixed scope or a separate retainer. Finally, ask what the written scope excludes, such as content migration, custom theming, accessibility audits by an independent assessor or the agency's own authorization paperwork, and ask for references the partner is permitted to disclose, along with whether they have delivered for public sector agencies. Treat any partner who cannot name an exclusion as a reason to ask further.
How to procure implementation and support
This sequence moves an agency from an internal requirements draft to a written, comparable scope with a partner who can host inside government infrastructure. Each step produces a document that the procurement team, security office and platform owner can review before any contract is signed.
Define requirements and compliance scope
The agency's security office, training owner, accessibility lead and records team agree which learner data, course content and staff records the platform will hold. They then decide which frameworks apply, such as the NIST SP 800-53 baseline the agency already uses, the ADA Title II web accessibility rule for public-facing courses, and any CJIS or CUI rules if criminal justice or controlled information is involved. The output is a one-page requirements document with a named owner for each decision. Confirm with your legal and records teams whether any dataset triggers stricter rules before you go further.
Choose Open edX or Moodle against the requirements
Map the requirements to the platform. Open edX suits open courses and modern authoring, while Moodle suits broad institutional use and a wide range of plugins and authentication options. Ask each candidate partner to justify the choice in writing, including which named release or LTS branch they would deploy. The output is a short decision record that the platform owner signs off on.
Shortlist partners able to host in agency infrastructure
Build a shortlist of implementation partners that can deploy into the agency's own cloud account, data center or air-gapped network, not only into a vendor-hosted environment. Ask each partner to describe its experience with the chosen platform, how it handles the named release cycle, and how it documents the environment for assessors. The output is a shortlist with written answers to the same questions, which makes responses comparable.
Request written scope with deliverables and acceptance criteria
Send the shortlisted partners the requirements document and ask for a written scope. It should list deliverables such as the installed platform, SSO integration, accessibility testing, backup and restore procedures, documentation and handover. Each deliverable needs acceptance criteria that the agency can test, for example a sign-in test against the government identity provider or an accessibility check against WCAG 2.1 Level AA. DeployOpen works on fixed scope agreed in writing before work starts, and a quote follows from that scope. The output is a scope document that all bidders can price against.
Compare support retainers for upgrades and security testing
Implementation is a one-time project, but the platform needs upgrades, patching and periodic security testing for as long as it runs. Ask each partner to price a support retainer separately, covering named release upgrades, security patches, backup verification and testing of applications and APIs. Confirm how the partner will move the agency between releases, since Open edX supports only its latest named release and Moodle LTS branches have fixed support windows. The output is a comparison of one-time and recurring costs under identical assumptions.
Confirm data residency and personnel clearance needs
Before award, confirm in writing where learner data, backups and logs will be stored and processed, and which staff at the partner may access them. If the course data falls under a federal or state regime, ask whether the partner's personnel need background checks or clearances and how those requirements will be met. Also confirm that the hosting arrangement satisfies the agency's cloud authorization rules, since cloud services that hold federal information may require FedRAMP authorization. The output is a signed data handling statement that legal and the security office accept.
Award the contract and record the procurement file
Select the partner whose written scope, support terms and data handling answers meet the requirements at the lowest total cost of ownership the agency can verify. Record the scope, quote, acceptance criteria and data handling statement in the procurement file so that auditors can trace each decision. The output is a signed agreement and a complete file that the agency can present at its next assessment.
How DeployOpen scopes and supports public sector course platforms
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a government training program, that means the Open edX or Moodle platform runs in the agency's cloud account, data center or air-gapped network, not in a vendor's shared tenancy. Most engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts. For a public sector buyer, that written scope is the document to take to security, procurement and legal reviewers, so it should name the hosting environment, the login integration with the agency's identity provider, the accessibility work and the handover of operating runbooks.
Two scoping decisions tend to shape the work most. The first is whether the platform needs security testing before launch. DeployOpen runs application and API testing, cloud and infrastructure testing, AI and agent testing, red teaming and private cyber ranges, and these can be scoped as separate work from the build. The second is who maintains the platform after go-live. Upgrades to named Open edX or Moodle releases, and continuous testing, can be covered by retainers, which recur and should be priced separately from the one-time implementation. Ask for the upgrade path, the security patch cadence and the responsibilities for each side in the retainer terms before signing.
DeployOpen prepares systems, controls and evidence for compliance assessments, such as configuration records, access reviews, backup test logs and accessibility test results. It does not issue audit reports, attestations or certifications. Those come from independent auditors, certification bodies or, where applicable, the authorizing official. Confirm early which assessor the agency will use, what evidence that assessor expects and which controls the platform inherits from the hosting environment, so the evidence package is scoped to match.
