The practical way to run Open edX on your own VPS is to use Tutor, which provisions the platform as Docker containers. The deployment path is: choose a 64-bit Linux VPS, create a non-root administrator, secure SSH and the firewall, install Docker, Docker Compose and Python, install Tutor, point DNS records at the server, then run Tutor’s configuration and launch workflow. HTTPS is enabled after the domain resolves.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
This guide separates published Tutor requirements from community advice, and flags the release and Ubuntu-version details that must be checked in the official Tutor documentation before you deploy. The current Open edX release and the currently supported Ubuntu version were not established in the available material as of 14 October 2026.
As an Amazon Associate I earn from qualifying purchases.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What you are self-hosting
Open edX is a learning platform made up of several services rather than a single executable. Tutor is the deployment tool that assembles those services and runs them in Docker containers. A typical installation includes the learner-facing LMS, Studio (the course-management CMS), and one or more micro-frontends (MFEs). Docker supplies the isolated runtime; Docker Compose coordinates the containers.
On a VPS, Tutor gives you control of the operating system, data, domains and upgrade schedule. You are also responsible for server security, backups, DNS, monitoring and capacity planning. A managed Open edX service can remove some of that work, but it is not self-hosting.
Size the VPS before you install
Tutor’s published figures are the best baseline. They are not a promise that every course, enrollment volume or optional service will fit comfortably, so leave room for the operating system, Docker images, logs, databases, uploaded media and upgrades.
| Profile | RAM | CPU | Disk | Source and meaning |
|---|---|---|---|---|
| Minimum | 4 GB | 2 CPUs | 8 GB | Tutor requirements; the smallest published starting point |
| Recommended | 8 GB | 4 CPUs | 25 GB | Tutor requirements; a more practical baseline for a real installation |
Tutor lists both AMD64 and ARM64 as supported architectures. Whichever architecture you select, verify that the exact Open edX release and any additional images you plan to use publish compatible images for it.
How to interpret conflicting community numbers
An unattributed 2026 guide in search results proposes 8 GB of RAM and a 50 GB SSD as a testing minimum, then 16 GB of RAM and a 100 GB NVMe disk for production, with swap required. Those are community recommendations, not Tutor’s published requirements. They are useful as headroom targets when you expect larger catalogs, background jobs or frequent image builds, but they should not replace the Tutor requirements table.
Choose an operating system carefully
Material for this deployment names Ubuntu 22.04, 24.04 and 26.04. It does not establish which release Tutor currently supports. Select the Ubuntu version listed by the current Tutor requirements page, rather than assuming that the newest Ubuntu release is compatible. Use a 64-bit server image and record the image name and date so you can reproduce the host later.
Secure the VPS before exposing Open edX
Do the security work while the server is still private. Take a VPS snapshot before making changes; it gives you a known rollback point if a package or firewall change leaves you locked out.
- Create a non-root sudo account. Log in with the provider’s initial account, create a named administrator, grant it sudo access, and test a second SSH session with that account before disabling the initial login. Do not run Open edX or Tutor as root.
- Install an SSH key. Add your public key to the new account and confirm key-based login from your workstation. Keep the original session open while testing. Once key login works, disable password authentication and direct root login in the SSH server configuration, then reload SSH.
- Enable the firewall. Allow SSH first so you do not cut off administration. Keep ports 80 and 443 closed until Docker and Tutor are configured; open them when DNS and the web stack are ready. Review the firewall rules after every change.
- Apply operating-system updates. Reboot if the kernel or a critical service requires it, reconnect using the non-root account, and confirm the server’s clock and hostname.
A snapshot is not a backup strategy for course data. Treat it as a quick recovery mechanism and arrange separate backups once the platform is running.
Install the required software
Tutor’s prerequisites are specific enough that old tutorials can fail even when their commands appear to work. The documented baseline is:
- Python 3.9 or later, with pip and the libyaml development headers.
- Docker 24.0.5 or later.
- Docker BuildKit 0.11 or later.
- Docker Compose 2.0.0 or later.
Older mirrors that mention Docker 18.06 or Compose 1.22 are obsolete for this workflow. Install Docker using a method that provides the Compose v2 plugin, not the legacy standalone Compose v1 binary.
Check versions before installing Tutor
Run the version checks as the non-root deployment user:
python3 --version
python3 -m pip --version
docker --version
docker compose version
docker buildx versionThe output should meet every version floor above. If your distribution’s package repository is older, use Docker’s current installation instructions or another supported package source, then repeat the checks. Do not proceed merely because the docker command exists: Compose v2 and BuildKit are separate compatibility requirements.
Recommended Free Tools
Give the deployment user Docker access
Docker normally requires membership in its Unix group or use of sudo. If you add the deployment user to the Docker group, log out and back in before testing; group membership does not apply to an existing shell. Remember that membership grants root-equivalent control of the host, so limit it to trusted administrators.
Install Tutor
Tutor can be installed from pip or as a standalone binary. The pip route is straightforward when Python is already managed on the server:
python3 -m venv ~/tutor-venv
source ~/tutor-venv/bin/activate
python -m pip install --upgrade pip
python -m pip install "tutor[full]"
tutor --versionThe tutor[full] extra installs the components expected for a complete Open edX deployment. A virtual environment prevents Tutor’s Python dependencies from colliding with operating-system packages. If you choose the standalone binary instead, install it from the current Tutor release instructions and verify the resulting tutor --version.
Pin what you deploy
The available material mentions Tutor v21 and the Ulmo Open edX release, but those references appear dated and do not establish the current versions on 14 October 2026. Before launching, choose a Tutor version and Open edX release that the official documentation currently supports, record both values, and test that combination. Do not copy an unversioned command from an older Nutmeg-era tutorial into a new production server.
Free tools Windows power users keep installed
One-click scans. No signup required.
Plan the domain names and DNS
You need a domain that you control. A production installation should be reached by hostnames, not by an IP address alone; one Ubuntu 22.04 community tutorial specifically cautions that its instance could not simply be opened by visiting the server IP.
Decide the names before running the launch process. At minimum, plan a hostname for the LMS, one for Studio (the CMS), and the MFE hostnames your chosen release requires.
| DNS record | Example | Purpose |
|---|---|---|
| A | learn.example.edu |
Points the LMS hostname to the VPS IPv4 address |
| CNAME | studio.example.edu or another subdomain |
Points a subdomain at the name that resolves to the same server, where your DNS design calls for it |
An Edly Academy walkthrough uses an A record for an LMS subdomain such as learn and CNAME records for other subdomains. DNS propagation often takes only a few minutes, but the authoritative TTL and resolver caches control the actual delay. Check each hostname with a DNS checker from more than one network before requesting HTTPS.
Launch Open edX with Tutor
Run the launch process as the non-root user that owns your Tutor environment. The command shown in Tutor installation snippets is:
tutor local launchThe launch workflow asks for site settings, including LMS and CMS domain names in the referenced snippet. Because the exact prompts and defaults can change between Tutor and Open edX releases, confirm the current sequence in the Tutor documentation before accepting values. Use the hostnames you created in DNS, not an IP address.
- Confirm the selected versions. Make sure the Tutor and Open edX versions in your environment are the pair you intended to test.
- Enter the LMS and Studio hostnames. Use fully qualified names that already resolve to the VPS or are ready to resolve when the containers start.
- Let Tutor generate its configuration and containers. The process downloads images and can take substantially longer than the command itself on a small VPS.
- Watch for resource pressure. A nearly full disk or exhausted RAM can interrupt image extraction and database initialization. Keep the terminal output for troubleshooting.
- Open web ports only after the stack is ready. Add firewall rules for TCP 80 and 443 once Docker’s published ports and DNS are correct.
HTTPS and the web proxy
Once DNS resolves to the VPS, enable SSL through the Tutor workflow documented for your release. The Edly walkthrough reports that Tutor includes a Caddy container that serves the traffic and that a separate Apache or Nginx installation is unnecessary. Treat that as a release-dependent behavior: confirm the current Tutor configuration before installing another reverse proxy, because two services competing for ports 80 and 443 will prevent either from starting.
Certificate issuance depends on public DNS and reachable HTTP/HTTPS ports. If a certificate is not generated, first test DNS from outside the VPS, then check that the firewall and any provider-level network policy allow the challenge traffic.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Verify the installation
Use a short acceptance checklist instead of assuming that a successful launch command means the site is ready:
- Each planned hostname resolves to the VPS address from an external network.
- The LMS opens by its hostname and redirects to HTTPS after certificates are active.
- Studio opens on its separate hostname and accepts an administrator login.
- The intended MFE URL loads the learner-facing interface appropriate to your release.
- Docker shows the Tutor containers running rather than repeatedly restarting.
- You can create a test course, enroll a test learner and complete a small piece of content.
- Disk usage, memory use and restart behavior are documented before inviting real users.
Keep a copy of the Tutor configuration, the selected release versions, DNS records and the date of the first successful launch. That information is essential when you rebuild or restore the VPS.
Choose between Tutor installation methods
| Method | Best fit | Trade-off |
|---|---|---|
pip package with tutor[full] |
Administrators who already manage Python environments and want an explicit, reproducible virtual environment | You must maintain the Python environment and avoid dependency conflicts |
| Standalone Tutor binary | Administrators who prefer a self-contained executable | You still need to track Tutor/Open edX compatibility and update the binary deliberately |
Neither method removes the Docker, Compose, DNS or operating-system requirements. Pick one method, pin its version, and use the same method for documented upgrades so that a later rebuild does not silently change the toolchain.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.VPS versus home or dedicated hardware
A VPS is the standard path described for this deployment because it supplies a public address, virtual hardware and provider snapshots without requiring you to maintain a physical machine or residential network. Home or dedicated hardware can run the same software, but you must provide reliable power, upstream bandwidth, public DNS, firewalling and remote recovery yourself. Those operational differences matter more than the Tutor commands.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →For a first self-hosted instance, select a VPS with a snapshot facility, console access and the ability to resize RAM, CPU and disk. Resizing is valuable because RAM is commonly the first constraint as you add courses, learners, background jobs or additional services.
Troubleshoot the common failure points
| Symptom | Likely cause | What to check |
|---|---|---|
| The browser cannot reach the hostname | DNS has not propagated, or the record points to the wrong address | Query the A and CNAME records from an external network; verify the VPS public address and wait for caches to expire |
| HTTPS certificate issuance fails | Port 80 or 443 is blocked, or the hostname does not resolve publicly | Review UFW and provider firewall rules, then confirm that the DNS name resolves before retrying SSL |
| The launch process stops during image download or extraction | Insufficient RAM, disk space or an incompatible Docker/Compose version | Check free disk and memory, compare every tool version with Tutor’s requirements, and inspect the saved launch output |
| Docker commands work only with sudo | The deployment user is not in the Docker group, or the session predates the group change | Apply group membership, start a new login session and test again; do not run the whole deployment as root |
| The site works by IP but not by name | The configured LMS/CMS domains and DNS records do not match | Use the exact fully qualified names entered during launch and correct the DNS records; do not treat IP access as a production configuration |
| A reverse proxy will not start | Another service already owns ports 80 or 443 | Check which process published those ports and use the proxy model supported by your Tutor release rather than installing Apache or Nginx automatically |
| An older tutorial’s commands fail | It targets obsolete Docker, Compose, Tutor or Open edX versions | Discard legacy version numbers, select a currently supported pair, and follow the matching official Tutor instructions |
Operate the platform after launch
Back up application data separately
Take provider snapshots before major changes, but also establish backups for the database, uploaded course media, configuration and any secrets. Test restoring to a temporary VPS; an untested backup is only an assumption.
Control upgrades
Do not upgrade Tutor, Open edX, Ubuntu and Docker simultaneously. Record the current versions, read the release-specific migration notes, take a snapshot and backup, then change one layer at a time. A pinned, tested version is safer than automatically accepting the newest image.
Monitor the limits that affect learners
Track RAM, CPU, disk growth, container restarts, certificate expiry and database backup age. Alert before disk reaches capacity: Docker image layers, logs and uploaded media can consume space even when course content itself is small. If memory becomes the bottleneck, resize the VPS before adding optional services.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesQuick Recap
Pre-launch checklist
- 64-bit AMD64 or ARM64 VPS selected.
- Capacity chosen from Tutor’s minimum or recommended profile, with additional headroom for your workload.
- Ubuntu release verified against the current Tutor requirements page.
- Snapshot taken before configuration.
- Non-root sudo user created and tested.
- SSH key login confirmed; password and direct-root SSH disabled.
- UFW enabled with SSH allowed; web ports opened only when ready.
- Python 3.9+, pip and libyaml development headers installed.
- Docker 24.0.5+, BuildKit 0.11+ and Compose 2.0.0+ verified.
- Tutor installed by pip or standalone binary and its version recorded.
- LMS, Studio and MFE hostnames planned.
- A and CNAME records created and externally verified.
- Tutor launch completed with the intended, pinned versions.
- HTTPS tested and the learner, author and administrator paths exercised.
- Backups, monitoring and a rollback plan documented.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
