Open edX Tutor deployment guide for one server

How to deploy Open edX with Tutor on one server

Tutor is the officially supported Docker-based Open edX distribution, and one server can run a production LMS and Studio for an initial learner population, provided configuration, TLS, backups and plugin choices are settled before go-live. The quick-start gets a site running, but it does not decide who owns the host, the DNS records, the certificate renewals or the backup schedule. Assign each of those to a named person or team before installation, because the single-server setup will not make those decisions for you.

The first hard part is configuration. Tutor generates a configuration file and secret values that the running services depend on, so these belong in a secrets store outside the server, not only on the host itself. Record which settings you changed by hand, and keep those changes under version control so an upgrade or rebuild can reproduce them. DNS and certificates are the second part. The LMS and Studio each need their own hostname, and certificate renewal must run without a person remembering to do it. Test the renewal path on a staging host before the production date.

Backups are the third part, and they cover more than one store. The LMS and Studio data lives in MySQL, course structure and content sit in MongoDB, and uploaded media and any analytics stores need their own copies. Schedule each one, keep copies off the host, and run a full restore into a separate environment at least once before launch. Plugin version drift is the fourth part. Open edX supports only the latest named release, and Verawood, published on 30 July 2026, is the current one. Pin your Tutor version and every plugin to the release you deploy, and confirm plugin compatibility with the Tutor documentation before any upgrade.

The upstream 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. Plan the host accordingly. One server is a sound starting point for an initial population, but multi-node deployments need a shared Django cache backend such as Redis or Memcached. That requirement is the first point where a single host stops being the simple answer. Ask your team which cache you will use, where it will run, and whether it belongs in the initial plan or in a later phase.

Which Tutor and Open edX components run on the host

A single-host Tutor install packs the learner site, the authoring tool, the databases and the cache onto one machine. Each piece holds different state, so backups and configuration changes have to cover all of them together.

LMS and Studio services

The LMS serves learners and the Studio (CMS) service serves course authors. Both are built from edx-platform, which is licensed under AGPL version 3 and written in Python and Django. They share the same codebase version, so they should be upgraded together. Confirm which edx-platform release your Tutor version pulls before you plan the install window.

MySQL 8.0 relational data

MySQL 8.0 holds the core relational records, including user accounts, enrollments, course metadata references and grades. Losing it means losing learner progress and account links, so it needs scheduled dumps that are restored and tested. Confirm the MySQL 8.0 version that your Tutor release deploys, because the database image is set by Tutor and not by your team.

MongoDB 7.x course content

MongoDB 7.x stores course structure and content modules as authored in Studio. A backup of MySQL without the matching MongoDB snapshot leaves courses and learner records out of step. Take both databases from the same maintenance window and record the MongoDB 7.x image tag your Tutor release uses.

Memcached cache layer

Memcached holds short-lived cached data for the LMS and Studio. It is not a system of record, so losing it only causes a slower restart, but it must be reachable by both services. On a single host, check that its memory limit suits your expected concurrent sessions, and confirm the Memcached version with your Tutor release.

Tutor configuration and overrides

Tutor keeps its settings in a config.yml file under the data directory, and environment overrides add or replace values on top of it. Generated secrets and hostnames live here, so this directory belongs in the backup set and in version control with restricted access. Any manual edit to generated files is lost on the next Tutor render.

Tutor plugin hooks

Tutor's plugin and hooks system is licensed under Apache 2.0 and lets you add services, settings and templates without editing upstream code. Each installed plugin changes what Tutor renders, so record the plugin name and version alongside the config. Review every plugin before install and retest it after each Tutor upgrade.

Decisions to settle before the first install

This table compares the five choices that shape an Open edX Tutor build: where the databases live, where TLS ends, where backups go, how custom code is held, and which runtime target you start with. Read each row as a fork: the right-hand columns show when each option fits and what it adds to patching, certificate renewal, restores and upgrades. The main takeaway is that the bundled single-host layout is quickest to start, while the external and Kubernetes options cost more to run but move the operational burden to places you can staff and monitor.

Decision	Option A and when it fits	Option B and when it fits	Operational cost to weigh
Databases (MySQL and MongoDB)	Tutor bundled services on one host fits a pilot, a small learner base or a team that wants one system to run and restore.	External managed MySQL 8.0 and MongoDB 7.x fits a team with database operators, larger learner volumes or a need for independent backup and failover.	Bundled services mean you patch the database engines and tune them on the same host. External services add network configuration, credentials handling and a cost line from the provider, which you should confirm in writing.
TLS termination	TLS on the host, with certificates handled by Tutor's proxy setup, fits a single-server deployment with one owner for certificates.	TLS at an upstream load balancer fits organizations that already manage certificates centrally or that need the load balancer for other services.	On the host, you own renewal and reload failures. At a load balancer, you must confirm forwarded headers and secure cookie settings reach the LMS and Studio correctly.
Backup location	Backups kept on the host fit a first deployment where the restore path is short and you are still learning the tooling.	Backups shipped off the host to separate storage fit any deployment with a recovery objective your organization has written down.	On-host backups fail with the host. Off-host backups need storage, retention rules, encryption keys and a restore test, which is the effort most often skipped.
Custom code: plugins or a fork	Tutor plugins and hooks fit most branding, settings and integration changes and keep the upgrade path to a new Tutor release simple.	Forking edx-platform fits changes that no plugin or frontend plugin slot can reach, but every change must be merged forward through each named release.	Plugins are re-tested on each Tutor upgrade. A fork is rebased on each Open edX release, and only the latest named release is supported, so fork drift carries a recurring labor cost.
Runtime target	Docker Compose on one host, using Tutor's default, fits a single-server build with a small operations team and clear capacity limits.	Kubernetes from the start, using tutor k8s, fits a planned multi-node build, scaling needs for LMS and workers, or an existing cluster team.	Compose is simpler to upgrade but has one failure domain. Kubernetes adds cluster patching, storage classes, ingress and scaling policy, which need an owner before go-live.

Build sequence from server to first learner login

This sequence takes a single Docker host from a bare server to a working Open edX site that a test learner can sign into. Each step closes with a check, so a fault is caught before the next layer depends on it. The last checks confirm that a restore from a test backup works before any learner data arrives.

Prepare the host and DNS records
Your infrastructure team provisions a Linux server in your own cloud account, data center or private network, sized for the pilot you plan to run, and opens only the ports you need. Create DNS records for the LMS domain and the Studio domain, pointing both at the server address. Confirm the host has a stable address, enough disk for container images and course media, and outbound access for package downloads. The step closes when both names resolve to the server from inside and outside your network.
Install Docker and Tutor
The platform team installs Docker Engine and the Docker Compose plugin on the host, then installs Tutor, the official Docker-based Open edX distribution, using the method its documentation describes for your operating system. Record the Docker and Tutor versions in your change log, because later upgrades depend on them. The step closes when the Docker daemon runs for the operator account and the Tutor command reports its version.
Initialize configuration and set domains
Run Tutor's configuration initialization, then set the platform domain to the LMS name and the Studio domain to the CMS name your DNS records use. Set the platform name, the contact address, the default language and the first administrator account. Generated secrets stay in the Tutor configuration store, and read access on the host is restricted, because these values reach every container. The step closes when the rendered configuration shows the expected domains and admin settings.
Add plugins and pin versions
Install only the plugins the project requires, obtained from sources your security reviewer has approved. Pin each plugin to an exact version in the configuration, and record it alongside the Open edX release and Tutor version, so a rebuild produces the same images. Leave out any plugin that is only needed for a later phase. The step closes when a fresh configuration render lists each plugin at its pinned version and no others.
Run initial configuration and start stack
Run the initial configuration step so Tutor builds images and prepares the data services, then start the stack. The first start takes longer than later starts because containers pull images and initialize their stores, and the database services must be healthy before the LMS and Studio come up. Watch container health and the LMS and Studio logs for errors. The step closes when all services report healthy and the LMS and Studio respond on their internal ports.
Configure HTTPS and certificate renewal
Place the LMS and Studio behind TLS with certificates issued for both names, using a certificate authority or ACME client your security team approves. Confirm which proxy your Tutor version routes through, that it forwards the original host and protocol headers, and that plain HTTP redirects to HTTPS. Schedule renewal, test it with a dry run, and add an alert for certificate expiry. The step closes when both domains serve valid certificates from outside your network and a renewal dry run completes.
Confirm first login and publishing
Create a test learner account and a staff account, then sign in to the LMS and Studio over HTTPS. As the staff account, create a short test course, add one unit with text, and publish it. Enroll the test learner and open the course from the learner view. Record each action in a written checklist that the project lead signs. The step closes when the learner signs in, sees the published course, and Studio shows no errors during authoring.
Restore a test backup before loading data
Take a backup of the running stack using the backup process documented for your Tutor version, store it outside the server, and restore it to a second host or a clean environment. Compare the restored course, the test accounts and the media files with the originals. Only after this restore succeeds should learner data be loaded or any migration begin. The step closes when the restored environment matches the source for the test records and the restore steps are written into your runbook.

What drives the effort of a single-server Tutor deployment

This table lists the factors that most change the work on a single-host Open edX Tutor deployment, why each one matters, and how to keep it contained. Read each row as a question to answer before you ask for a fixed-scope quote, since the same scope can shift sharply with any one of them.

Driver	Why it changes effort	How to keep it down and what to ask for in a quote
Number of environments	Staging and production each need the same Tutor configuration, plugins and data shape, and every extra environment adds build, verification and maintenance work.	Keep staging as a copy built from the same Tutor configuration files. Ask the quote to state which environments are included and who maintains each one.
Concurrent learners and course media volume	Single-host sizing depends on peak concurrent learners and video or file volume, which affects server capacity, storage, backups and whether one Docker host stays adequate.	Agree expected peak learners and media size in writing before sizing. Ask the quote to state the sizing assumptions and the point at which high availability would be a separate scope.
Number and maturity of plugins	Each Tutor plugin must be installed, configured, tested against the current release and kept working through upgrades. Newer or less-used plugins carry more unknowns.	Fewer plugins and well-maintained ones reduce effort. Ask the quote to list each plugin, its version, its maintainer and who owns compatibility testing.
Integrations that touch the host (SSO, analytics)	SSO providers, certificates, callback URLs and analytics pipelines such as Aspects add services, secrets and network paths on the same host, each needing its own configuration and tests.	Limit the first release to the integrations the business needs at launch. Ask the quote to name each identity provider, analytics component and the test cases that prove login and event flow.
Data migration from another system	Moving courses, learners and records from another LMS requires mapping, import runs, reconciliation and a rehearsed cutover, often the largest unknown in a project.	Run a scripted import in staging and compare record counts before cutover. Ask the quote to define the source systems, the data to move and the reconciliation method.
Compliance evidence required	Assessors expect documented configuration, access control records, backup and restore evidence and change history. Producing this evidence takes effort on top of the build.	Generate configuration from version-controlled Tutor files and keep a scripted restore test with its results. Ask the quote to list the evidence artifacts and whether DeployOpen prepares them for an independent assessor.
Team skills with Docker and Linux	Operating Tutor on one host requires working knowledge of Docker, Linux services, certificates and logs. A team without these skills needs more handover, documentation and support time.	Plan a handover with runbooks and a practice restore. Ask the quote to state the training, documentation and post-go-live support included, and what your team must do itself.

How the deployment changes by environment

On a single server, Tutor runs the Open edX services as Docker containers on one Docker host, so the LMS, Studio, databases, caches and workers share one machine. This is the simplest supported path and the one most teams use for a first production site or a staging environment. Configuration, installation and backups all live in one place, which keeps the number of moving parts low and makes the upgrade path easier to follow.

The main limits are structural:

Setup: one server, one Tutor configuration and one set of containers to start, stop and back up.
Recovery: a host failure takes the LMS and Studio down together, so restores depend on tested backups of data and media.
Scaling: capacity grows by resizing the host, and learner traffic competes with Studio work for the same resources.
Operations: patching the host, Docker and Tutor falls to your team, and each change needs a planned maintenance window.

Before committing, confirm with your team how the host will be sized for expected concurrency and test the restore procedure in Tutor's documentation against your own data.

Securing the Tutor configuration and host

These controls sit beneath the platform: where Tutor keeps its configuration, who can reach the host, which network ports are open, how HTTPS certificates stay valid, and which plugins enter the build. They connect because a weakness in one exposes the secrets and services the others protect. Django settings, cookies and staff access policy are covered in the Open edX security hardening topic.

Keep config.yml and secrets out of version control

Tutor stores its settings in config.yml and generates secrets, including keys and passwords, when the configuration is created. Do not commit either to a shared repository, even a private one, because anyone with access to the history can recover values long after they were changed. Keep the configuration in a secrets store or an encrypted backup that the operations team controls, and scan the repository history for accidental commits before go-live. Confirm with your Tutor version which generated files contain sensitive values.

Restrict permissions on configuration and secrets

The configuration directory and generated environment files should be readable only by the account that runs Tutor and the administrators who maintain it. Set ownership and file modes explicitly, then check them again after every upgrade or restore, because copy and backup steps often reset them. Confirm which account owns the data directories that containers mount from the host, and whether any other local user or service can read them. Write the expected permissions into the runbook so an auditor can compare the server against it.

Limit SSH and Docker daemon access

Access to the host is effectively root access to the platform, and membership in the Docker group grants root-equivalent control over every container. Restrict SSH to named administrators, require key authentication and disable password logins. Keep Docker group membership to the smallest set of accounts that run Tutor, and confirm the Docker daemon does not listen on a network socket. Review both lists whenever someone changes role or leaves the team.

Close unused ports with a host firewall

Set the host firewall to deny inbound traffic by default, then open only the ports with a stated purpose. Learners need HTTPS, and administrators need SSH from known addresses or a VPN. Confirm whether your certificate method requires port 80, and make sure database, cache and internal service ports are not published to the host. Verify the result from outside the network with a scan that your team is authorized to run, and repeat it after each change to the Tutor configuration.

Certificate handling and renewal

Decide how certificates are issued, stored and renewed before the first learner signs in. The certificate source, whether a public authority, an internal CA or a managed load balancer, determines who renews it and who protects the private key. Document the expiry date, the alert that fires before expiry and the step that reloads the proxy after renewal. Confirm how your Tutor configuration terminates HTTPS, because a renewed certificate on disk does nothing if the proxy keeps serving the old one.

Review third-party plugins before installing

Tutor plugins run code during the build and inside the platform, so each installation is a trust decision. Before installing one, check its source repository, its license, the recent activity of its maintainers and the Open edX release it targets. Pin the version, test it with the same Tutor version used in production, and record who approved it. Code-level review of XBlocks and custom plugins is covered in the Open edX security hardening topic.

How to test the install and prove it fails safely

The install is not finished when Tutor reports that containers are running. It is finished when a defined set of tests passes, the results are recorded, and the team has shown that a failed plugin install or configuration change can be reversed on a copy of the platform before anyone attempts it in production. Start by writing this test plan before go-live, and assign an owner to each test so that results can be signed off by someone other than the person who built the server.

The first group of tests is functional smoke testing of the core services. Log in to the LMS with a learner account and an instructor account, open Studio with an authoring account, create a short test course, add a text component and a video or file component, publish it, and confirm that the published unit appears in the LMS for an enrolled learner. Upload a media asset in Studio and confirm it loads for a learner. Run the same sequence after any plugin or theme change. Record the account types used, the course identifier, and the time and outcome of each step, and keep these test courses out of production reporting.

The second group covers transport and host behavior. Confirm that plain HTTP redirects to HTTPS for both the LMS and Studio domains, that the certificate chain is complete and trusted from a clean client, and that the certificate expiry date and renewal method are documented. Reboot the host and confirm that every Tutor-managed service returns without manual intervention, and that the LMS and Studio respond afterward. Check the Docker restart policies and the host's startup configuration, since a service that only comes back after a manual start will fail silently during a power event.

The third group proves recoverability. Restore the most recent backup into a separate host that has no connection to production learners, then compare learner accounts, enrollments, course structure and the active platform configuration against the source. Confirm that media files resolve and that the restored system can be logged into. Ask the vendor or your own platform team to confirm which databases and volumes Tutor backs up by default in your version, because the restore test is only meaningful if it covers everything your learners depend on, including MySQL, MongoDB and media storage.

The final group tests failure. In staging, install a plugin that is known to fail, or apply a configuration change with a deliberate error, and then follow the written rollback steps exactly as they are documented. Confirm that the platform returns to its prior state, that the smoke tests pass again, and that no data was altered. Evidence to keep includes the test plan with owners and dates, screenshots or logs of each smoke test, certificate check output, reboot test logs, the restore comparison report, the configuration files and plugin list before and after each change, and the rollback transcript. These records are the basis for a go-live decision and for later compliance evidence, which an independent assessor will decide whether to accept.

Operating the host after go-live

A single Tutor host stays healthy only if someone watches it, can rebuild it and knows how releases reach it. The cards below cover the signals to monitor, the data and configuration to back up, the upgrade sequence set by Open edX named releases, and the runbooks that let another engineer act during an incident.

Disk and container health

Tutor runs the LMS, Studio, workers and data services as Docker containers on one host, so disk and container state is the first thing to watch. Alert on free space for the volumes that hold MySQL, MongoDB and media files, since a full volume can stop writes before any error page appears. Also check that every container is running and that restarts stay within what you expect after a reboot or update. Confirm alert thresholds against your own sizing and log growth, because no fixed figure fits every deployment.

Certificate expiry and renewal

HTTPS sits in front of the LMS and Studio, and an expired certificate fails for every learner at once. Track expiry dates for each hostname, including Studio, and alert well before the date. Confirm how renewal runs on your host, whether through a proxy or ingress step you configure yourself, and test that the renewed certificate is served for both the LMS and Studio. Name the owner who receives the alert when a renewal step fails.

LMS error rates

Watch the rate of server errors and failed requests on the LMS and Studio, not only whether pages load. A rising error rate after a configuration change, plugin install or theme update points to the change that caused it. Review container logs for repeated tracebacks, and track login failures separately, because a broken identity provider can look like a learner problem. Record a baseline during the first weeks in production so that a later spike has something to be compared against.

What to back up

Back up the MySQL and MongoDB data, the media storage that holds uploaded course assets, and the Tutor configuration with its plugin list. Also keep the host configuration needed to rebuild the server: operating system setup, Docker setup, DNS records, proxy and certificate settings, and where the secrets are held. Store copies away from the host and confirm that each backup job succeeds. Restore a copy into a separate environment on a regular schedule, because an untested backup cannot be relied on.

Upgrades follow named releases

Open edX supports only its latest named release, so plan upgrades as a sequence of named releases with matching Tutor version changes. Verawood is the current named release, published on 30 July 2026, and Willow and Xylon are listed for December 2026 and June 2027. Before each step, test custom XBlocks, plugins and themes against the target version. The release-by-release path is covered in the upgrades and support topic.

Runbooks the team keeps

Keep a short runbook for each routine task: checking disk and containers, renewing certificates, restoring a backup, rebuilding the host and running a Tutor upgrade. Each entry should name the command or console step, the expected result, the owner and the point at which to roll back. Keep the runbooks in version control beside the Tutor configuration, with secrets kept out of the repository. Review them after each release step so they match the host as it runs.

Questions teams ask before deploying Open edX with Tutor

Is one server enough for a first production Open edX site?

One server can be enough for a first production site with a modest, predictable learner load, but the answer depends on how many learners are active at the same time, how large your course media is, and whether you run analytics. Tutor packages the LMS, Studio, workers, MySQL, MongoDB and Memcached as Docker containers, so a single host is a common starting point. The risks are shared resources: a traffic spike during a live exam can slow Studio authors, a large video upload can fill the disk, and a failed host takes the whole site down until it is restored from backup. Ask your team or your partner to load test a copy of the site with content that resembles your expected courses, and write down the recovery time you can accept. If you plan to run Aspects analytics on the same host, size it separately, because the analytics stack adds its own storage and memory needs.

What must our team own in a Tutor-based Open edX setup?

Your team owns the operational side of the site, including Linux, Docker, DNS, certificates, backups and secrets, even when a partner builds it. Plan for these areas:

Linux administration: patching, user access, firewall rules and disk growth.
Docker: the host runtime, container updates and the Tutor configuration files.
DNS: records for the LMS, Studio and any custom domains, and control of the registrar account.
Certificates: issuance, renewal and the point where HTTPS is terminated.
Backups: where copies are stored, how long they are kept, and a restore you have tested.
Secrets and email: the Tutor configuration holds passwords and keys, and learners need working outbound email.

Name one owner for each area before work starts. Unclear ownership is a frequent cause of delay after handover.

Can our team install Open edX from the official Tutor documentation alone?

Often yes for a single host, if your team already runs Linux servers and Docker and has time to read the configuration reference carefully. The Tutor documentation covers installation, configuration, plugins and HTTPS. The edx-platform maintainers point production operators toward Tutor or a service provider and describe bare-metal installation as complex, with limited community support. The harder work comes after the first install: keeping pace with each named release, testing custom plugins and XBlocks at every upgrade, and restoring from backup under pressure. Ask whether a named person on your team will own those tasks for the life of the site. If the answer is unclear, a fixed-scope engagement can cover the build and hand over documentation and runbooks, and a retainer can cover upgrades and ongoing support.

What should a fixed-scope quote for a Tutor deployment include?

A useful quote states what is built, where it runs, what is handed over, and what is excluded. Ask for these items in writing:

The hosting target, including the cloud account, data center or air-gapped network, and the server specification expected.
The Open edX release and Tutor version, plus the plugins and theme files in scope.
Domains, DNS and the certificate method, and who holds the registrar and certificate accounts.
The backup design, the restore test you will witness, and the retention period you require.
SSO, analytics and custom XBlock work, each listed separately with its acceptance criteria.
Documentation, handover sessions and the access you will hold afterward.
Exclusions, such as content migration, learner data import and post-launch support.

The scope and deliverables should be agreed in writing before work starts, and the price should follow from that written scope.

How long does a Tutor deployment take to complete?

The duration depends on scope, so no single figure applies to every site. Ask for a timeline tied to the written scope. The largest drivers are the number of integrations, such as SSO with a corporate identity provider, which needs access to identity provider administrators and test accounts. Other drivers include the amount of theming and custom code, the volume and format of course content to be loaded, the number of environments such as staging, and the availability of your reviewers and approvers. Infrastructure lead times also matter, because DNS changes, certificate issuance and cloud account approvals can run on your organization's own schedule, separate from the project plan. Ask the partner to name the dependencies it expects you to provide, the date each one is needed, and how the timeline changes if one arrives late.

What drives the cost of an Open edX Tutor deployment?

Cost follows labor and infrastructure, and each splits differently between one-time and recurring spend. One-time costs cover the build: planning, installation, configuration, HTTPS, backup setup, integrations, theming and handover documentation. Recurring costs cover the servers and storage you pay your cloud or data center provider for, email delivery, offsite backup storage, monitoring, and any retainer for upgrades and support. Scope drives the one-time part most, since each additional identity provider, plugin, custom XBlock or analytics stack adds design, build and test effort. Infrastructure choices drive the recurring part, including whether you run one host or a cluster with managed databases. Open edX itself is licensed under the AGPL, so there is no platform license line item, but you should still budget for the upgrade work each named release requires. Ask for one-time and recurring costs to be quoted separately.

When does a single Docker host stop being enough for Open edX?

A single Docker host stops being enough when measured load, recovery needs or growth exceed what one machine can carry safely, and the signs usually appear in monitoring before they appear in complaints. Common triggers include sustained peaks during exams or cohort starts, Studio slowdowns during authoring, disk growth from video, and a recovery time objective that restoring onto one machine cannot meet. At that point the deployment changes shape: several application nodes behind a load balancer, a shared Django cache such as Redis or Memcached (the edx-platform maintainers note that multi-node deployments need one), managed or replicated MySQL and MongoDB, shared media storage, and separate worker nodes. Tutor also supports Kubernetes, which is covered in a separate topic. Plan the move with a load test and a rehearsed backup restore, and confirm the exact topology with your partner before buying hardware.

Which Open edX release should a new Tutor deployment start on?

Start on the latest named release, because Open edX supports only one release at a time. The current named release is Verawood, published on 30 July 2026, and the release notes list Willow for December 2026 and Xylon for June 2027. Verawood added a new Studio sidebar, a redesigned instructor dashboard, an AI Extensions Framework, tagging and taxonomy management, new frontend plugin slots and LTI Advantage Complete certification, so check which of these your course teams need. Confirm that the Tutor version you install supports the release you select, and check that every plugin, theme and custom XBlock you plan to use is compatible with it before work starts. Ask your partner to state in the quote how the next named release will be handled, including who tests it and whether that work is included in support.

How DeployOpen scopes, builds and hands over a Tutor deployment

DeployOpen plans, implements, hardens, documents and supports Open edX deployments built with Tutor inside your own cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before any build work starts.

How we scope

Confirm whether a single Docker host with Tutor meets your expected learner numbers, or whether a Kubernetes deployment is needed.
Record the Tutor version, plugins, HTTPS approach, backup targets and any identity or analytics integrations in the written scope.
Agree which custom work, such as theming or XBlocks, is included, and which items are excluded from the fixed-scope quote.

How we build

Provision the Tutor configuration, secrets handling and HTTPS on your infrastructure, following the Tutor documentation for each step.
Install and configure the plugins in scope, then test LMS and Studio access, course authoring and learner enrollment on the target environment.
Set up scheduled backups of databases and media, then test a restore so recovery is verified rather than assumed.

How we hand over

Document the deployed configuration, plugin versions, upgrade steps and backup and restore procedures for your operations team.
Walk your engineers through day-to-day Tutor commands, logs and common troubleshooting steps on your own environment.
Deliver the written handover pack and confirm ownership of accounts, secrets and repositories before the engagement closes.

How we support

Offer ongoing support, upgrades and testing as a retainer, covering Tutor version changes and plugin compatibility checks.
Plan upgrades around the current named Open edX release, since only the latest named release is supported by the project.
Confirm with DeployOpen during scoping which support hours, response channels and escalation paths apply to your retainer.