Why an Open edX Kubernetes deployment with Tutor needs more than a cluster
A platform team asked to run Open edX in its own cluster should expect Tutor on Kubernetes to fit, but only if the team is ready to own more than the cluster. Tutor is the official Docker-based Open edX distribution for production and local development, and it supports Kubernetes deployments. The edx-platform maintainers recommend running production through a service provider or with Tutor, and they note that bare-metal installation is complex and receives limited community support. Treat Tutor as the packaging layer. The operational work sits in the services and release process around it, and that is what you need to check before committing.
Open edX is a modular monolith. It combines independently deployable applications with React-based micro-frontends, and its two core services are Studio, the authoring CMS, and the LMS, which serves learners. Both depend on background workers, so the deployment has several workload types to size, scale and restart separately. Confirm which workers and micro-frontends your deployment will run, how each one is exposed through ingress, and which components must share configuration. Those answers determine how many Kubernetes workloads you will monitor and which failure modes you need to test.
The hardest part is the stateful services. edx-platform development requires MySQL 8.0 and MongoDB 7.x, and multi-node deployments need a shared Django cache backend, such as Redis or Memcached. Each of these needs a decision on whether it runs inside the cluster or on a managed service in your cloud or data center, along with a tested backup, restore and failover path. Media storage is the other persistent concern, because uploaded course assets must survive pod replacement and be reachable by every LMS and Studio instance. Ask who owns each stateful component, what recovery time your organization requires, and whether a restore has been rehearsed against a copy of production data.
The release cycle is the third hard part. 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, so you cannot stay on an older line while you schedule the work. 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. Confirm which release your deployment targets, how long your change process needs for each upgrade, and who applies Tutor version changes and plugin fixes between named releases. A cluster makes upgrade mechanics repeatable, but it does not set the timing for you.
Before you choose between your own team and a partner, write down the answers to a few questions: which team owns the LMS, Studio, workers and micro-frontends; where MySQL, MongoDB, the shared cache and media storage run; how backups are tested; and which release you will be on at go-live. List any Tutor plugins, custom XBlocks and theme changes too, because each one must be retested on every upgrade. Gaps in these answers are the risks to plan for, and they will shape the scope of any fixed-scope quote. Ask any provider to show how they handled the same items on a comparable deployment, and ask for the evidence.
Which Open edX components a cluster must host
An Open edX cluster runs several kinds of workloads, and they do not all behave the same way under Kubernetes. Tutor generates the manifests for each one, but your team still chooses where each stateful service lives, whether inside the cluster or on managed infrastructure. That choice shapes backups, failover and upgrade planning.
LMS and Studio web processes
The LMS serves learners and Studio serves course authors. Both are Django applications that run as web processes, and their pods can be replaced or scaled out. They must not keep session data, uploaded files or cached values in local memory. Check that every replica reads the same settings, secrets and shared cache, and that a rolling restart does not log out learners or discard a course edit in progress.
Background worker processes
Workers run asynchronous tasks that the web processes hand off, such as sending email and running longer course operations. They look stateless, but they depend on the same databases and cache as the web tier, plus a message broker for queued work. If the worker pool is undersized or points at a different settings file, tasks queue without clear errors and learners see delays. Confirm the queues and broker your Tutor release uses before sizing the pool.
React micro-frontends
Newer parts of the interface are React micro-frontends that the browser loads alongside the Django-rendered pages. They hold no learner data of their own, but each build depends on configuration that must match the LMS and Studio release. Check that the frontend builds, API endpoints and plugin configuration are versioned together, so an upgrade does not leave a page calling an API that has changed.
MySQL relational data
MySQL holds relational records such as user accounts, enrollments and grades. The edx-platform project specifies MySQL 8.0 for development, so confirm the version your Tutor release expects before choosing a managed service. This is stateful data that needs backups proven by test restores, a recovery point objective agreed with the business, and a tested failover path. Running it in a pod without persistent storage risks permanent loss.
MongoDB course content
MongoDB stores course structure and content, so it is the data that defines what learners see inside each course. The edx-platform project lists MongoDB 7.x as a development requirement, and you should confirm the version your release supports. Losing this store breaks courses even while the LMS keeps running. Schedule its backups alongside MySQL backups so that enrollment records and course content can be restored to a matching point in time.
Shared Django cache
Multi-node deployments need a shared Django cache backend, usually Redis or Memcached. The edx-platform project lists Memcached among its development requirements, so confirm which backend your Tutor release configures. Cache contents are disposable, but a per-pod local cache gives replicas different answers and can break sessions after a scale event. Size the cache for session volume and check how it behaves when restarted.
Decisions to settle before the first tutor k8s run
This table compares the infrastructure choices to settle before the first tutor k8s run: databases, shared cache, media storage, TLS termination and where Aspects runs. Read each row as a fit test followed by the work that stays with your team after go-live. Confirm every managed service against the MySQL 8.0 and MongoDB 7.x versions Open edX expects before you commit.
| Decision | When it fits | What it costs to run |
|---|---|---|
| Relational database (MySQL 8.0) | In cluster fits teams with database operators and backup routines. Managed outside fits teams that want the provider to own failover and patching. | In cluster: you own backups, patching, failover and storage. Managed: added latency between pods and database. Confirm MySQL 8.0 compatibility with the provider. |
| Document store (MongoDB 7.x) | In cluster fits teams already running MongoDB operators. Managed outside fits teams that want the provider to handle backups and failover. | In cluster: you own replica set health, backups and upgrades. Managed: latency and provider fees. Confirm the service supports MongoDB 7.x before you commit. |
| Shared cache: Memcached | Fits a single shared cache where losing entries on restart is acceptable for your traffic pattern. | You run and monitor the pods and their memory limits. Cached data does not survive restarts. Confirm the release configuration selects Memcached. |
| Shared cache: Redis | Fits teams that already run Redis or want a managed cache service. | Persistence, memory eviction and failover are yours to configure. Confirm the Redis version and the Django cache backend setting for your release. |
| Media: object storage | Fits multi-node LMS and Studio, since replicas can share media without a shared volume. Needs a configured storage backend. | Access keys, lifecycle rules and backups are yours. Requests add some latency. Confirm the storage backend settings in your Tutor configuration. |
| Media: shared volumes | Fits a cluster whose storage class already offers shared read-write access and a team that operates it. | Shared file system performance, capacity growth and backups are yours. A slow volume slows every replica that mounts it. |
| Ingress and TLS in cluster | Fits teams that want routing and certificates defined alongside the platform manifests. | You own ingress controller and certificate manager upgrades, renewals and alerts. Confirm HTTPS and secure cookie settings match your domain. |
| TLS at external load balancer | Fits organizations whose load balancer already manages certificates and TLS policy centrally. | Confirm forwarded protocol headers reach the platform so links and cookies stay secure. Check this during the first test deployment. |
| Aspects analytics in the same cluster | Fits pilots or single-team setups where one group runs both the platform and analytics. | ClickHouse, Superset and the event pipeline add storage, memory and upgrade work. Plan separate alerting and confirm sizing against the Aspects documentation. |
Build sequence for a Tutor deployment on Kubernetes
This sequence takes an empty cluster to a running Open edX site on Tutor, with data stores, the LMS, Studio and workers, public access over TLS, and tested backups. Each step closes with a check that the next step depends on, so problems surface before learners arrive.
Provision the cluster and namespaces
The platform team creates or confirms the Kubernetes cluster in the client's cloud account, data center or private network, then defines namespaces for the Open edX application, data services and ingress. Access controls, image registry access and node capacity are set here, along with the network policies that decide which namespaces can reach the databases. The step closes when a test workload can be scheduled in each namespace and pull its image from the registry. Confirm with the client which Kubernetes version and node pool sizes their platform team supports.
Provision or attach the data stores and cache
The team either attaches managed MySQL 8.0 and MongoDB 7.x instances or deploys them inside the cluster, then provisions a shared cache. Multi-node Open edX needs a shared Django cache backend such as Redis or Memcached, so every LMS and worker pod reads the same session and cache state. Credentials go into the cluster's secret store, not into configuration files. The step closes when a debug pod in the application namespace opens a connection to MySQL, MongoDB and the cache using the same credentials the application will use. Confirm which Tutor release supports the database versions you plan to run.
Configure Tutor settings and plugins for the release
On a workstation or CI runner, the team installs the Tutor version that matches the chosen Open edX named release, then sets the platform domain, languages, email, storage and third-party authentication values. Plugins are installed and pinned to versions tested against that release, and any custom theme or XBlock package is added at this point. The step closes when Tutor renders its configuration without errors and the plugin list matches the approved bill of materials. Verawood is the current named release in the supplied material, so confirm which release the client's project targets before pinning versions.
Generate and review the Kubernetes manifests
The team generates the Kubernetes manifests with the tutor k8s commands and reviews them before anything is applied. The review checks image tags, resource requests and limits, replica counts for the LMS and workers, persistent volume claims, secret references and any cluster-wide objects. Manifests are committed to version control so changes can be reviewed and rolled back. The step closes when the reviewed manifests pass a dry-run apply against the target cluster with no errors or unexpected objects. Ask the partner to show the diff between generated and reviewed files.
Deploy the LMS, Studio and workers
The team applies the reviewed manifests to the cluster, starting with the database initialization and migration jobs, then the LMS, Studio and background worker deployments. Migrations must finish before the web deployments accept traffic, so the order is checked in the job status rather than assumed. The step closes when all pods report ready, the migration jobs show completed, and a test task submitted by the team is picked up and finished by a worker. Confirm how the client's change process handles migration failures before the first apply.
Configure ingress, TLS and DNS
The team creates the ingress resources for the LMS and Studio hostnames, attaches a TLS certificate from the client's certificate authority or an automated issuer, and points DNS records at the ingress address. Cookie and redirect settings are confirmed against the public hostnames so that login and course URLs stay consistent. The step closes when an HTTP request to the LMS health endpoint returns a successful response over the public hostname with a valid certificate chain. Studio should be checked the same way on its own hostname before the step is marked complete.
Load initial data and admin accounts
The team loads the initial platform data, creates the first staff and superuser accounts, and sets up the organizations, course catalog placeholders and any site configuration the client needs before pilot users arrive. Admin accounts are created with named individuals rather than shared logins, and default credentials from the installation are removed. The step closes when an administrator signs in to Studio and the LMS through the public hostnames, and a test course can be created, published and opened by a test learner account. Confirm with the client who approves admin access and how it is recorded.
Wire and test backups
The team connects scheduled backups for MySQL, MongoDB, media storage and the persistent volumes that hold configuration and generated assets, with retention set to the client's policy. Backup jobs run in their own namespace with credentials scoped to the backup targets. The step closes with a restore test: the team restores the latest backup into a separate namespace and confirms that the LMS starts and that a known course and learner record are present. A backup that has not been restored has not been verified. Ask the partner to document the restore procedure and who runs it.
What drives the effort and cost of a cluster deployment
This table lists the main factors that change the effort and cost of an Open edX Kubernetes deployment with Tutor, and how each one can be kept under control. Read each row as a question to answer before scoping: the more of these drivers your project carries, the more the fixed-scope quote should break out by line. Ask for effort split by driver, not as a single total.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Number of environments | Development, staging and production each need their own cluster configuration, secrets, domains and data, and each must be kept on the same Tutor version. | Use one reference configuration reused across environments, with only values (hostnames, sizes, secrets) changing between them. |
| Learner base and concurrency | Peak concurrent learners drive how many LMS and worker replicas, database capacity and cache capacity are needed, and how load tests must be designed. | Agree target concurrency and peak patterns early, size from measured load tests, and avoid over-provisioning for hypothetical peaks. |
| Custom plugins and XBlocks | Each custom Tutor plugin, Django app, XBlock or theme must be rebuilt, retested and reviewed against every named Open edX release and every Tutor upgrade. | Keep custom code to what the course model truly needs, prefer supported plugin slots and hooks, and document which custom components are owned by the client. |
| Managed versus self-run data stores | MySQL, MongoDB and the shared cache can be run in the cluster or provided as managed services, which changes provisioning, backup, patching and the monitoring you own. | Decide per store before scoping. Confirm with your platform team which stores you already operate and what your backup and patching standards require. |
| Storage and backup requirements | Media uploads, database volumes and backup retention determine persistent volume design, restore testing and recovery time expectations. | Define retention periods and restore objectives in writing, then test a full restore in a non-production environment before go-live. |
| Integrations such as SSO and LTI | Each identity provider (for example SAML 2.0, Shibboleth or OAuth2 providers) and each LTI tool needs its own configuration, test cases and ongoing certificate or key management. | Limit the first release to the identity providers and LTI tools you need on day one, and add others as separately scoped change requests. |
| Compliance evidence needs | Assessors may ask for configuration baselines, access records, backup test results and change history. Collecting this evidence is extra work on top of the build. | Agree the evidence list up front, generate it from the reference configuration and upgrade runbook, and confirm with your auditor what they will accept. DeployOpen prepares evidence but does not issue audit reports. |
| Upgrade runbook and release cycle | Named Open edX releases are supported one at a time, so every platform move requires regression testing of the cluster, custom code and integrations. | Write a documented upgrade runbook during the build, rehearse it in staging, and ask for upgrade effort as its own line in the quote. |
How the cluster layout changes by environment
A single production cluster is the simplest layout to reason about. The LMS, Studio, workers and data stores all run inside one cluster, usually in one cloud account, and your team owns every component from the ingress controller down to the database volumes. Tutor generates the Kubernetes manifests from its configuration, so most of the decisions concern storage classes, sizing and where state lives.
Data store placement: Decide how MySQL, MongoDB and Memcached are deployed, which storage class backs their volumes and who performs restores.
Media and uploads: Choose whether course assets sit on a volume shared across pods or move to object storage later, because that choice affects how pods scale.
Shared cache: Once more than one LMS pod serves requests, a shared Django cache backend such as Redis or Memcached is required.
Backups: Volume snapshots do not replace logical database dumps, so plan both and test a full restore into a separate namespace.
Failure modes: A node failure can take a database pod with it, and a storage class without snapshot support turns a restore into a rebuild.
Before committing, confirm the storage class, snapshot and restore procedure with your platform team, and check the resource layout Tutor generates for your exact Tutor version.
Moving MySQL, MongoDB and media storage outside the cluster changes the failure boundary. The cluster becomes stateless for most workloads, which simplifies rebuilds and rolling upgrades, but every LMS and worker request now depends on a network path to a service run by someone else. Ownership shifts from the cluster team to a combination of the cluster team, the database provider and the cloud network team.
Engine compatibility: Confirm that the provider offers the MySQL 8.0 and MongoDB 7.x versions the platform expects, and check the supported parameter settings with the vendor.
Network path: Decide between private endpoints and public endpoints, and confirm latency between the cluster and the database region.
Credentials: Store database and object storage credentials in Kubernetes secrets with a rotation process, and limit each credential to the buckets and databases the platform needs.
Connection limits: Scaling LMS and worker replicas multiplies connections, so a pool that works at one replica count can exhaust a managed database at another.
Recurring costs: Managed service fees and data transfer charges recur every month and grow with learner activity, so ask for them to be estimated separately from one-time migration work.
Before committing, confirm with the provider the maintenance windows, failover behavior and the object storage API compatibility that Tutor's configuration depends on.
In an air-gapped or restricted network, the cluster cannot reach public registries, chart repositories or package indexes during install or upgrade. Every artifact the deployment needs must be mirrored internally first, and the mirror becomes a dependency that must be updated for each platform release. The main risk is not the first install but the upgrade that needs a package nobody mirrored.
Container images: Build an inventory of every image referenced by the Tutor configuration for your version, then mirror each one into an internal registry.
Manifests and charts: Render manifests and fetch chart sources in a connected staging environment, then transfer them through your approved process and verify checksums.
Python and Node packages: Custom images and plugins install dependencies at build time, so internal package mirrors must hold the transitive dependencies, not only the top-level packages.
Certificates: Internal registries and mirrors need certificate trust configured on every node and in the build pipeline.
Failure modes: A missing dependency usually fails during an upgrade build, long after the original install succeeded, so test a build from a clean mirror before each change window.
Before committing, confirm with the vendor and your platform team the complete image list for your version, whether builds run fully offline, and whether any step contacts an external service.
How to test that the Open edX cluster works and fails safely
A Kubernetes deployment of Open edX is only ready for learners when a defined set of tests passes on the cluster itself, not just on a developer workstation. Start with smoke tests that exercise the two core services: log in to the LMS as a learner, log in to Studio as a course author, and create a test course from start to finish. Run these through the public ingress hostnames you configured, because a pass on an internal service address can hide problems with TLS, cookies or routing. Record the results with the Tutor version, image tags and the Kubernetes namespace so the same suite can be rerun later.
Next, test the content and learner paths. Import a small test course, export it, delete it, and import the export again. The round trip checks that Studio writes course data to the MySQL and MongoDB stores and that media files reach the storage you configured. Then enroll a test learner, complete the course, and confirm that the certificate is issued and can be viewed. If you use third-party sign-in or LTI, add a login through that path to the same run. Ask your implementation partner or platform team to confirm which certificate template and grading settings the test course should use, since these vary by installation.
Worker and restart tests come next. Confirm that asynchronous tasks, such as course imports, email and grade calculations, run through the worker deployments and complete without errors. Then restart each pod type one at a time (LMS, Studio, workers and any other deployments in your Tutor configuration) and confirm that the Kubernetes rollout completes and the smoke tests still pass. Repeat the drill for the database layer: fail over the MySQL primary or the in-cluster instance, and do the same for MongoDB. Your managed database provider or your own runbook should state the expected failover behavior, the time to reconnect and what happens to in-flight writes. Confirm these details before the drill rather than during it.
A cache loss test confirms that sessions recover. Flush or restart the shared Memcached or Redis backend and check that signed-in learners and staff are either kept signed in or sent to a login page without losing course progress or entering an error state. Safe failure means the platform degrades in a predictable way: pages may reload or require a new sign-in, writes are either committed or clearly rejected, no learner data is exposed to another account, and the cluster returns to normal without manual database edits. Document what a safe failure looks like for each test before you run it, so the team can judge the result quickly.
Before every Tutor version change, repeat the full suite in a staging cluster built from the same configuration and images you plan to promote. Include the smoke tests, the import and export round trip, the certificate path, the worker checks, the restart and database failover drills and the cache loss test, plus any tests for your custom plugins or XBlocks. Keep a rollback plan that has been tested, and treat any failed test as a stop condition until its cause is understood. The effort and frequency of these runs are a cost driver to raise in any quote, because they recur with each upgrade and not only at go-live.
Securing secrets, access and network paths in the cluster
An Open edX deployment on Kubernetes spreads configuration, credentials and traffic across LMS, Studio, workers and data stores, so each path needs an explicit owner and control. The cards below cover where secrets live, who can reach administrative surfaces, how components talk to each other, how traffic is encrypted at the edge, and who can run Tutor against production. Django settings and plugin vetting are covered in the separate security hardening topic.
Tutor configuration secrets
Tutor generates and stores values such as the Django secret key, database passwords and service credentials in its configuration. On Kubernetes, decide whether these values live in Kubernetes Secrets with encryption at rest enabled, or are pulled from an external secrets manager at deploy time. Check that the generated configuration file is not committed to a shared repository, and confirm how rotation of each secret would be applied to running LMS and worker pods.
Database and cache credentials
MySQL, MongoDB and the shared Redis or Memcached cache each need their own credentials, with access limited to the services that use them. If you use a managed database service, confirm how its credentials are injected into pods and whether they can be rotated without redeploying the whole platform. Ask your provider which network and identity controls apply to these endpoints, and record who holds administrative access to each one.
Studio and admin access restrictions
Studio, the Django admin and the instructor tools are the most sensitive surfaces in the platform. Decide which networks or identity groups can reach Studio and the Django admin, and whether they sit behind a separate hostname or access proxy. Review which staff roles are granted in the platform and confirm that accounts are removed when people leave the course team or operations group.
Network policies between components
Kubernetes network policies can restrict which pods talk to each other. Map the expected traffic: ingress to LMS and Studio, LMS and workers to MySQL, MongoDB and the cache, and outbound calls to identity providers and mail services. Default-deny the namespace, then allow only those flows. Verify the policies with a test pod from outside the allowed set, because the cluster network plugin must enforce them for the policies to have any effect.
TLS at ingress and cookie settings
Terminate TLS at the ingress controller with certificates from your own certificate authority or a public issuer, and redirect plain HTTP to HTTPS. Confirm that session and CSRF cookies are marked secure and that the platform domain and cookie domain settings match your public hostnames. Check certificate renewal, the cipher policy your ingress enforces, and whether internal traffic between services needs encryption under your own policy.
Who can run Tutor against production
Tutor commands such as configuration changes, upgrades and database initialization can alter a live platform. Limit production access to named operators, route changes through version-controlled configuration, and keep cluster credentials separate from staging. Record each production command and its output in your change log, and confirm which account the pipeline uses to apply changes to the cluster.
What to monitor, back up and document after go-live
After go-live, the operations routine should watch four signals every day: pod health, data store and cache metrics, worker queue depth and ingress error rates. Start with the LMS, Studio and worker deployments in the cluster. Track restarts, failed readiness checks and pods stuck in pending, since these usually appear before learners notice a problem. Next, watch MySQL connection counts, slow queries and storage headroom, MongoDB operation latency and disk use, and the shared cache's hit rate and eviction count. Queue depth matters because a growing backlog of asynchronous tasks, such as grading or email, shows that workers are undersized before the LMS slows down. Finally, watch 5xx rates at the ingress controller by hostname. Agree alert thresholds with your platform team and test that each alert reaches a named person.
Backups need a written schedule and a restore test that runs on a timetable. MySQL holds core relational data for the LMS and Studio, so it needs the most frequent full and incremental protection. MongoDB holds course structure and content data in the releases your cluster runs, so confirm with your Tutor version which collections matter and back them up consistently with MySQL. Media storage holds uploaded course assets and files, and it must be backed up on its own schedule with the same retention rules. Set recovery targets with your business owners before choosing intervals. Store copies outside the cluster and in a location your data residency policy allows. A backup that has never been restored is unproven, so restore into an isolated namespace on a regular basis and check login, course rendering, a learner progress record and a media file.
Open edX supports only the latest named release, and it cannot support more than one release at a time. Verawood is the current named release, published on 30 July 2026. Willow and Xylon are listed for December 2026 and June 2027. This means every cluster must plan a repeated upgrade path, not a single upgrade project. Build the upgrade run book as a standing process with an owner, a schedule and a budget line. Confirm the release dates on the Open edX release notes before you commit a maintenance window, because listed dates can change. Also confirm which Tutor version matches each Open edX release before scheduling an upgrade, and check that version against your custom plugins, XBlocks and themes.
The upgrade run book should list each step in order. Begin with a fresh backup of MySQL, MongoDB and media storage, and confirm that a restore from that backup has succeeded recently. Upgrade a staging cluster built from the same configuration first, including every custom plugin, XBlock and theme. Run the database migrations, then execute smoke tests covering learner enrollment, grading, Studio course editing and any single sign-on login. Record the image tags, Tutor configuration and values files used for each release. Define the rollback path and the conditions that trigger it before the maintenance window opens. Afterward, update the run book with what took longer than planned.
Keep operational documentation current in version control. Include a cluster inventory, the Tutor configuration and plugin list for each environment, the locations of secrets without their values, alert routing and on-call owners, the backup schedule, the restore test log and the upgrade history. Ask your implementation partner for these documents as part of handover, and confirm who holds administrative credentials after the project closes. Documentation is the difference between an upgrade your team can run alone and one that depends on the people who built the cluster.
Questions teams ask before running Open edX on Kubernetes
Can our team deploy Open edX on Kubernetes with Tutor without outside help?
Yes, a platform team with strong Kubernetes skills can deploy Open edX with Tutor without an outside partner, but the first deployment usually takes longer than teams expect. Tutor is the official Docker-based Open edX distribution for production, it supports Kubernetes deployments, and its plugin and hooks system is licensed under Apache 2.0. The edx-platform maintainers recommend Tutor or a service provider for production because bare-metal installation is complex and receives limited community support. Your team needs working knowledge of Kubernetes, Django-based services, MySQL 8.0, MongoDB 7.x and a shared cache. The gap usually appears in day-two work: backups, scaling LMS and worker pods, certificates and release upgrades. Before you decide, check whether someone on the team can own those tasks for the life of the platform.
What does a Kubernetes Open edX project need from our team?
Three inputs matter most before work starts: cluster access, database ownership and a named upgrade owner. Cluster access means a namespace or cluster where the work can run under your change controls, with credentials handled through your own secrets process. Database ownership means your team decides who operates MySQL 8.0 and MongoDB 7.x, including backups, restores, patching and capacity, and who approves changes to them. An upgrade owner is one named person who accepts release decisions, schedules test windows and signs off on custom XBlocks, plugins and themes. You will also need to provide DNS records, TLS certificate responsibilities, a contact for learner data decisions and access to your identity provider if SSO is in scope. The written scope should list each input, its owner and the date it is needed.
Does Open edX on Kubernetes support managed MySQL and MongoDB services?
A managed service can work only if it matches the database versions Open edX requires and gives Tutor the access its deployment needs. The edx-platform requirements list MySQL 8.0 and MongoDB 7.x, and multi-node deployments need a shared Django cache such as Redis or Memcached. Confirm four things with the provider and in the Tutor documentation for your target release: version compatibility, whether the service accepts the connection settings Tutor generates, how backups and point-in-time recovery work, and when maintenance windows occur. Check also that the service supports the TLS settings and user permissions your security team requires. Whether a managed option is the right choice depends on who owns backups and whether your team can run restore tests. Ask for the database design to be written into the scope so that ownership is clear after go-live.
How are cost and effort split between setup and recurring upgrades?
Setup is one-time work. It covers cluster configuration, ingress and storage, database and cache setup, backups, initial organizations, courses, theming, SSO if it is in scope, and testing before go-live. Recurring work covers cluster and database operations, Tutor and Open edX release upgrades, dependency updates, monitoring, backup restore tests, plugin compatibility checks and support. The main drivers are the number of custom XBlocks, plugins and theme depth, the number of integrations and identity providers, the number of environments, and any compliance evidence you must produce. Cloud and hosting charges are paid to your provider, while labor is paid to whoever builds and operates the platform. DeployOpen does not publish a price list, and a quote follows from the written scope. Ask for a quote that separates one-time and recurring lines and states its assumptions.
How long does an Open edX Kubernetes deployment take to complete?
No duration is published for this work, and the timeline depends on the agreed scope. The main drivers are how many environments you need, whether the cluster and databases already exist, how much custom code must be ported or tested, how many identity providers are involved, and how quickly your team can review and sign off each phase. Ask for a scoped estimate that lists phases such as environment build, Tutor configuration, data and database setup, integration testing, load checks, cutover and handover. Ask which tasks depend on your access or approvals, because those often set the critical path. Verawood is the current named release, published on 30 July 2026, and Willow and Xylon are listed for December 2026 and June 2027. Confirm which release you will target at kickoff, since that choice affects the test plan.
How do Open edX release upgrades work inside a Kubernetes cluster?
Open edX supports only the latest named release, so upgrades form a recurring cycle that your team should plan for from the start. A typical cycle selects the target release and the matching Tutor version, rebuilds images with your plugins and themes, and deploys to a staging environment with a recent copy of production data. The upgrade owner then checks custom XBlocks, plugins, themes and integrations, runs database migrations and confirms that backups can be restored before the production change. Production rollout happens through the cluster with a documented rollback plan and a monitoring check afterward. Custom code is the most common source of delay, so keep it small, tested and documented. Ask any partner to show how its upgrade runbook covers each of these steps.
When does a retainer make more sense than an internal team?
A retainer tends to fit when the platform is business-critical but your internal team cannot cover upgrades, monitoring and security patching at the pace the release cycle requires. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, separate from the fixed-scope build. An internal team tends to fit when it already runs Kubernetes and managed databases at the standard you require, has Django and Python skills, and can staff a named upgrade owner. Compare the recurring hours for upgrades, monitoring, backup restore tests, plugin maintenance and incident response against your team's capacity. When you request a retainer, ask what is covered, which environments are included, how response is handled, who performs Tutor and release upgrades, and what triggers a separate quote. Retainer terms are set in writing before work begins.
How DeployOpen scopes, builds and hands over a Kubernetes deployment
DeployOpen plans, implements, hardens, documents and supports Open edX inside your own cloud accounts, data centers or air-gapped networks. For Kubernetes, we work from Tutor's Kubernetes deployment support and agree the cluster design, data services and release process with your team before any build begins.
How we scope
- Agree the written scope covering the Tutor-based Kubernetes cluster, LMS and Studio workloads, and worker components.
- Record the managed MySQL, MongoDB, Memcached or Redis, object storage and ingress decisions your environment requires.
- Confirm the named Open edX release to deploy, since only the latest named release is supported, and the upgrade path expected after go-live.
How we build
- Configure Tutor for Kubernetes, with plugins, secrets handling and a shared Django cache backend for multi-node operation.
- Test scaling of LMS and worker replicas, persistent storage, ingress and TLS, and backups against recovery steps your team agrees.
- Check any custom XBlocks, plugins and themes against the chosen release before they are included in the cluster build.
How we hand over
- Deliver the deployment repository, Tutor configuration, cluster manifests and environment-specific settings under your version control.
- Provide runbooks for scaling, backup restoration, release upgrades and rollback, written for the engineers who will operate the cluster.
- Walk your platform and operations team through the deployed system and the verification results against the agreed acceptance criteria.
How we support
- Offer ongoing support, upgrades and continuous testing through a retainer, separate from the fixed-scope build.
- Plan each named release upgrade and retest the custom code and cluster configuration before changing production.
- Confirm with us in writing what post-go-live support, response expectations and upgrade work the retainer includes.
