Which Open edX deployment model fits your team
Choose Tutor local when one server can carry the program and your team has general system administration skills. Tutor's local install was designed so that people with no prior system administration experience can launch a platform, and it runs the same Docker images that power the Kubernetes option. This suits a single program, a pilot, a training environment or a course catalog with modest learner numbers, where one host, one set of backups and a short list of operators is enough. The trade-off is that the single server is also your single failure domain, so you need a tested restore procedure and a clear view of how much downtime the program can absorb. Confirm your expected concurrent learner load with the Tutor project and your own load tests before committing to one host.
Choose Tutor on Kubernetes when the platform must run as a production service with redundancy, scaling and a cluster your organization already operates or intends to staff. Tutor's own documentation says that a single server and a Kubernetes cluster are two very different things and that managing a Kubernetes platform is a fairly advanced endeavour. Before you pick this path, check that you can supply nodes with at least 4 GB of RAM each, a DNS-managed or self-supplied load balancer in place of the default LoadBalancer service that exposes Caddy, and shared storage through the MinIO plugin, which Tutor says a production cluster will most certainly need. You also need people who can operate the cluster itself, including upgrades, etcd backups and access control for Secrets. If that skill set is not in-house, the operating effort moves onto your team or onto a support arrangement that you should price before deciding.
Tutor local and Tutor on Kubernetes side by side
This table compares the two Tutor deployment modes across runtime, node sizing, networking, storage, skills and support. Read it as a checklist: the rows marked for confirmation are areas where the supplied documentation does not give a figure, so ask Tutor or your own environment before committing. The main takeaway is that both modes run the same Docker images, and the difference lies mostly in the operating skills and infrastructure you take on.
| Factor | Tutor local (single server) | Tutor on Kubernetes (tutor k8s) |
|---|---|---|
| Runtime model | Single server running Open edX through Docker containers | Same Docker images scheduled as pods across a Kubernetes cluster |
| Intended operator | Designed so users with no prior system administration experience can launch a platform | Tutor's docs call managing a Kubernetes platform a fairly advanced endeavour |
| Node memory minimum | Not stated in the supplied Tutor docs; confirm the server sizing for your course load | At least 4 GB of RAM on each node |
| Load balancer and DNS | Single host entry point; confirm the ingress and TLS setup you need | Deploys a LoadBalancer service for the Caddy web proxy by default; point DNS at it or replace it with your own load balancer |
| Shared storage | Local filesystem on one server; no shared volume is needed between pods | Shared storage through the MinIO plugin for S3-compatible storage; Tutor says a production cluster will most certainly need it |
| Skills required | Docker and basic server administration | Kubernetes operations, RBAC, secrets handling, etcd and control plane care, plus Open edX operations |
| Upgrade path | Follow Tutor and Open edX release changes on one host; confirm the upgrade steps for your version | Upgrade the Kubernetes control plane one minor version at a time, then nodes; Kubernetes 1.35, 1.36 and 1.37 are the supported minors as of September 2026 |
| Who supports the install | Community support for Tutor, which Edly maintains and offers with professional support; confirm scope with Edly or your partner | Same Tutor support model, plus whoever runs your cluster; confirm who owns cluster incidents and patching |
Why the same images still mean two different jobs
The Tutor Kubernetes documentation says the same Docker images power single-server and Kubernetes deployments, but it also says that running Open edX on one server and running it in a cluster are two very different things. The image is the part that is identical. What differs is everything around it: the nodes, the load balancer, the shared storage, the database and cache tier, the backups and the people who operate them. Before you choose a target, treat the container image as a shared starting point and size the surrounding platform as a separate project. The local install was designed so that users with no prior system administration experience can launch a platform. That is the job Tutor's single-server path is built for: a pilot, a sandbox, a development environment or a small course site that one or two people can run and reason about. The Kubernetes docs also describe managing a Kubernetes platform as a fairly advanced endeavour. If your team cannot yet explain how a pod is scheduled, how a persistent volume claim binds to storage and how a failed node is replaced, that gap is a decision point, not a footnote.
The hard part is not the image. It is the platform that keeps a learning site available while learners, instructors and course content move through it. Before committing, ask who will own node patching, certificate renewal, etcd or cluster upgrades, database backups and restore tests, and the on-call rota for a course launch. Confirm with your platform team which of these skills already exist in-house and which would need to be contracted or trained. Write those answers down before you size the cluster, because they determine whether the Kubernetes path is a deployment choice or an operating commitment your organization must sustain for years.
What a Tutor Kubernetes cluster needs before the first deploy
A Tutor deployment on Kubernetes depends on the cluster underneath it as much as on Open edX itself. The cards below cover the node sizing, the public entry point, the shared storage and the self-managed control plane that your team has to own before the first deploy.
Node memory floor
Tutor on Kubernetes needs at least 4 GB of RAM on each node. That is a minimum, not a sizing guide, because the LMS, Studio and supporting services compete for memory under real course traffic. Ask your platform team to size nodes for peak load and to confirm how the cluster autoscaler or node pools will add capacity when a node is lost.
Public entry through the Caddy proxy
By default Tutor deploys a LoadBalancer service that exposes the Caddy web proxy. Your DNS records for the LMS and Studio hostnames must point at that address, or you must replace it with your own load balancer and route traffic to Caddy yourself. Confirm who owns the cloud load balancer, the TLS certificates and the DNS change process before the first deploy.
Shared storage through MinIO
Sharing one filesystem across pods needs ReadWriteMany persistent volume claims, which the Tutor documentation describes as difficult to set up. Its recommendation is the MinIO plugin for S3-compatible storage, and it states that a production Kubernetes platform will most certainly need it. Plan the object storage backend, its own backups and its access keys as part of the platform scope, not as an afterthought.
Highly available control plane
A self-managed cluster built with kubeadm uses either a stacked control plane, with etcd on the same nodes, or an external etcd cluster. The kubeadm guide calls for at least three control plane nodes behind a TCP load balancer on port 6443. Etcd should run with an odd number of members, and the etcd documentation recommends five members in production. Confirm whether your team will run this or buy a managed control plane.
Etcd backup and restore plan
Etcd holds the cluster state, so losing it can mean rebuilding the platform. The Kubernetes documentation requires a backup plan for etcd data, uses etcdctl snapshot save for backups and etcdutl for restores. Schedule the snapshots, store them away from the cluster, and rehearse a restore on a non-production cluster before you rely on it.
Choosing by team and program situation
A small team that wants to evaluate Open edX, run a pilot course or stand up a sandbox for instructional design usually fits Tutor local. Tutor describes its local install as designed so that users with no prior system administration experience can launch a platform, and the same Docker images back both models, so a pilot built on one server does not change the application layer. The cost of this path is mostly the time of the people who run it and the server you give it.
- Skills required: Comfort with Docker, Linux administration and DNS, plus one person who owns upgrades and backups.
- Scope: A proof of concept, a limited course catalog or an internal training environment.
- Exit path: Plan how content, users and databases would move if the pilot becomes production, since a single server is not a high availability design.
- Illustrative example: A training team with one administrator runs a pilot for a few internal courses on a single virtual machine.
Before committing, confirm with your hosting provider how backups, restores and resizing work for that machine, and confirm the Tutor version and Open edX release you will track against the Open edX release notes.
An institution that already runs Kubernetes clusters, with platform engineers who handle ingress, storage classes, secrets and upgrades, is the case where Tutor on Kubernetes tends to fit. Tutor's Kubernetes documentation says that running Open edX on a single server and in a Kubernetes cluster are two very different things, and that managing a Kubernetes platform is a fairly advanced endeavour. A team that already carries that load adds Open edX as one more workload, while a team without it takes on a second discipline.
- Skills required: Operating a cluster, managing persistent volumes, configuring a load balancer and handling Secrets with least-privilege RBAC.
- Storage: Plan for shared object storage, since the Tutor docs recommend the MinIO plugin for production.
- Networking: Each node needs at least 4 GB of RAM, and the default LoadBalancer service exposes Caddy, which DNS or your own load balancer must reach.
- Illustrative example: A university platform team that already runs a production cluster deploys Open edX as a separate namespace.
Confirm the Kubernetes minor versions your platform supports against the Kubernetes releases page and your provider's upgrade calendar before you commit.
An organization with application owners but no staff who operate Kubernetes should weigh the Kubernetes path carefully. Tutor's own guidance points to the single-server install for users without system administration background, and a production Kubernetes platform adds cluster upkeep, etcd backups and control plane decisions that the Open edX team would own. DeployOpen can plan, implement and support either path within the client's infrastructure, but the choice of model should follow the team that will run it day to day.
- Skills gap: Cluster upgrades must follow the version skew rules, and etcd must be backed up if a self-managed control plane is used.
- Alternative: A managed Kubernetes service from your cloud provider reduces control plane work, but it still needs your own owner for Tutor configuration.
- Support: Ask whether a retainer covers upgrades and monitoring, since that work recurs after go-live.
- Illustrative example: A corporate learning team with no cluster staff evaluates a single-server build with a documented upgrade routine.
Before committing, ask who will perform each upgrade, restore and security patch, and what that person's time costs over the life of the platform.
A regulated organization that must show availability, backup and access control evidence will care most about how the production model is owned. Tutor on Kubernetes is documented as the path for production clusters, but the team must be able to produce evidence for each control, such as encryption at rest for Secrets, restricted access to list and watch operations and tested restores. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or attestation.
- Evidence: Keep records of backups, restores, RBAC reviews and upgrade history.
- Secrets: Kubernetes stores Secrets unencrypted in etcd by default, so encryption at rest must be configured.
- Authentication: Map the cluster's identity model and Open edX's third-party providers to the organization's identity standard.
- Illustrative example: A bank's training group runs a production cluster under the same change control as its other platforms.
Confirm with your assessor which controls and evidence formats they expect before you choose the model.
A program that serves several departments, partners or regions may need separate environments for development, staging and production, with some teams holding different responsibilities. In this situation the choice often turns on whether the central platform team can run separate clusters or namespaces for each environment, and whether individual teams need their own sandboxes. The local model suits isolated sandboxes, while the Kubernetes model suits shared production with several environments under one operator.
- Environments: Decide how many production and non-production instances you need and who may deploy to each.
- Isolation: Separate tenants by namespace, cluster or server, and document which model you chose.
- Capacity: Each Kubernetes node must meet the 4 GB minimum, so count nodes per environment when you size hardware.
- Illustrative example: A regional program runs a shared production cluster and single-server sandboxes for partner trainers.
Ask your implementation partner to write the environment model into the scope before work begins, since it drives both cost and effort.
How to move from a single server to a cluster later
The sequence takes an install that runs on one server with tutor local and moves it to a Kubernetes cluster with tutor k8s, ending in a platform whose data, DNS and restores have been tested. Each step produces a check that tells you whether the next one can start.
Confirm the Kubernetes skills in your team
Before any node is provisioned, the platform or operations lead confirms that someone on the team can run a Kubernetes cluster day to day. Tutor's Kubernetes documentation says that running Open edX on a single server and in a cluster are two very different things, and that managing a Kubernetes platform is a fairly advanced endeavour. Check that named people can handle cluster upgrades, RBAC, pod troubleshooting, persistent volumes and etcd backups. The step is done when the team can name who owns each of those tasks and has a written plan for covering absences.
Size the cluster nodes against the minimum
The platform team selects node sizes and counts for the target cluster. Tutor's Kubernetes documentation requires at least 4 GB of RAM on each node, which is a floor and not a sizing estimate. Size for your expected learner concurrency, Studio authoring load and the add-on services you plan to run, then confirm the figures with the Tutor documentation and your own load tests. The step is done when a written sizing sheet lists node count, memory and CPU per node, and the reasoning behind each number.
Plan DNS and the load balancer
The network owner decides how traffic reaches the cluster. By default, Tutor on Kubernetes deploys a LoadBalancer service that exposes the Caddy web proxy, and DNS records must point at that address. If your environment requires a different load balancer, you replace the default with your own and point DNS at it. Record the TLS certificate process, the public address and the cutover window with the operations team. The step is done when DNS records and the chosen load balancer are documented and a test record resolves to the new endpoint in a non-production environment.
Move media to S3-compatible storage
The engineer moves uploaded media and other shared files from the single-server filesystem to S3-compatible storage. Tutor's documentation explains that sharing one filesystem across Kubernetes pods needs ReadWriteMany persistent volume claims, which are difficult to set up, and recommends the MinIO plugin for S3-compatible storage. It also says a production Kubernetes platform will most certainly need it. Confirm the plugin's current configuration steps in the Tutor documentation before you start. The step is done when a test upload from Studio is readable from the cluster and the storage bucket holds the expected objects.
Migrate data and reconcile customizations
The platform team copies the database and the data the platform depends on into the cluster environment, then reviews every customization and plugin on the single server. Each one needs a decision: keep it as a supported plugin, rebuild it, or retire it. The cost of this step depends on how much data you hold, how many customizations you run and how many plugins depend on the single-server layout, so it is the least predictable part of the sequence. Ask Tutor's maintainers, Edly, or your implementation partner to confirm the supported migration path for your version before you commit to a schedule. The step is done when a written inventory lists every customization with its disposition and the migrated data passes a row-count and login check.
Test restores on the cluster before cutover
The operations engineer runs a full restore of the latest backup into a separate cluster namespace. Kubernetes documentation says etcd needs a backup plan, and Open edX data needs the same discipline, so restore the platform database and the object storage together and check that they still agree. Record how long the restore took and which steps were manual. The step is done when a restored copy starts, serves courses to a test learner and returns the expected enrollment and grade data. Keep the restore runbook with the cutover plan.
Cut over DNS and retire the single server
The operations lead schedules the cutover with the business owners of the course content and confirms a rollback path back to the single server. On cutover day, the team points DNS at the cluster, runs smoke tests on enrollment, course playback and Studio publishing, and watches logs and resource use. The single server stays available until the rollback window closes. The step is done when smoke tests pass, monitoring shows steady resource use, and the team signs off in writing. Only then should the single server be decommissioned and its backups archived.
Upgrades, backups and monitoring for each model
This table compares what keeps each Tutor model current, backed up and watched after go-live. Read it as a list of recurring jobs, then confirm the Tutor-specific upgrade steps with Tutor or your own test environment before you commit to either model.
| Operating area | Tutor local (single server) | Tutor on Kubernetes |
|---|---|---|
| Open edX release tracking | Open edX supports only the latest named release, so plan an upgrade to Willow after its December 2026 date and to Xylon after its June 2027 date. Verawood is the current release. | Same Open edX release rule applies. The cluster adds a second upgrade track for Kubernetes itself, so both must be scheduled together. |
| Kubernetes version cadence | Not applicable to the host OS work on a single server, which follows your normal OS patch process. | Kubernetes ships about three minor releases a year on a cycle of about 14 weeks. The project maintains the three most recent minors, so plan a minor upgrade roughly every few months. |
| Upgrade order and version skew | Upgrade the Tutor deployment and host together in a staging copy first. Confirm the exact procedure in the Tutor documentation for your version. | The skew policy requires the API server to move one minor at a time, before controller manager, scheduler and kubelets. Kubelets may be up to three minors behind, which gives a staged rollout window. |
| Backup scope | Back up the MySQL and MongoDB data, the media and file storage, and the Tutor configuration and secrets on the server. Restore testing is the step most often skipped. | Back up the databases and object storage (for example, MinIO data), the Tutor configuration, and the etcd cluster state. Etcd backups use etcdctl snapshot save and restores use etcdutl. |
| Secrets handling in backups | Protect the local config and secret values on the server disk and in backup copies. | Kubernetes Secrets are stored unencrypted in etcd by default. Confirm encryption at rest is enabled, because etcd snapshots will contain those values. |
| Monitoring focus | Host CPU, memory, disk and the health of the web, worker and database services. Alerts usually come from host-level tooling you add yourself. | Node memory against the 4 GB minimum, pod restarts, load balancer health, persistent volume and object storage capacity, and etcd health. Confirm which tooling your Tutor version wires in by default. |
| Operating skills required | General Linux administration, Docker operation and the ability to read Tutor logs. The local install is designed for users without prior system administration experience. | Kubernetes administration, including RBAC, certificates, etcd operations, upgrades and troubleshooting. Tutor's own docs describe managing a Kubernetes platform as fairly advanced. |
| Who you need on call | Often one trained administrator with a documented restore procedure. | At least two people who can run cluster upgrades and etcd restores, since a single operator is a single point of failure. |
The Kubernetes skills a production cluster needs
Running Tutor on Kubernetes in production means owning a set of skills that the single-server path never asks for, and the Tutor documentation is direct that managing a Kubernetes platform is a fairly advanced endeavour. Start with version upgrades under the skew policy: kube-apiserver must be upgraded one minor version at a time and before kube-controller-manager, kube-scheduler and kubelets, and kubelets may be up to three minor versions older than the API server. Kubernetes maintains only the three most recent minor releases, so your team needs a fixed upgrade calendar tied to the Kubernetes releases page, plus a staging cluster where each Open edX release is tested before production moves.
Next, plan etcd backup and restore and the control plane behind it. The kubeadm high availability guide describes a stacked or external etcd topology with at least three control plane nodes and a TCP load balancer in front of port 6443. Kubernetes recommends an odd member count, five members in production, and uses etcdctl snapshot save for backups and etcdutl for restores. Confirm who runs these snapshots, where they are stored, and whether a restore has been rehearsed. A backup that has never been restored is not yet a recovery plan.
Then settle authentication, RBAC and Secrets. Kubernetes does not store normal users as API objects, so identity comes from X.509 certificates, OpenID Connect or other bearer tokens, or an authenticating proxy, and each choice must be tied to your directory. Grant least-privilege RBAC, restricting list and watch on Secrets. Secrets are stored unencrypted in etcd by default, so enable encryption at rest or use an external store through the Secrets Store CSI Driver. Apply Pod Security Standards to the namespaces that run Open edX, and use the CIS Kubernetes Benchmark as the working reference for hardening controls, reading its control IDs and titles with your own auditors. Confirm conformance with the CNCF program if you choose a distribution. These skills apply whether your team runs the cluster or a partner does, because the accountability for access, backups and patching stays with the owner of the data.
Questions buyers ask before choosing a deployment model
What drives the cost of running Open edX with Tutor on one server versus Kubernetes?
The main cost difference is the work to build and keep a cluster running, not the software, which is open source under AGPL-3.0 in both cases. A single server needs one host, storage, backups and patching. A Kubernetes platform adds nodes with at least 4 GB of RAM each, a load balancer or DNS records for the Caddy web proxy, shared object storage through the MinIO plugin, and the people to operate it. Setup work is largely one-time, while cloud or data center capacity, monitoring, backups, upgrades and support recur. Ask any quote to split one-time build work from recurring operations, and to list which infrastructure is billed by you and which by the provider.
How long does it take to launch Open edX on Tutor?
No supplied fact gives a duration for either path, so treat any timeline as something to confirm in writing. The schedule depends on how many environments you need, whether you have cloud accounts and DNS ready, how much theming and integration work is in scope, and how quickly your team can review and test. Tutor's local install was designed so that users with no prior system administration experience can launch a platform, which suggests a single-server pilot can start sooner. A Kubernetes production platform takes longer because the cluster, storage, load balancing and backups must be built and tested first. Ask for milestones tied to environment handover and acceptance tests.
Can a team with no Kubernetes experience run a production Open edX cluster?
Usually not without added skills or outside help. Tutor's Kubernetes documentation says that running Open edX on a single server and in a Kubernetes cluster are two very different things, and that managing a Kubernetes platform is a fairly advanced endeavour. A production cluster needs people who can handle cluster upgrades, which follow a version skew policy that requires moving kube-apiserver one minor version at a time, plus etcd backup and restore, certificate-based and token-based authentication, and secrets protection. A team new to these areas can run a single-server Tutor install and learn in a staging cluster, but should confirm skills or hire support before it owns a production cluster.
What does the work require from our own staff?
Expect ongoing time from named owners even when an outside team builds the platform. Plan for someone who owns the Open edX application and course content, someone who owns infrastructure and access, and someone who answers for security and data protection. For a Kubernetes path, the infrastructure owner needs to understand the control plane topology, which the kubeadm high availability guide describes as stacked etcd or external etcd with at least three control plane nodes behind a TCP load balancer on port 6443. Ask the provider to name which tasks it performs, which tasks your staff perform, and how handover and documentation will work.
When should we bring in outside help for an Open edX deployment?
Bring in outside help before the first production decision, not after an incident. Good triggers include choosing between single-server and cluster designs, configuring identity integration with SAML 2.0, Shibboleth or OAuth2 providers, setting up encryption at rest for Kubernetes Secrets, and running a backup and restore test for etcd. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers.
What should a written scope include for a Tutor deployment?
A written scope should name the target (single server or Kubernetes), the environments, the hosting accounts and who owns them, the identity providers, the storage design, the backup and restore procedure, and the hardening baseline. For Kubernetes, ask whether the scope covers the cluster itself or only the Open edX application on top of a cluster you already run, and whether it includes the load balancer and DNS work. Ask for acceptance criteria, the handover documents, the upgrade approach for the Open edX release line, and what happens to the work if a dependency changes. DeployOpen does not publish a price list, so a quote follows from this written scope.
How does the choice of deployment model affect a later move between them?
Moving from a single server to Kubernetes is possible because both paths use the same Docker images, but the surrounding work is not a simple copy. Storage changes from local volumes to shared object storage through the MinIO plugin, the network path changes from a direct host to a LoadBalancer service fronting Caddy, and backups must move to the cluster's data handling. Data also needs a restore test in the target environment. Ask any provider to document data export, configuration location and a rehearsed cutover, and to state which parts of the Open edX release line carry over during an upgrade.
What to confirm with Tutor and your own environment
Start by confirming that the Tutor release you plan to deploy supports the Open edX named release you intend to run. Open edX states that the latest named release is the only supported release, and Tutor plugins are maintained separately from the platform, so a plugin that worked on the previous release may lag behind the current one. Check the plugin index and each plugin's compatibility notes against the exact Tutor version, then test every plugin you depend on in a non-production cluster before you upgrade. The Tutor documentation is the place to start, and Edly is the party to ask about professional support if a plugin you need has no clear maintainer.
Next, confirm which managed Kubernetes service your cloud provider offers, its supported control plane versions and how it handles node pools, load balancers and persistent volumes. Tutor on Kubernetes expects a LoadBalancer service that exposes Caddy, and the way your provider provisions that load balancer, along with its DNS and TLS handling, changes the setup steps. Also confirm who patches the control plane and how long your provider keeps each Kubernetes minor version available, since that sets your upgrade calendar. For backups, decide who owns the database dump and restore process for MySQL and MongoDB, how media stored in the MinIO plugin is replicated, and how you will test a full restore. Ask your storage team for recovery point and recovery time targets, because none of these are settled by the supplied documentation.
Finally, confirm how learners will sign in and how many of them you must support at the same time. Open edX third-party authentication supports OAuth2 providers, SAML 2.0, Shibboleth and LTI, so the identity provider you use determines the settings you configure and the claims you must map. Verify the setup with your identity team in a staging environment, including account linking and deprovisioning. For concurrent learners, no capacity figure is given here. Load test the LMS and Studio with representative course content, measure database, cache and media throughput under peak load, and size node memory and replica counts from those results rather than from assumptions. Ask Tutor, your hosting provider and any service partner to put these answers into the written scope before work begins.
How DeployOpen scopes and supports Open edX deployments
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Open edX on Tutor, that means choosing between a single-server install and a Kubernetes cluster against your real requirements, then building and handing over whichever path the written scope defines.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope states whether Tutor runs on one server or a Kubernetes cluster, and why.
- Scope covers node sizing, load balancer and DNS arrangements, and shared storage through the MinIO plugin where needed.
How we build
- Builds use the same Tutor images in your environment, with configuration, plugins and identity integration set per the scope.
- Kubernetes builds cover control plane topology, etcd backup planning, secrets encryption at rest and RBAC.
- Security testing of the deployed platform is available as a separate scoped engagement if the written scope includes it.
How we hand over
- Handover documentation records the chosen topology, versions, configuration keys and the upgrade path for your team.
- Backup and restore procedures are documented and handed over as part of the written deliverables.
- Your team can confirm skill gaps, such as Kubernetes operations, before the handover is accepted in writing.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrades follow the named Open edX release cycle, with the latest named release as the supported target.
- Ask any provider, including DeployOpen, to confirm in writing which release, cluster version and operator responsibilities the support covers.
