Scaling a self-hosted course platform to large learner numbers

A platform engineer owns the cluster that runs Open edX or Moodle, including node pools, the control plane, etcd, ingress, autoscaling and upgrades. Kubernetes releases come about three times a year on a cycle of roughly 14 weeks, and the project supports only the three most recent minor releases, so upgrades are recurring work, not a one-time task. The engineer also owns etcd backups using etcdctl snapshot save, restore drills, and the control plane topology chosen at build time. Confirm with your partner which of these are included in the fixed-scope build and which move to an ongoing retainer. The Kubernetes release cycle page explains the cadence your team must plan around.

An LMS administrator manages course catalogs, enrollment rules, instructor accounts, course cloning for new cohorts, certificate settings and the learner-facing configuration of the platform. This work is recurring and grows with each launch, since every cohort needs its own dates, access windows and enrollment logic. One-time work includes writing the enrollment and naming conventions, training instructors and building the cohort checklist. Ask your partner to document these procedures during the rollout so the role can be filled by a trained staff member instead of the original build team. Staffing levels depend on catalog size and launch frequency, which you should set against your own plan.

A release manager tracks which Open edX or Moodle release is in use, when it stops receiving support, and when upgrades must happen. Open edX supports only its latest named release and cannot support more than one at a time, so staying on an old release leaves the platform without a supported path. Moodle publishes long-term support releases with separate bug fix and security fix end dates, and Moodle 5.3 requires PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. The release manager schedules test upgrades in a staging environment, coordinates Kubernetes patch windows and keeps a dated record of every change. This is recurring work for the life of the platform.

A security engineer controls how secrets and administrator access are stored, rotated and reviewed. Kubernetes stores Secrets unencrypted in etcd by default, so the engineer must confirm encryption at rest is enabled, restrict list and watch access with least-privilege RBAC, and decide whether an external store is used through the Secrets Store CSI Driver. Access reviews of cluster roles, LMS staff accounts and identity provider connections are recurring. Setup of the identity provider, such as SAML 2.0 or LDAP, is usually one-time, while reviews and rotation continue indefinitely. Confirm the review frequency and the evidence format your compliance team needs before the build starts.

A support lead runs the queue of learner questions, from login and enrollment problems to video playback and certificate requests, and sets the escalation path to the platform engineers. Cohort starts concentrate tickets into a short window, so the lead needs a rota, a published help page, and canned responses prepared before launch. Ticket volume depends on learner numbers, course design and how clearly access rules are explained, so ask your partner for a load test result and a support playbook before setting staffing. The recurring part is the queue and the knowledge base. The one-time part is the playbook and the escalation contacts.

Your team can run the platform if it has the skills for Kubernetes operations, database administration, LMS configuration and security review, and if the runbooks are written and tested. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and ongoing support, upgrades and continuous testing are available as retainers. Most engagements are fixed-scope, so the handover, runbooks and training should be written into the scope. Ask any partner which roles it will cover, which the client keeps, and how responsibilities split during an incident.

One-time work includes the initial cluster design, the first load test, the identity integration, the runbooks, and the training of staff. Recurring work includes Kubernetes and LMS upgrades, etcd backup checks, secret rotation, access reviews, cohort setup and learner support. Recurring costs are driven by how often you launch, how many releases you track, and how many people you need on call. Ask any quote to separate build effort from ongoing operations so you can compare the two over the life of the platform.

The cost is driven mainly by scope, cluster design, video volume, integrations and the depth of load testing. A platform for a few thousand learners needs a smaller cluster, fewer managed database replicas and lighter testing than one expecting tens of thousands of concurrent learners during a launch. Video volume adds CDN and storage spend that grows with hours published and viewers reached. Each integration with a identity provider, payment system or student records system adds build and test effort. Ask every quote to split one-time work (architecture, build, migration, load testing, training) from recurring costs (cloud infrastructure, CDN traffic, backups, monitoring, support). Also ask who pays cloud accounts and third-party licenses directly, since that changes what the quote includes.

No timeline can be set until the scope is written, because duration depends on the cluster design, the number of integrations, the video pipeline and how many named releases must be upgraded before launch. Treat the published release calendars as planning inputs rather than fixed deadlines. For Open edX, the latest named release is the only supported one, and Verawood is the current release, with Willow listed for December 2026 and Xylon for June 2027. For Moodle, the 5.3 release is the current long-term support line, with security support until 1 October 2029. Ask the partner to lay out a schedule that includes a load test window and a freeze before the launch date, and to name the milestones that need your sign-off.

Some teams can, but running a large course platform is an operating job, not a one-time installation. The maintainers of edx-platform recommend running Open edX in production through a service provider or with Tutor, and note that bare-metal installation is complex and receives limited community support. A capable operating team usually covers Kubernetes cluster administration, database and cache tuning, backups and restores, security patching, release upgrades, CDN and video configuration, and incident response. Assess your team against each of these areas. Gaps in any of them are worth naming in the quote so the engagement can cover training, runbooks or ongoing support.

The implementation team needs a clear learner profile, a launch date, access and decision owners before work can be scoped accurately. Provide expected peak concurrency, enrollment volume by month, course catalog size and video hours, plus any region or language requirements. Grant access to cloud accounts or data center networks, identity provider metadata, DNS, certificate authorities and payment or student information system contacts. Name one business owner who signs off on scope changes and one technical owner for security decisions. Delays usually come from missing access or unresolved decisions rather than from the engineering work itself, so confirm these items in writing at kickoff.

Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. The written scope should list the platform components, environments, integrations, load test targets, documentation, handover sessions and acceptance criteria. Each deliverable should name what the client must provide and what happens if a dependency slips, including how changes to scope are priced and approved. Ask for the acceptance process, the test evidence delivered at each milestone and the terms for the launch freeze. A fixed scope protects both sides only if the boundaries are explicit, so review exclusions such as content migration, custom theme work or third-party video contracts.

Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope implementation. A retainer typically covers patching, monitoring response, backup verification, release upgrades and periodic load retesting before major enrollment events. Confirm in the quote what response coverage applies, which hours are included, how named release upgrades are scheduled, and how urgent incidents are escalated. Ask whether the retainer includes Kubernetes control plane maintenance, etcd backups and restore drills, and CDN configuration changes. Because DeployOpen does not publish a price list, request a quote built from the written support scope.

Upgrade effort depends on which release you run and how far it is behind. For Moodle, sites must be on version 4.4 or later to upgrade to 5.3, and the document root must point to the /public directory from Moodle 5.1 onward. For Open edX, only the latest named release is supported, so each upgrade is a planned migration. Kubernetes adds its own cycle, with three minor versions maintained at a time, and kube-apiserver must be upgraded one minor version at a time. Ask the partner how they test upgrades in a staging environment that mirrors production, how long they reserve for each cycle in the quote and how rollback is handled if a migration fails.

Compare quotes on the same written scope, not on headline totals. Check that each one itemizes architecture and design, cluster build, database and cache configuration, video delivery, integrations, load testing with stated targets, security hardening, documentation, training and handover. Confirm who holds cloud accounts, licenses and domain names, and what happens to those assets at the end of the engagement. Ask for the assumptions behind any effort estimate, such as expected concurrency and number of integrations. Quotes that leave these items out are harder to compare and tend to produce change requests later.