What running Open edX costs
Open edX has no license fee to pay. The edx-platform code is licensed under the GNU Affero General Public License version 3, so the recurring cost of running it is the people, infrastructure and upgrade work needed to keep it available, secure and current. Budget for that work from the first year, because it does not stop after go-live.
The work usually starts from a trigger: a new LMS for a new learner population, a move off an older or hand-built install, a named release that has gone out of support, or a renewal decision on an existing hosting arrangement. Open edX states that only the latest named release is supported, so a platform that falls behind must be upgraded before the next fix path is open. Ask your team how many named releases you have run in the last three years and how long each upgrade took.
Most teams that run Open edX keep some work in-house and hand off the rest. Typical splits are an in-house owner for content, learners and configuration, with infrastructure operations, upgrades and deep plugin work sometimes outsourced to a provider. Confirm which roles you can staff for on-call, database operations and release testing before you decide the split.
The edx-platform maintainers recommend running Open edX in production through a service provider or with Tutor, the official Docker-based distribution. They note that bare-metal installation is complex and receives limited community support. A quote should state which hosting model it assumes, who owns the upgrade calendar and who responds when a release is out of support.
What a cost of ownership study covers
A cost of ownership study produces a model you can change, not a price list. Each deliverable below is a document or spreadsheet your team keeps after the study ends.
Component inventory
A list of every running part of your Open edX estate: the LMS, Studio, MySQL 8.0, MongoDB 7.x, Memcached or Redis for shared caching, media storage, and Aspects analytics with ClickHouse and Superset if you use them. Each line records its host, its size assumptions and its backup target, so the cost model has a physical basis to attach numbers to.
Run-cost model by year
A year-by-year model of recurring infrastructure, database, storage, backup, monitoring and staff effort, with each input stated as an editable assumption. Ask for the drivers behind each line, such as learner counts, course volume and retention periods, so you can rerun the model when those change.
Upgrade calendar tied to releases
A calendar that maps your upgrade windows to named Open edX releases. Open edX supports only the latest named release, so the calendar shows when you must move, which of your custom components need retesting, and how much time each upgrade consumes in your environment. Verawood is the current release, with Willow and Xylon listed next.
Custom code and plugin register
A register of every XBlock, Tutor plugin, theme, frontend plugin slot change and custom API in your deployment, with its owner, its dependencies and a compatibility note for the release it targets. This register is what turns upgrade effort from an unknown into a countable workload.
Self-hosting versus provider comparison
A side-by-side comparison of running Open edX in your own infrastructure against a hosting or service provider. Each line carries a written basis, such as the staffing hours assumed, the hosting tier and the support scope, so you can see which numbers come from your own environment and which come from a quote. The edx-platform maintainers recommend running production through a service provider or with Tutor, which is a fact worth weighing in this comparison.
What drives the cost of ownership
This table lists the factors that move the running cost and effort of an Open edX deployment, why each one matters, and how to keep it under control.
| Driver | Why it moves cost | What keeps it down |
|---|---|---|
| Learner and concurrent user volume | Peak concurrent learners set the size of LMS web nodes, workers, database capacity and cache. Exam weeks and cohort launches often drive peaks well above daily averages. | Ask the provider to size from peak concurrency, not total enrollments. Load test before go-live and scale web and worker tiers separately. |
| Number of courses and media volume | Large course catalogs grow MongoDB content, Studio editing load and media storage. Video and file assets add storage and bandwidth costs that recur every month. | Set media standards and transcoding rules early. Archive or retire inactive courses and confirm where video is hosted. |
| Aspects analytics | Aspects adds ClickHouse, Superset and an event pipeline using Ralph or Vector. Each component needs its own compute, storage, backups, monitoring and upgrades. | Decide which reports are needed for course teams and administrators before enabling it. Start with a narrow set of dashboards and size storage from measured event volume. |
| Custom XBlocks, plugins and themes | Each custom block or plugin is code your team must test, upgrade and support across each named release. Custom code often costs more over time than the initial build. | Limit custom code to what the business requires. Use documented extension points such as Tutor plugins, frontend plugin slots and theme packages rather than forking the platform. |
| SSO connections | Each identity provider (SAML 2.0, Shibboleth, OAuth2 or LTI) adds configuration, attribute mapping, certificate renewal and testing. Account linking rules add support work. | Agree the number of identity providers and attribute contracts in the scope. Use the supported third-party authentication providers and document certificate renewal dates. |
| Environments (dev, staging, production) | Each environment repeats infrastructure, data refreshes and upgrade rehearsals. Staging must resemble production closely enough to catch release issues. | Use Tutor configuration and images to keep environments consistent. Ask whether staging can run smaller, and confirm what data is masked before copying. |
| Hosting model | A single Tutor host is the lowest fixed cost but has limited headroom. Tutor on Kubernetes adds cluster, ingress and storage operations. Managed or provider-run setups shift operations to a provider under a contract. | Match the model to measured peak load and team skills. Confirm which tasks the provider performs, which the client performs and how each is priced. |
| Compliance evidence needs | Assessors may ask for access logs, change records, backup restore tests, vulnerability management and data retention records. Producing this evidence is recurring work. | Define the evidence list in the scope. Automate log collection and restore tests where possible. DeployOpen prepares evidence for assessors but does not issue audit reports or certifications. |
How the cost model is built
The sequence turns a Open edX footprint into a comparable, dated cost model that a buyer can check against each option and each release.
Inventory the current or planned footprint
The team lists every Open edX environment, including LMS, Studio, analytics, sandboxes and any legacy installs, with learner volumes, course counts, custom XBlocks, plugins, themes and identity integrations. The output is a footprint register that names each component, its owner and its current release. The step is done when the buyer's platform owner confirms the register matches production.
Choose the hosting model and document components
The team compares Tutor on a single server, Tutor on Kubernetes and a managed provider, since the edx-platform maintainers recommend a provider or Tutor for production. Each option lists its components, such as MySQL 8.0, MongoDB 7.x, a shared cache, media storage, backups and Aspects services if analytics is in scope. The output is a hosting decision record with a component list for each option.
Estimate recurring labor by area
The team estimates recurring effort for platform operations, release upgrades, custom code maintenance, analytics operations and learner support. Each line states the task frequency the team expects and who is paid for the work, whether in-house staff or a partner retainer. The output is a labor sheet with one row per area and its assumptions written beside it, ready for quote comparison.
Compare self-hosting and provider options
The same footprint, labor sheet and cost categories run through each option, covering infrastructure, any licensed components, staffing and partner fees. One-time setup is kept apart from recurring operation for each option. The output is a side-by-side comparison built on identical assumptions, plus a list of costs each provider leaves out. Confirm every term in writing, because quotes follow from the written scope.
Review the model against the release calendar
The team maps the model to Open edX named releases. Verawood was published on 30 July 2026, and Willow and Xylon are listed for December 2026 and June 2027. Because only the latest named release is supported, the upgrade effort is planned for each cycle. The output is a dated upgrade calendar with labor adjusted for each release. Timing depends on the footprint and the buyer's decisions, and the written scope sets the schedule.
Where ownership estimates go wrong
Most underestimates come from a small set of planning gaps that appear after launch. Each card names one gap and the step that prevents it.
Sizing for launch day
Infrastructure is often priced for the first week of traffic instead of peak course enrollment, when many learners register, start courses and sit assessments at the same time. Ask for the expected concurrent learner peak for each course launch and exam window, and confirm the estimate includes load testing against that figure before hardware or cloud commitments are made.
Leaving out Studio and workers
Estimates often count only the learner-facing LMS servers. Studio, where course teams author content, and the background workers that run asynchronous tasks need their own capacity, and the MySQL, MongoDB, cache and media storage behind them must be sized for both. Ask the quote to list each service, its node count and the redundancy provided.
Upgrades as recurring events
Open edX supports only the latest named release and cannot support more than one at a time, so each move to a new release is a required event that repeats. Verawood is the current named release, and Willow and Xylon are listed for December 2026 and June 2027. Budget upgrade effort as a recurring cost, and ask whether the quote includes upgrade rehearsals and a rollback plan.
Testing custom code after release
Each release can change APIs and frontend behavior that custom XBlocks, plugins and themes depend on. Estimates often cover building custom code but leave out re-testing it after every release. Ask for an automated regression suite, a dedicated test environment and a per-release testing allowance written into the scope.
Analytics treated as optional
Aspects analytics is a separate pipeline: tracking logs pass through the event-routing-backends plugin as xAPI statements, are stored in ClickHouse via Ralph or Vector, and appear in Superset dashboards. Teams that defer it can find that early learning events were never stored. Decide reporting needs during scoping and include storage, retention and dashboard build in the estimate.
Provider support and custom code
A provider's support normally covers the platform as delivered and configured, not custom code the buyer owns. Custom XBlocks, plugins and theme changes stay with the owner unless the agreement says otherwise. Before signing, list each custom component in the scope and confirm who fixes it after each release and during an incident.
Recurring and one-time costs
This table separates one-time Open edX costs from recurring ones and shows which lines stay fixed and which grow with learner and course volume.
| Cost line | Timing | Scales with | Confirm before modeling |
|---|---|---|---|
| Initial build and data migration | One-time | Organizations, courses, learner records and source systems to move | Written scope covering tenants, theming, SSO, analytics and migration volumes |
| Custom XBlocks, plugins and theme | One-time build, then recurring rework | Number of custom components and frontend changes | Which custom code is needed at launch and which can wait |
| Security testing and hardening | One-time per release, repeated on a schedule | Scope of applications, APIs and admin access under test | Test scope, retest terms and who fixes findings |
| Hosting for LMS, Studio, MySQL 8.0, MongoDB 7.x, cache, media and backups | Recurring | Learner concurrency, node count, storage and backup retention | Node sizing, managed database options and backup retention with your hosting provider |
| Analytics infrastructure for Aspects (ClickHouse, Ralph or Vector, Superset) | Recurring | Volume of xAPI events and retained history | Event volume estimates and storage retention rules for your learner base |
| Upgrade projects per named release | Recurring, one project per release | Size of custom code and plugins that must be retested | Upgrade effort for the next named release, including custom code retests |
| Plugin and theme maintenance, monitoring and on-call | Recurring | Number of plugins, alerts and incidents per month | Response hours, alert coverage and who owns the pager |
| Internal platform and course-operations staff | Recurring | Fixed core team plus course volume and enrollment cycles | Roles you will keep in-house and roles a partner will cover |
| Platform license and paid support | No license fee under AGPL, support optional | Support tier and any hosted service selected | Any paid support from Edly for Tutor or hosted offerings, confirmed in writing before modeling |
How the cost changes by starting point
A new deployment on Tutor usually has the lowest setup cost because there is no legacy data or configuration to carry over. Most effort goes into designing the course and organization structure, theming, SSO and the hosting layout.
- Shrinks: migration and data mapping, since there is no prior platform to extract from.
- Grows: design and configuration time for organizations, roles and branding, which is built from scratch.
- Recurring: hosting, backups, and the upgrade work that follows each named release.
- Confirm with the platform owner: the expected number of courses and organizations, the identity provider to integrate, and whether analytics is in scope at launch.
- Confirm: who will own Tutor configuration and plugin changes after go-live.
Moving from an older or native (non-Tutor) install adds a migration track on top of the new build. The platform itself is the same codebase, but the server layout, configuration and data paths differ, so the cost depends on how far the current install has drifted from standard.
- Grows: assessment of the current install, data export and mapping, and a tested cutover plan.
- Grows: reconciliation of custom code, themes and settings that were applied by hand and must be rebuilt as Tutor plugins or configuration.
- Shrinks: long-term operating cost once the site is on Tutor, since the deployment is repeatable.
- Confirm with the platform owner: the exact release currently running, whether customizations are documented, and the volume of learner records and course content.
- Confirm: the acceptable downtime window and who signs off on the cutover.
A Kubernetes deployment with managed databases shifts cost from server administration toward cluster and service management. Infrastructure charges rise with the number of nodes and managed services, while some operations work is handed to the cloud provider.
- Grows: cluster setup, ingress, storage configuration and the knowledge needed to run them, which is a recurring platform cost.
- Grows: managed database and cache fees, which recur and scale with size and redundancy.
- Shrinks: manual patching and failover work for the databases, which the managed service typically covers.
- Confirm with the platform owner: which cloud or data center the cluster will run in, and whether the team already operates Kubernetes.
- Confirm: the backup and restore responsibilities split between the managed service and the operator.
A deployment that must run in an air-gapped or restricted network raises the cost of nearly every line. Packages, container images and updates must be moved in by approved means, and external services such as hosted identity or email relays may be unavailable.
- Grows: the build and verification effort for offline image and package delivery, and the process to repeat it at each upgrade.
- Grows: internal identity, mail, storage and monitoring services that would otherwise be external.
- Grows: documentation and evidence for change control and approvals inside the restricted zone.
- Confirm with the platform owner: the transfer process for software and updates, the network boundary rules, and which services are allowed inside it.
- Confirm: the expected update cadence, since each named release must be moved through the same controlled path.
An existing Open edX site that has fallen behind the latest named release carries an upgrade cost that grows with the gap. Open edX supports only the latest named release, so the site must move through intermediate changes before it can be supported again.
- Grows: the number of release steps, testing of custom XBlocks, plugins and themes against each target, and any data migrations those steps require.
- Grows: remediation of workarounds and forked code that no longer match upstream.
- Shrinks: future upgrade effort if the site returns to a regular cycle, since changes are smaller and more frequent.
- Confirm with the platform owner: the release currently running, the list of custom components, and whether a staging copy with production-like data is available.
- Confirm: the support status the organization needs during the upgrade period, and which team approves each step.
What the buyer needs to provide
A cost of ownership estimate for Open edX is only as good as the inventory behind it. Before a quote can separate one-time build work from recurring hosting and upgrade effort, the buyer needs to supply current hosting bills (or the cloud or data center cost model they use), a list of every server, database, cache, object store and analytics component in scope, and the current learner and course counts with a realistic growth expectation for the next two to three years. Confirm your own cloud or data center prices directly with your finance or infrastructure team, because DeployOpen does not publish prices and a quote follows from the written scope.
Next, list every custom XBlock, Tutor plugin, theme, frontend plugin and integration in use or planned, and name the owner of each. For each item, state whether the owner is internal, a contractor or a vendor, and whether the code is in a version-controlled repository. Add the SSO and LTI requirements: which identity providers must sign learners in (for example SAML 2.0, Shibboleth, or an OAuth2 provider such as Azure Active Directory), whether account linking or provisioning is expected, and which external tools need LTI launches or grade passback. These decide how much integration work is quoted and how much testing each upgrade will need.
Give the team the analytics requirements and the compliance frameworks that apply. Analytics needs cover which reports course teams and administrators must see, how long event data must be retained, and whether an Aspects stack (ClickHouse and Superset) will be hosted in the same environment. For compliance, name the frameworks and internal controls that govern the platform, since they affect logging, access reviews, backups and evidence collection. DeployOpen prepares systems and evidence for assessment, but independent auditors issue any report.
Finally, name the decision owners for three choices that change recurring cost: the hosting model, the release timing and the support level. Hosting model decides who operates the infrastructure. Release timing decides how often a named release upgrade is funded and tested, given that only the latest named release is supported. Support level decides who responds to incidents and how long they have to respond. Written decisions from these owners let a fixed-scope quote state its assumptions clearly and make later change requests easier to price.
Frequently asked questions
Does Open edX have a license cost?
No license fee applies to the platform itself, because edx-platform is licensed under the GNU Affero General Public License version 3. Your costs are operational: infrastructure for the LMS, Studio and any analytics services, the staff or partner who runs and upgrades the platform, and any custom development you commission. Check the license terms with counsel before you modify the code and offer it to users over a network, since the AGPL includes source-sharing obligations for modified versions.
Can our own team run Open edX in production?
Yes, but only with the right skills and a deliberate plan. Tutor is the official Docker-based distribution for production and local development, and it supports Kubernetes deployments. The edx-platform maintainers recommend running Open edX in production through a service provider or with Tutor, and they note that bare-metal installation is complex and receives limited community support. Your team needs working knowledge of Python, Django, MySQL, MongoDB, Memcached or Redis, Docker or Kubernetes, backups and release upgrades.
How long does an Open edX cost study take?
The duration depends on the footprint and the decisions behind it, so it is fixed in the written scope before work starts. The study usually covers expected learner volume, hosting model, custom code, analytics, single sign-on and the upgrade cadence you want to keep. Ask the provider which inputs they need from you, which they will confirm during discovery, and whether the output is a costed comparison of self-hosting and a service model.
What drives Open edX running costs the most?
Learner volume and the shape of load usually matter most, because they set the size of LMS, worker and database capacity and the high-availability design. Custom code comes next, since every XBlock, plugin and theme must be tested and kept compatible through each release. Analytics adds a separate data stack, and upgrade frequency sets how often that testing repeats. Ask for each driver to be costed separately so you can see which decisions move the total.
Are there paid Open edX editions or commercial tiers?
Confirm this in writing with Edly, the Open edX community and any provider you shortlist before you compare offers. Ask each party which features, support levels and hosting options are included in the open-source platform and which come from a paid service, contract or plugin. Edly maintains Tutor and offers professional support for it, so check whether that support is a separate agreement. Do not assume a feature is included simply because it appears in release notes.
What does a fixed-scope quote cover compared with ongoing support?
A fixed-scope quote covers a defined piece of work, such as an agreed build, migration or cost study, with deliverables and timelines written down before work starts. DeployOpen works on a fixed-scope basis for most engagements and offers retainers for ongoing support, upgrades and continuous testing. Ongoing support recurs for as long as you keep it. Ask for one-time and recurring costs as separate lines, and ask what you must provide, such as named staff, infrastructure access, course content and integration contacts.
How DeployOpen approaches ownership planning
DeployOpen plans Open edX cost of ownership and editions as a written, fixed-scope engagement inside your own infrastructure, so the recurring cost of hosting, upgrades and custom code is visible before work starts. The written scope sets what is built, what is handed over and what is supported after go-live.
How we scope
- Map the Open edX deployment model, such as Tutor on a single host or Tutor on Kubernetes, against your learner volume and hosting constraints.
- Separate the one-time build costs from recurring costs for LMS, Studio, databases, caches, storage and analytics in your environment.
- List the custom XBlocks, plugins, themes and integrations that will need testing on every named release upgrade.
- Agree the written scope, deliverables and timelines in writing before any work starts, since most engagements are fixed-scope.
How we build
- Build a reference cost model that names who runs each component, your team or a provider, and how often each part needs attention.
- Set up Tutor configuration, plugins and infrastructure so that the platform version and custom code can be upgraded and tested separately.
- Test custom code against the current named release, since Open edX supports only the latest named release at any time.
- Document the assumptions behind each cost line so the figures can be checked against your own hosting and staffing data.
How we hand over
- Deliver the cost model, architecture notes and upgrade test plan as documents your finance and platform teams can review.
- Walk through the recurring items, including infrastructure, release upgrades, custom development and support, with the people who will own them.
- Record which costs stay with your team, which are covered by a provider and which would need a retainer or a separate quote.
- Confirm what to ask for in any future quote, including hosting, upgrade work, custom development and support terms.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped in writing, once the platform is live.
- Review the cost model when a new named release is published, such as the release schedule listed for Willow and Xylon, and update the upgrade effort accordingly.
- Keep custom code, theming and analytics components tested against platform changes so recurring effort does not grow unnoticed.
- Advise on self-hosting versus a service provider so the decision is revisited if learner volume, compliance needs or staffing change.
