Open edX high availability guide

Why Open edX high availability starts with shared state

High availability for Open edX means learners can keep reaching the LMS, and course teams can keep working in Studio, when one server, process or zone fails. Redundancy on this platform depends less on how many web nodes you run than on the state those nodes share. The LMS and Studio come from one codebase and are deployed as several services, so each node that serves a learner or an author reads from the same MySQL 8.0 database, the same MongoDB 7.x store, the same Django cache and the same media storage. If any one of these is a single point of failure, adding nodes adds capacity without adding availability. Start the design by listing where each of these four dependencies runs, who operates it and how it fails over.

The shared cache needs particular attention. Multi-node deployments need a shared Django cache backend, such as Redis or Memcached, so that nodes do not each hold their own copy of cached state and session data. Decide which product you will run, whether that product is itself highly available, and what happens to sessions and cached values during a failover. Ask your team or partner to confirm how the chosen Open edX release configures the cache and which settings must match on every node. Test this during a rehearsal by stopping a cache node while a test cohort is active and observing whether learners are logged out or see inconsistent content.

The installation method is part of the availability plan too. The edx-platform maintainers describe bare-metal installation as complex, note that it receives limited community support, and recommend running production through a service provider or with Tutor. Tutor is the official Docker-based distribution and supports Kubernetes deployments, which gives the team a repeatable way to define each service, its replica count and its configuration. A hand-built multi-node install can work, but every service, database connection and cache setting then becomes a custom artifact that your team must document, patch and rebuild after a failure. Ask any partner how node replacement, configuration drift and database failover are handled before you commit to a layout.

Upgrades belong in availability planning because only the latest named release is supported. Open edX states that it cannot support more than one release at a time. Verawood is the current named release, published on 30 July 2026, and the next releases, Willow and Xylon, are listed for December 2026 and June 2027. A platform that stays healthy but sits on an unsupported release carries a security and continuity gap. Rehearse each upgrade on a copy of production data, including the database migrations, before you schedule it. Keep upgrades out of term start and exam windows, and agree a rollback point with the business owner before the change window opens.

Which Open edX components need redundancy and why

Open edX high availability depends on which components can run as several instances and which hold state that every instance must share. Identity providers, Aspects analytics (ClickHouse and Superset) and event routing services are optional, so their outages should be isolated from the core learning path.

LMS for learner delivery

The LMS serves course pages, enrollment and the learner-facing APIs, and it carries most of the traffic during exams and cohort starts. It is normally the first tier to scale horizontally behind the reverse proxy. If it fails, learners cannot reach courses or sign in. Check in the Tutor and edx-platform documentation for your release which LMS processes can run as several replicas and which settings must match across them.

Studio for authoring

Studio is the course authoring application, used for editing content, managing course runs and running imports and exports. A Studio outage blocks course teams but usually leaves published content available to learners if the LMS and data stores are healthy. Confirm whether Studio can run as several instances in your release and that it uses the same shared cache and data stores as the LMS.

Background workers for asynchronous tasks

Background workers run asynchronous tasks such as course imports, email and certificate generation. When they stop, queued work waits and failures can go unnoticed until a learner or course team reports them. Confirm in the edx-platform documentation which worker queues exist for your release, whether workers can scale out, and how the task broker is configured. Monitor queue depth so a stalled queue is visible.

MySQL 8.0 for shared relational data

MySQL 8.0 holds the relational data for accounts, enrollments, grades and other platform records, so it is a single point of failure for nearly every learner and author action. Redundancy means a replicated or managed high availability setup with a tested failover path. Ask your database team to confirm the replication topology the Tutor deployment supports and how application connections recover after a failover.

MongoDB 7.x for course content

MongoDB 7.x stores the course structure and content that the LMS and Studio read and write, so its outage stops course loading and authoring. Run it as a replica set so a primary failure does not remove content access. Confirm the replica set size, election behavior and backup approach supported by your Tutor release, and test a failover before go-live.

Shared Memcached or Redis cache

Multi-node Open edX deployments need a shared Django cache backend such as Redis or Memcached. A per-node cache causes inconsistent sessions and stale data across LMS and Studio replicas. Losing the cache typically degrades performance and can disrupt sign-in, so confirm whether your release degrades gracefully or fails outright. Choose a clustered or managed option that matches the availability target you set for the platform.

Ingress, reverse proxy and media storage

The reverse proxy or ingress terminates TLS and routes requests to LMS and Studio replicas, so its failure makes the whole platform unreachable. Media and static files must sit on storage that every replica reads, or learners see missing images and broken styling depending on which node answers. Confirm how your Tutor or Kubernetes setup serves static assets and how certificate renewal is monitored.

Choosing the HA model: VMs, Kubernetes or a managed service provider

This table compares four ways to run Open edX with redundancy, from several VMs managed with Tutor to a full service provider. Read each row against the operational questions that follow: who patches nodes, who runs database failover, who owns secrets, how releases roll out and which skills your team must hold. The main takeaway is that the edx-platform maintainers recommend a service provider or Tutor for production, and the more of the operating burden you keep, the more in-house skill you need.

Option	When it fits	What it costs you operationally
Several VMs with Tutor-managed services	Your team wants redundant LMS and Studio nodes on infrastructure it controls and has Linux and Docker operations experience.	Your team patches the operating system and Docker hosts, runs or verifies MySQL and MongoDB failover, manages secrets in Tutor configuration and schedules every release upgrade across nodes.
Tutor on Kubernetes with tutor k8s	Your organization already runs a cluster, needs to scale LMS and worker pods independently and has platform engineers comfortable with Helm-style operations.	Your team owns the cluster, ingress, storage classes, managed or self-run databases, secret stores and rolling upgrades. Cluster skills and monitoring become ongoing work, not a one-time setup.
Single Docker host with off-host backups	Learner numbers and availability targets are modest enough that a single host with tested restores is an accepted risk, and it serves as a stepping stone before a multi-node design.	Host failure means downtime until restore, so your team must rehearse restores. Patching, secrets and upgrades stay with you, and this option does not provide node-level redundancy.
Running through an Open edX service provider	Your team wants a production platform without building multi-node operations in-house, or it needs support hours and an accountable operator.	You pay a provider for hosting, patching, failover and upgrades under contract. Your team still owns learner data decisions, content, integrations and the scope agreed with the provider. Ask which party holds secrets and database access.

How to build a multi-node Open edX deployment in order

This sequence takes a single Open edX install and turns it into a multi-node deployment where LMS, Studio and workers scale independently and any node can serve any learner. Each step closes with a check that proves the layer works before the next one depends on it.

Fix the release and Tutor version first
Record the Open edX named release and the Tutor version in writing before any node is built. Open edX states that the latest named release is the only supported release, so the platform owner makes this decision, not the server build team. Pin the Tutor version, the plugins that match it and the Python and Node.js versions the release requires for any custom build. Confirm the release and Verawood timeline with the Open edX release notes. Check: a clean build from the pinned configuration on one test host reports the same versions as the written plan.
Provision databases outside application nodes
Stand up MySQL 8.0 and MongoDB 7.x as their own services, separate from the LMS, Studio and worker hosts. Configure replication for each database and define the failover behavior with your DBA or platform team, including who promotes a replica and how clients reconnect. Set up scheduled backups with retention that you agree in writing, and store copies away from the database hosts. Check: restore the latest backup into a separate instance and confirm an application build can read course and enrollment records from the restored copy.
Place a shared cache for LMS and Studio
Deploy Redis or Memcached as a shared Django cache backend that every LMS and Studio instance uses. Multi-node Open edX needs a shared cache, because per-node memory caches give each instance a different view of the same data. Decide whether this cache also holds sessions, and document which settings point each service at it. Size the cache and its network path with your load test results, not with a fixed guess. Check: write a cache value from an LMS instance on one node and read it back from an LMS instance on another node.
Move media and static files to shared storage
Move uploaded course assets, media and compiled static files to storage that every LMS and Studio node can reach, such as an object store or a network file system that your infrastructure team supports. Confirm which storage backend your Tutor configuration uses for the release you pinned, and set the public URLs so each node serves the same files. Plan how static assets are built and published so that a new build reaches all nodes together. Check: upload an asset in Studio, then load it through a different LMS node and confirm the file returns with the same content.
Deploy LMS and Studio as separate services
Run LMS and Studio as separate scalable services, each with its own replica count, and place both behind a load balancer with health checks. Keep the two services independently deployable so learner traffic can grow without changing the authoring tier. Confirm that the health check endpoints respond only when the application can reach the database, cache and storage. Check: stop one LMS replica during a test and confirm the load balancer routes requests to the remaining replicas without errors visible to a test learner account.
Scale background workers separately
Run the Celery workers that handle asynchronous tasks, such as grade calculations, certificate generation and course imports, as their own deployment. Scale workers on queue depth and task duration, and keep their replica count apart from the web tiers. Confirm that every worker shares the same queue broker, cache and storage settings as the web services. Check: start a course import, scale workers up and down during the job, and confirm the import completes once with no duplicate tasks in the logs.
Configure session handling and TLS termination
Keep sessions in the shared cache so the load balancer does not need sticky sessions, which means any LMS node can validate a learner's session. Terminate TLS at the load balancer or ingress, and configure forwarded protocol and host headers so the platform generates HTTPS links and sets secure cookies. Confirm the session and CSRF cookie settings for the pinned release with the Open edX security documentation. Check: sign in through the load balancer, send several requests that land on different LMS nodes, and confirm the learner stays signed in and every cookie carries the Secure attribute.
Run a staged cutover with a rollback path
Move production traffic in stages, starting with internal staff accounts, then a limited group of learners, then all users. Freeze content changes during the cutover window, run a final database sync and confirm the rollback steps in writing before the switch. Keep the previous environment available until the new deployment has run through its agreed observation period. Check: rehearse the rollback on a copy of production, then confirm that test learner and staff accounts can sign in, enroll and open a course after each stage.

What drives Open edX high availability effort and cost

This table lists the factors that change how much design, build, testing and ongoing operations work an Open edX high availability setup needs, with ways to keep each one under control. Read each row as a question to answer in your own environment before asking for a quote. The main takeaway is that concurrency, release-tied custom code and compliance evidence usually move effort more than raw node count, and that most of the recurring cost comes from operating the platform rather than from the initial build.

Driver	Why it changes effort or cost	How to keep it down
Concurrent learners and peak events	Peak load on LMS, workers and the shared cache sets how many redundant nodes, database capacity and load tests are needed. Exam windows and course launches create short spikes that drive the design more than average use.	Document expected peak concurrency and the events that create it. Agree which peaks justify headroom and which can be handled by scheduling or queuing.
Course and media volume	Large course catalogs and heavy video or file assets increase database size, backup duration and media storage needs, and they affect how media is served across nodes.	Move media to object storage behind a CDN where your policy allows it. Set retention rules for old course versions and unused uploads.
Number of environments (dev, staging, production)	Each environment needs its own cluster, data copies, secrets and monitoring. Keeping staging close to production makes failover and upgrade tests realistic but adds recurring infrastructure cost.	Use smaller non-production topologies for routine work and reserve one production-like staging environment for failover and cutover rehearsals.
Integrations (SSO, analytics, payment and HR feeds)	Every external identity provider, analytics pipeline or data feed adds failure modes, timeouts and credentials to rotate. Analytics stores such as ClickHouse add their own redundancy requirements.	Map each integration to the high availability target it must meet. Agree which integrations can degrade without blocking learners, and test those failure paths explicitly.
Custom XBlocks and plugins retested on each release	Custom code must be rechecked against every named Open edX release, and only the latest named release is supported. Each upgrade repeats regression and failover testing for that code.	Keep custom work small and tied to documented plugin points. Automate tests for XBlocks and plugins and budget them as part of each upgrade cycle.
Compliance evidence requirements	Assessors may ask for evidence of backups, restore tests, access reviews, change records and availability reporting. Producing and keeping that evidence is ongoing work. DeployOpen prepares evidence but auditors and certification bodies issue any report.	Agree the control list and evidence format before design starts. Generate logs, restore records and change tickets as part of normal operations rather than at audit time.
Managed database services versus self-run clusters	Self-run MySQL and MongoDB clusters need replication, failover, patching and backup tooling staffed by your team. Managed services shift some of that work to the provider but change network design, parameter control and cost model.	Compare the responsibilities each option leaves with your team, including patching, failover testing and restore. Confirm which MySQL and MongoDB versions the provider supports for your Open edX release before deciding.
Shared cache and session design	Multi-node deployments need a shared Django cache backend such as Redis or Memcached. Losing or undersizing it affects every node at once, so its own redundancy and monitoring add scope.	Choose one shared cache service, size it from observed load, and test node loss and cache restart during the cutover rehearsal.

How high availability differs across single node, VMs, Kubernetes and air-gapped networks

A single node runs LMS, Studio, workers, MySQL, MongoDB and Memcached on one host, so the only redundancy is in your backups. Nothing fails over automatically. Recovery means restoring the database, media and configuration onto a replacement host, which is why the backup location and restore test matter more than any other design choice.

Redundancy: none for running services. Off-host copies of database dumps, media files and Tutor configuration are the recovery path.
Shared cache and media: the cache and media files live on the host's local disk. Media is only as safe as its off-host copy.
Database failover: no failover. Restore the latest MySQL and MongoDB backups to a new host and confirm the point-in-time gap you can accept.
Images and packages: Tutor pulls images at install and upgrade time. Confirm whether the host can reach the registry, or whether images are staged in advance.
Upgrades: rehearse on a copy restored from backup, then schedule the production upgrade with a fresh backup taken immediately before it.

Ask your provider or team to demonstrate a full restore to a clean host, timed and documented, before go-live.

Securing shared state, secrets and media access in a cluster

A cluster multiplies the places where Open edX can leak data or accept unwanted access. The cards below cover the controls that connect the shared database, cache, media storage, secrets, administrative paths, transport and backups to the application tier. Each one needs a named owner and a check your team or a partner can verify before go-live.

Limit data stores to application nodes

The MySQL database, MongoDB, the shared Django cache (Redis or Memcached) and any object or file storage for course media should accept connections only from LMS, Studio and worker nodes. Use private subnets, security groups or network policies, and block public addresses on every data store. Confirm that administrative tools and bastion hosts are the only other permitted sources, and test the rule from outside the application tier before go-live.

Keep secrets out of images

Database passwords, the Django secret key, storage credentials and third-party identity provider keys should enter the platform through Tutor configuration and the cluster secret store, never through container images or committed files. Check that no image layer, plugin repository or configuration file in version control contains a live value. Agree who can read and rotate each secret, and confirm that rotation can be performed without rebuilding images.

Restrict LMS and Studio admin access

The Django admin and Studio staff functions should not be reachable by ordinary learners or from the public internet without an additional control. Options include separate hostnames, load balancer allowlists, or a VPN in front of Studio and admin paths. Confirm which accounts hold staff and superuser roles, how they sign in, and how access is removed when people leave. Django settings and cookie guidance sits in the security hardening topic.

Encrypt traffic from the load balancer to nodes

Terminating TLS at the load balancer is common, but traffic from the balancer to each LMS and Studio node can still cross shared networks. Decide whether to re-encrypt that hop, and manage certificates for both sides with an owner and a renewal process. Confirm that the proxy forwards the headers Django needs to recognize HTTPS requests, or cookies and redirects will misbehave. Cookie flags are covered in the security hardening topic.

Encrypt and control backup access

Database dumps, MongoDB backups, media archives and configuration snapshots all contain learner records and secrets. Encrypt each backup at rest with keys held separately from the backup storage, and limit read and restore rights to named roles. Log restore operations, and test a full restore into an isolated environment on a schedule. Ask the provider which team can restore backups and how that access is reviewed.

Stay on the supported named release

Open edX supports only the latest named release, so security fixes reach a cluster only when it moves onto that release. Verawood is the current named release, published on 30 July 2026, and the next releases are listed for December 2026 and June 2027. Pin the Tutor version in each environment, track the release notes, and plan an upgrade window that includes your custom plugins and XBlocks.

How to test that Open edX stays up when a node fails

The test plan should be written before anyone stops a node. Each test needs a stated expected result, a maximum acceptable interruption and a named owner who decides pass or fail. Agree these criteria with the platform, operations and business owners in writing, because a team that sets thresholds after seeing results tends to accept whatever happened. Ask the business owners what is acceptable for learners sitting a graded assessment, since that window is usually tighter than for someone browsing the catalog. Run the tests in a non-production environment that matches the production topology as closely as the budget allows, and repeat them in production only when the change window and rollback plan have been approved.

Start with node loss. With learners signed in and working through a course, stop one LMS node behind the load balancer and confirm that sessions continue on the surviving nodes. Session continuity depends on the shared cache backend, Redis or Memcached, holding session data for every node, so verify that a session created on the removed node still works after it is gone. Repeat the test for one Studio node while an author saves units and edits a course outline. Expect a possible failed save at the moment of loss, and decide in advance whether an author must retry and whether any unsaved edit is acceptable to lose. For workers, restart one background task worker while a long job such as a course export or grade report is queued. Confirm that the job completes or is retried, and that no task disappears from the queue without an error record.

Next, test the data tier and the cache. For the MySQL 8.0 primary, run a planned failover while a probe script signs in test accounts and loads a course page at a fixed interval, timestamping each result. Record how long logins and course access fail and when they recover, then compare those figures to the agreed criteria. Run the same drill on the MongoDB 7.x replica set if the deployment uses one for course content, because a successful MySQL failover does not prove that the content store is available. Then restart the Memcached or Redis cache and observe whether users are logged out. The answer depends on whether sessions are stored in that cache, so check the configuration and record the result. Finally, after any change to media storage, request course images and uploaded documents from every LMS and Studio node and confirm that each returns the same content.

Two further checks cover recoverability and load. Restore the latest backup of MySQL, MongoDB and media into a separate environment, then confirm that courses open in Studio, that content and assessments match the source, and that a sample of learner enrollments, progress and grades matches the snapshot. A backup that has never been restored is untested, so schedule this restore as a recurring exercise. For load, ask the client for its historical peak of concurrent learners and the activity pattern during exams or enrollment periods, then build the test profile from those figures plus a margin the client agrees to. Record every result as evidence: timestamped logs, probe output, configuration versions, pass or fail for each criterion, and the sign-off. Independent auditors decide whether that evidence satisfies a control, and DeployOpen prepares it for them.

What to monitor, back up, upgrade and document after go-live

Going live is the start of the operating work, not the end of the project. The cards below cover the signals to watch, the backups and restore tests that protect learner and course data, the upgrade path through named releases, and the documents that let someone other than the build team keep the cluster running.

Node and service health

Track host resource use, pod or process restarts, and LMS and Studio response times for each node behind the load balancer. In a multi-node Open edX deployment, one unhealthy LMS node can hide behind healthy peers, so check each node separately as well as the pool. Confirm the alert thresholds and the monitoring stack with your own team, since they depend on your hosting and existing tooling.

Database replication lag

Measure replication lag between the MySQL primary and its replicas, and alert before reads served from a replica fall far behind writes. Watch MongoDB replica set member state and oplog window as well, because course content depends on it. Ask your database provider or DBA which lag and failover signals they expose, and confirm that the application connects through the failover path you tested.

Cache hit rate and evictions

Multi-node Open edX depends on a shared Django cache, usually Redis or Memcached, so cache misses shift load straight onto MySQL and MongoDB. Track hit ratio, eviction count and memory headroom over time, and note any change after a release or a new course launch. Confirm the cache sizing and eviction policy against your own traffic pattern before the first large enrollment.

Worker queue depth and storage capacity

Asynchronous tasks such as grading, email and course operations run on workers, and a growing queue shows up as delayed grades or slow Studio actions long before a user complains. Pair queue depth alerts with storage capacity alerts for media, uploaded course assets and database volumes. Confirm which queue broker and worker scaling approach your deployment uses, and set limits from your own measurements.

Certificate expiry

TLS certificates for the LMS, Studio, media domains and any SSO endpoints must renew before they expire, and a lapsed certificate blocks learners from the entire platform. Track expiry dates for every public hostname and every identity provider metadata signing certificate used in third-party authentication. Confirm who owns each renewal and whether renewal runs automatically in your ingress or load balancer.

Backups and scheduled restore tests

Back up MySQL and MongoDB with dumps or volume snapshots, back up media storage, and keep Tutor configuration and secrets in a protected store that can be rebuilt. A backup that has never been restored is an assumption, so run restore tests on a fixed schedule into a separate environment and time them. Confirm the backup tooling, retention periods and recovery targets with your own data owners.

Staged release upgrades

Open edX supports only its latest named release, so every upgrade is a move to the next release that the team must plan. Apply each named release to a staging cluster built from production-like data first, then promote it to production. Retest custom XBlocks, plugins and themes in that staging run, because they are the most likely components to break during an upgrade.

Architecture and runbooks

Keep a current architecture diagram that shows the load balancer, LMS and Studio pools, workers, database clusters, cache, media storage and external identity providers. Write runbooks for failover and restore, with exact steps, the commands to run and the expected result of each step. Review them after every upgrade and every restore test so they describe the cluster as it runs today.

Owners and the on-call path

Name an owner for each component, including the platform, database, identity, content and custom code, and record who approves changes to each. Define the on-call path from the first alert through escalation to the build partner or internal engineers, with contact hours and the cases that justify waking someone. Confirm the path with your own organization before go-live, because the people named here must be reachable when the cluster fails.

Open edX high availability questions buyers ask before hiring help

How much does high availability for Open edX cost to set up?

The cost depends on how many application nodes, database and cache layers, media storage paths and backup routes the quote covers, and how much of your existing stack you reuse. Each part has a one-time share (design, build, load testing, failover drills and documentation) and a recurring share (the infrastructure you pay your cloud or data center provider for, monitoring, upgrades and support). The largest drivers are the database topology, since MySQL 8.0 and MongoDB 7.x each need their own redundancy plan, the shared cache, because multi-node deployments need a shared Django cache backend such as Redis or Memcached, and whether media and backups are replicated across sites. Learner volume and peak concurrency change the sizing. DeployOpen does not publish prices. Ask for a fixed-scope quote that lists each component, who provisions it, which tests prove failover, and which items recur after go-live.

How long does a high availability Open edX project take?

The timeline depends mostly on your environment, not on the Open edX code alone. The work usually moves through a design review, provisioning of nodes and managed services, configuration of the LMS, Studio and workers, cache and database redundancy, media storage and backups, then load and failover testing and a cutover. Several factors lengthen it: access approvals in your cloud accounts, data centers or air-gapped network, database and identity owners who are slow to respond, unclear learner volume targets, and the number of custom plugins or XBlocks that must be tested in a clustered setup. A written scope should show the phases, the dependencies on your teams and the test evidence each phase produces. Ask for those milestones and their dependencies before you compare durations between proposals.

Can our internal team build high availability for Open edX alone?

Yes, an experienced platform team can build it, and many do. The real question is whether your team has the skills and time across Linux, networking, database replication, Django caching, Docker or Kubernetes, backup restoration and Open edX upgrades, all at once. 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. Consider who will respond when a node fails at night, who handles the next named release, and whether failover has been tested under realistic load. A partner can deliver a fixed scope, a runbook and handover, while your team keeps ownership. Compare your internal estimate against the same list of deliverables a quote would include.

What does a high availability Open edX project need from our team?

Expect to provide access, named owners and a calendar. Access means accounts or network paths to build in your cloud, data center or air-gapped network, along with approvals for firewall, DNS and certificate changes. You need a database owner who can decide on MySQL and MongoDB topology, backup retention and restore authority, and an identity owner for single sign-on settings if third-party authentication is in scope. Provide test users for each role, including learners, course teams and administrators, so failover and load tests reflect real use. A release calendar is essential: agree freeze windows for cutover and share planned Open edX upgrades. Name one decision maker who can accept trade-offs during the build, because unresolved choices are a common cause of delay.

Is Tutor on Kubernetes required for high availability Open edX?

No. Tutor on Kubernetes is one supported route and is not a requirement. Tutor supports Kubernetes deployments, which suits teams already running clusters and managed databases. High availability can also be designed across several hosts managed through Tutor or another approach, as long as the database, cache, media storage and load balancing are all redundant. The choice changes operations. Kubernetes adds cluster skills, storage decisions and a cluster upgrade workflow, while a multi-host layout adds manual node management and more careful configuration tracking. Decide based on your team's skills, your hosting standard and the failover behavior you need. The quote should state the chosen topology, why it fits your environment and what the team must operate after go-live.

What happens to a high availability Open edX setup at the next release?

The setup must be upgraded to the next named release, because 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. Verawood is the current named release, published on 30 July 2026, and the next releases, Willow and Xylon, are listed for December 2026 and June 2027. Each upgrade touches the LMS, Studio, workers, database migrations, cache configuration and any custom XBlocks or plugins. A high availability setup adds steps: rolling updates across nodes, migration ordering and failover tests after the change. Ask whether the scope includes upgrade planning, a staging rehearsal and post-upgrade failover testing, or whether that work falls under a support retainer.

How DeployOpen scopes, builds, hands over and supports Open edX high availability

DeployOpen plans, builds, documents and supports Open edX high availability inside your own cloud accounts, data centers or air-gapped networks. We start from the platform's actual architecture, including Studio and the LMS, workers, MySQL, MongoDB, shared caches and media storage, so the written scope reflects what your deployment must survive.

How we scope

Confirm whether the target is a multi-node Tutor setup or a Kubernetes cluster, and which components must be redundant.
Map LMS, Studio, worker, MySQL, MongoDB, Redis or Memcached, and media storage dependencies before estimating any build.
Agree the written, fixed scope, deliverables and timeline with you before work begins; ongoing support can be added as a retainer.

How we build

Configure a shared Django cache backend so that multiple LMS and Studio nodes handle sessions and cached data consistently.
Set up database redundancy and backups for MySQL and MongoDB, and test restores on a separate environment.
Place course media on shared or object storage, then verify that uploads and asset delivery work from every node.

How we hand over

Document the topology, configuration files, secrets handling and the recovery steps for each redundant component.
Run failover and node-loss tests with your team present, and record the results alongside the configuration.
Train your operators on scaling LMS and worker pods, routine backups and the release upgrade procedure for your environment.

How we support

Monitor availability and capacity signals agreed during scoping, and review them with your platform team on a schedule.
Plan Open edX upgrades around the latest named release, since only that release is supported, and retest clustering after each change.
Offer ongoing support, upgrades and continuous testing as a retainer, with the coverage written into the agreement.