What an Open edX implementation involves
An Open edX implementation puts the two core services, Studio (the CMS authors use to build courses) and the LMS (where learners enroll and study), into infrastructure your organization controls. The work covers how that platform is hosted, either with Tutor, the official Docker-based distribution, or on Kubernetes using Tutor's Kubernetes support. It also covers configuring organizations, courses and programs, branding, single sign-on and analytics. Each of these is a separate decision, and the hosting choice affects most of the rest.
Organizations usually start this work for one of three reasons: they are leaving a commercial LMS and want to control their licensing and data, they are consolidating training that is spread across several tools, or they plan to offer courses to external learners and need a platform they can brand and govern. The trigger shapes the scope. A team consolidating internal training may need HR-driven enrollment and SSO first. A team selling courses externally will weight branding, payments outside the platform, and analytics for course owners more heavily.
Most teams that run Open edX in production use a partner for the first build. The edx-platform maintainers recommend running Open edX in production through a service provider or with Tutor, and they describe bare-metal installation as complex with limited community support. Your own team can still do much of the work, but the first build is where configuration mistakes become expensive. Ask any provider to show how the initial environment, release, backups and identity settings will be documented and handed over, and to name who is responsible for the first upgrade after go-live.
What the work includes and what you receive
A fixed-scope Open edX build usually runs as a set of workstreams, each ending in a named deliverable you keep. Ask for this breakdown in any quote so you can compare scope line by line.
Environment and Tutor configuration
Tutor is the official Docker-based Open edX distribution and supports Kubernetes, so the environment work covers choosing the hosting model, setting the Tutor configuration and secrets, and wiring the platform to your database, cache and storage. You receive a deployed environment, a version-controlled configuration repository and a runbook for rebuilding it. Confirm which hosting model the quote assumes.
Studio and LMS setup
Studio is the authoring service and the LMS is the learner service, and both need correct domains, email, HTTPS and admin accounts before any course is built. This workstream sets those values and tests a sample course end to end. You receive working Studio and LMS instances and a checklist of the settings that must match your production domains.
Organization and course structure
Organizations, course runs and programs determine how content, reporting and enrollment are grouped, so they are decided before build starts. This workstream maps your catalog, teams and reporting needs to that structure and loads an initial set of records. You receive a documented structure map and the configured organizations and program records.
Theming and frontend branding
Branding touches the legacy LMS and the React micro-frontends, and the approach you choose affects every future release. This workstream builds a brand package through Tutor theming and frontend plugin slots instead of forking core code. You receive the theme source in version control and a list of what was customized and why.
Third-party authentication
Open edX supports OAuth2, SAML 2.0, Shibboleth and LTI for sign-in, and the choice affects account linking, provisioning and support load. This workstream configures the provider you select and tests first login, linking and logout. You receive a configured identity provider, a test record of sign-in paths and a provisioning note for your directory team.
Aspects analytics
Aspects captures tracking logs as xAPI statements, stores them in ClickHouse through Ralph or Vector, and presents them in Superset dashboards. Sizing, retention and the reports course teams need drive most of the effort. You receive a running analytics stack, the dashboards agreed in scope and sizing notes for growth.
Plugin and XBlock work
Custom XBlocks and plugins extend course components and platform behavior, and each one must be tested against the release you run. Scope the number of blocks, their integrations and their test coverage before quoting. You receive the packaged code in version control, automated tests and a compatibility note for each release upgrade.
Handover and operations
Handover moves knowledge and control to your team, covering deployment, backups, restores, upgrades and support contacts. Ask whether training and shadowing are included in the fixed scope. You receive runbooks, a tested restore record and an agreed list of open items with owners.
What drives cost and duration
This table lists the main factors that change Open edX project effort, why each one adds work, and what you can do to keep it contained when comparing quotes.
| Driver | Why it adds effort | How to keep it contained |
|---|---|---|
| Learner numbers and concurrent use | Peak concurrent sessions set LMS, worker and cache capacity, and load testing before go-live takes time that grows with the target volume. | Agree a peak concurrency target in the scope, and ask the quote to include load testing against it rather than assuming current demand. |
| Course content and media volume | Large course libraries and video assets need import checks, media storage planning and a repeatable migration run, which lengthens cutover testing. | Limit the first migration to courses that are live or scheduled, and ask for a sample import run before pricing the full library. |
| Identity providers and integrations | Each SAML, Shibboleth, OAuth2 or LTI connection needs attribute mapping, account linking, test accounts and a failure path, so effort rises with every added source. | Start with the one identity provider that governs most learners, and phase additional providers into later releases of the scope. |
| Theming and frontend changes | Legacy LMS templates and React micro-frontends are branded separately, and changes that bypass plugin slots must be retested on every platform upgrade. | Use Tutor theming and frontend plugin slots, and limit branding to what the brand guide actually requires. |
| Custom XBlocks and plugins | Each custom block or Django plugin has its own build, test and packaging work, and must be checked against each named release before upgrades. | Build custom XBlocks only where a standard course component cannot meet a proven need, and standardize on Tutor plugin hooks. |
| Environments (staging and production) | Each environment needs its own configuration, secrets, data refresh and test cycle, so a second environment adds deployment and verification work. | Keep one staging environment that matches production configuration, and ask the quote to name what is refreshed and how often. |
| Compliance evidence needs | Assessors may ask for access logs, change records, backup test results and hardening evidence, and collecting this during the build adds documentation effort. | Define the evidence list in the scope before the build, and keep it tied to the controls your assessor actually asks for. |
| Hosting model: single Tutor host or Kubernetes cluster | A single Docker host with Tutor has fewer moving parts, while a Kubernetes cluster adds managed databases, storage, ingress, scaling and upgrade procedures. | Choose the single-host model unless learner volume or availability targets require a cluster, and confirm the decision in writing with the scope. |
Project phases and the output of each
The sequence moves from agreed scope to a hosted, configured, tested and handed-over Open edX platform, with a named output at every phase.
Run discovery and agree the scope
The partner and your stakeholders define the learner groups, course and program catalog, required integrations (identity, analytics, HR or CRM), and success criteria. Your team confirms who owns content, who approves decisions and which Open edX release the build targets. The output is a written scope with deliverables, exclusions and a phase-by-phase schedule, which should be agreed before work starts.
Decide the architecture and hosting model
The team chooses between a single-server Tutor deployment, Tutor on Kubernetes, or a managed-service model, and records the reasons. Hosting location, database and cache choices, media storage, backup approach and the sizing inputs are settled here. The output is an architecture decision record that lists each component, its owner and the open risks, and that your security team has reviewed.
Build the environments with Tutor or Kubernetes
The partner provisions the non-production and production environments in your accounts or data centers and deploys the platform with Tutor, either on Docker hosts or through tutor k8s. Infrastructure as code, TLS, secrets handling and access controls are put in place. The output is a working staging environment that loads the base platform, with build and deployment steps documented so your team can repeat them.
Configure organizations, courses and programs
The team sets up organizations, course structures, enrollment rules, roles for instructors and course staff, and the program definitions your catalog needs. Branding and theme settings are applied through configuration rather than core code changes. The output is a configured staging platform with sample courses reviewed by your course owners, and a record of every configuration decision that will move to production.
Build customizations and integrations
The partner builds the agreed custom work: Tutor plugins, frontend plugin slots, custom XBlocks, identity provider connections, and analytics or reporting feeds. Each item is built against the named release you chose and kept in version control. The output is a tested code set for each custom item, with a list of dependencies and the known upgrade impacts, so later release upgrades can be planned.
Test the platform and custom code
Testing covers the standard platform flows, the custom XBlocks, plugins and integrations, and the performance and failover checks your scope names. Custom code is tested against the current named release, which Open edX describes as the only supported release. The output is a signed-off test report listing passed cases, defects fixed and any accepted risks, with the test evidence stored with the project.
Cut over and hand over
The team moves approved configuration and code to production, runs the agreed cutover checks, and confirms backups restore in the target environment. Your staff are trained on operations, the runbook is handed over, and support terms begin under the written agreement. The output is a live production platform, a completed runbook and a handover record that names who owns each operational task.
How the work differs by starting point
A new build on one Tutor host is the smallest hosting scope. The work centers on configuration, plugins, HTTPS, backups and the first course build, with the platform running on one server.
- Confirm: the expected learner load, the server specification and whether the host can run the Docker stack alongside other services.
- Confirm: where backups are stored and how restores are tested.
- Cost drivers: the number of organizations, the volume of custom theming and the number of plugins to vet.
- Watch for: the point where one host stops being enough, which moves the work toward the Kubernetes tab.
A build on Kubernetes with Tutor adds cluster work to the platform work. Tutor supports Kubernetes deployments, so the platform team must agree on how the cluster, storage and database services are provided before the build starts.
- Confirm: whether the cluster, managed databases and ingress already exist and who operates them.
- Confirm: the shared cache choice, since multi-node deployments need a shared Django cache backend such as Redis or Memcached.
- Cost drivers: cluster and managed service setup, storage design, scaling of LMS and worker pods, and the platform team's time for upgrades in the cluster.
- Ask the quote to show: which items belong to the Open edX build and which stay with the platform team.
Replacing a legacy or Ansible-based Open edX install moves existing courses, learners and records onto a new Tutor-based build. The new build follows the Tutor and Kubernetes or single-host paths, and the data movement is covered in the migration topic.
- Confirm: the source release, the number of courses, the learner record volume and whether any custom code runs on the old install.
- Confirm: whether learner accounts will be carried over with their credentials or reset through the identity setup.
- Cost drivers: the course and record mapping effort, the testing of imported content and the cutover rehearsal.
- Refer to: the Open edX migration topic for the import, export and cutover steps, so this section does not repeat them.
A deployment in an air-gapped or restricted network changes how software, images and plugins reach the platform. Every dependency must be available inside the network, and updates must pass through an approved transfer process.
- Confirm: how container images, Python and Node packages, and plugin sources will be mirrored or transferred, and who approves each transfer.
- Confirm: whether external identity providers, email and analytics services are reachable from inside the network.
- Cost drivers: the mirroring and transfer process, the testing of each update in the isolated environment and the extra documentation for each release.
- Ask the quote to show: how the upgrade path to each named release will be delivered into the restricted network.
An existing Open edX site that needs an upgrade must reach the current named release, Verawood, which was published on 30 July 2026. Open edX supports only the latest named release, so the upgrade plan must account for every release between the current version and Verawood.
- Confirm: the installed release and Tutor version, and the list of custom XBlocks, plugins and themes that must work on the target release.
- Confirm: whether the site uses a Tutor-based or older install, since that changes the upgrade steps.
- Cost drivers: the number of release steps, the amount of custom code to test and fix, and the regression testing before cutover.
- Plan around: the next named release, Willow, which is listed for December 2026, if the upgrade will run into that window.
What teams keep in-house and what they outsource
This table maps each part of an Open edX project to the party that usually owns it and the skills it requires, so you can see where a partner adds the most value and where your own staff must stay involved.
| Project part | Usually owned by | Skills the part needs |
|---|---|---|
| Hosting operations | Partner builds, client runs or co-runs | Docker and Kubernetes, Linux, MySQL and MongoDB administration, backups and monitoring |
| Tutor configuration | Partner, with client sign-off on settings | Tutor plugins and hooks, Docker, environment and secrets management, Python |
| Course design | Client | Instructional design, subject expertise, assessment design, accessibility review |
| Studio content authoring | Client course teams | Course authoring in Studio, XBlock use, quality assurance of content |
| Theming | Partner builds, client approves brand and copy | Tutor theming, React and SCSS, brand and accessibility standards |
| SSO configuration | Partner configures, client's identity team owns the IdP | Identity federation (SAML 2.0, OAuth2/OIDC, Shibboleth), certificate handling, attribute mapping |
| Aspects analytics | Partner sets up, client defines reports and access | Data engineering, ClickHouse, xAPI, Superset dashboards, data governance |
| XBlock development | Partner builds, client owns the business logic | Python and Django, XBlock SDK, JavaScript, automated testing against each release |
| Security review | Partner tests, client accepts risk and evidence | Application security, TLS and cookie configuration, secrets handling, logging |
| Handover | Shared: partner documents, client's team runs | Runbooks, upgrade procedures, access management, knowledge transfer |
What usually goes wrong and how to prevent it
Most Open edX delays and cost overruns trace back to a few decisions made too late or without written criteria. Each card names one failure point and the design review, scope item or acceptance criterion that prevents it.
Custom code that forks the platform
Changes made directly to edx-platform block upgrades, because Open edX supports only the latest named release. A fork that falls behind the release cycle turns each upgrade into a merge project. During design review, confirm that every custom change is packaged as a plugin, theme or XBlock, and write upgrade testing for each named release into the scope.
Course and media migration underestimated
Legacy courses rarely import cleanly. Embedded media, video links, assets and quizzes with broken references need manual rework, and that effort grows with the number of courses. Require a sample migration of representative courses in the first phase, and write acceptance criteria for media playback, grades and links before the cutover date is fixed.
Identity and role model left open
Organizations, roles and identity provider attributes are often designed after the build starts. SAML, Shibboleth, OAuth2 and LTI providers each send attributes in their own format, and a missing mapping leaves learners or instructors without the right organization or role. Before build, document each role, its source attribute and a test login for every role.
Aspects sized from assumptions
Aspects storage and compute needs depend on event volume, which follows course activity and learner count, and the pipeline spans xAPI routing, ClickHouse and Superset. Sizing on guessed numbers either overbuilds or stalls the analytics launch. Ask for a written sizing sheet with event volume, retention period and a load test as acceptance criteria.
Bare-metal install chosen against guidance
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 with limited community support. Choosing it shifts patching, dependency pinning and service wiring to your team. Record the hosting decision in design review with the Tutor option compared.
No owner after go-live
After launch, someone must handle release upgrades, Tutor version changes, backup checks, plugin updates and incident response. Without a named owner, the platform drifts from the supported release and upgrades become emergency work. Put run responsibilities and a support scope into the written quote, or into a separate retainer scope, before go-live.
What you need to provide before the build starts
The fastest way to hold an Open edX schedule is to hand over a complete intake pack before the first build day. Each item below blocks a specific phase, and a gap usually surfaces weeks later as idle engineers or rework. Confirm each item with a named owner on your side before signing a fixed-scope quote, so the quote reflects what will actually be built. Start with the environment. DeployOpen implements inside your cloud accounts, data center or air-gapped network, so we need access to the target accounts, network rules for outbound package and container registry traffic, and the ability to create databases, object storage and load balancers. Without this, the Tutor or Kubernetes environment cannot be provisioned. Equally blocking are the domain names and TLS certificate decisions for the LMS, Studio and any preview hosts, including who issues and renews the certificates. Open edX cannot complete its HTTPS and cookie configuration until these are settled.
Identity is the next dependency. For SAML 2.0, Shibboleth or OAuth2 providers such as Azure Active Directory, we need the identity provider metadata or client registration details, the attribute mapping for email and names, and the decision on account linking. Without them, the third-party authentication configuration and the SSO test plan cannot start. For branding, supply logos, color values, fonts and any approved legal text in final form, since theming work depends on them. Content and people come last but drive the most schedule risk. Provide sample courses, media files and their licensing status, and name an owner for content, one for support, and one for security approvals. Each owner signs off on a different phase: content on the import tests, support on the runbook, security on hardening and the access model. Give a learner volume estimate for launch and for the first year, because it sets the sizing of the LMS, workers and analytics stack. Finally, decide who operates the platform after go-live, whether your team, a partner or a service provider. That decision determines what handover and training the build must include.
Frequently asked questions
What drives the cost of an Open edX implementation?
The main cost drivers are the hosting model, the number of organizations and courses to set up or migrate, the amount of custom work, and the integrations you need. A single Tutor server with one organization and a standard theme is a very different project from a multi-node or Kubernetes deployment with shared caches, managed databases and backups. Custom XBlocks, theming, SSO, analytics and plugins each add design, build and test effort. Ask the quote to price each of these separately so you can see what each choice costs.
How long does an Open edX project take to deliver?
No single duration applies, because the timeline depends on scope. A small Tutor deployment with local login and one course structure is far simpler than a multi-organization program with SSO, migrated learner records, custom XBlocks and analytics. The main timeline drivers are the number of content and data migrations, the number of identity providers, how much custom code needs review, and how many environments and approval steps are involved. Ask for milestones tied to these drivers and the assumptions behind each one.
Can our own team build Open edX without a provider?
Yes, a capable team can build and run Open edX with Tutor, the official Docker-based distribution, which has its own documentation. The edx-platform maintainers recommend running Open edX in production either through a service provider or with Tutor, and they note that bare-metal installation is complex and receives limited community support. Assess your team's existing skills in Python, Django, Docker, Kubernetes, MySQL and MongoDB. Then confirm that the staff who will handle each named release upgrade have the time to do it.
Why is only the latest Open edX release supported?
Open edX states that the latest named release is the only supported release and that it cannot support more than one release at a time. For a quote, this means moving to the newest named release becomes part of the work, and custom XBlocks, plugins and themes must be tested against it. Verawood is the current named release, published on 30 July 2026, and Willow and Xylon are listed for December 2026 and June 2027. Ask the quote which release the build targets and whether later upgrades are included or priced separately.
Is Open edX Aspects included by default in an implementation?
Do not assume it is. Aspects is a separate analytics set of components: xAPI events are captured through the event-routing-backends plugin, stored in ClickHouse via Ralph or Vector, and presented in Superset dashboards. Each part adds hosting, sizing, backup and maintenance work. Ask whether the written scope includes Aspects, which parts it covers, and how dashboards for course teams and administrators will be built and handed over.
Can a fixed-scope Open edX quote be written, and what should it list?
Yes, most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A written quote should list the hosting model, organizations, course and program structure, theming, identity providers, analytics, plugins and XBlocks, migrations, environments, testing, handover documentation and any post-go-live support. It should also state what your team provides, such as a named sponsor, content exports, access and DNS, along with the assumptions behind each line and any items deferred to discovery. DeployOpen does not publish a price list, so the quote follows from that written scope.
How DeployOpen scopes, delivers and hands over Open edX
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Open edX, that means a written scope covering hosting, organizations, courses, theming, SSO, analytics and custom code before any build work starts.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names hosting path (Tutor or Kubernetes), learner volume assumptions, and which LMS and Studio features are in or out.
- Each plugin, custom XBlock, theme and identity integration is listed separately so the quote can be checked line by line.
How we build
- Builds run in your cloud accounts, data centers or air-gapped network, using the Tutor deployment path agreed in the scope.
- Custom XBlocks, plugins and frontend work are tested against the named Open edX release chosen for the project.
- Environments are verified for MySQL, MongoDB, Memcached or Redis, HTTPS, backups and restore before learners are onboarded.
How we hand over
- Handover includes configuration records, deployment runbooks, plugin and XBlock documentation and the upgrade approach.
- Your team receives access, secrets handling notes and a tested backup and restore procedure agreed in the scope.
- Acceptance criteria from the written scope are walked through with your team before the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, sized to your release and hosting plan.
- Upgrades follow the latest named Open edX release, since the project supports only that release at any time.
- Ask your quote to state which support tasks are one-time handover and which recur under a retainer.
