What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
The practical way to run Open edX on a virtual private server is to use Tutor, the open-source deployment tool that packages Open edX as Docker containers. Start with a 64-bit Linux VPS, create a non-root administrator, harden SSH and the firewall, install Docker, Docker Compose v2, Python and Tutor, point your LMS, Studio and Micro-Frontend (MFE) hostnames at the server, then run Tutor’s configuration and launch workflow. Tutor’s documented baseline is 4 GB RAM, two CPUs and 8 GB of disk; 8 GB RAM, four CPUs and 25 GB of disk is the safer starting point for a small production installation.
What you are actually deploying
Open edX is not a single daemon that you install with one package. It is a collection of services: the learner-facing LMS, Studio (the authoring or CMS interface), databases, search, task workers, web services and front-end components. Tutor supplies the orchestration, configuration and Docker images that make those services run together.
On a VPS, Docker provides process and network isolation while Tutor generates the configuration and starts the containers. A reverse-proxy container handles incoming web traffic and can obtain TLS certificates. This is why a normal deployment does not require you to assemble a separate Apache or Nginx stack.
Tutor is maintained by Edly. Before installing, read the current requirements and installation pages at docs.tutor.edly.io. The snippets available for this guide mention Tutor 21 and the Ulmo release, but those references may not be current on 14 October 2026. Treat the exact Tutor version, Open edX release and supported Ubuntu version as values to verify immediately before deployment.
Choose a VPS that will not run out of memory
Tutor’s published figures are the most useful sizing baseline:
| Profile | CPU | RAM | Disk | What it means |
|---|---|---|---|---|
| Minimum | 2 CPUs | 4 GB | 8 GB | Enough for a small evaluation or very light use; builds and upgrades may be slow. |
| Recommended | 4 CPUs | 8 GB | 25 GB | A more practical starting point for a small production site and routine container work. |
The same minimum and recommended values appear in a community Ubuntu guide. They are not a promise of capacity for a particular number of learners: video delivery, simultaneous logins, course size, search indexing and background jobs can require substantially more resources.
Recommended Free Tools
A separate 2026 search-result guide suggested 8 GB RAM and 50 GB SSD for testing and 16 GB RAM with 100 GB NVMe for production, plus swap. That is community opinion rather than a Tutor requirement, so do not present it as an official minimum. It is nevertheless a reasonable warning that disk and memory pressure become the first operational problems as your catalog and enrollment grow.
Architecture and storage decisions
- Choose a 64-bit AMD64 or ARM64 VPS; those are the architectures identified on Tutor’s requirements page.
- Use SSD storage. Leave headroom for Docker images, build layers, logs, databases, uploaded course assets and backups rather than treating the nominal 8 GB minimum as a target.
- Prefer a plan that lets you increase RAM, CPU and disk without rebuilding the server. A memory upgrade is often the simplest fix for failed builds or containers being killed by the kernel.
- Arrange external backups or snapshots. A VPS snapshot is especially useful before the first configuration change, an upgrade or a migration.
Operating-system and software prerequisites
The source material names Ubuntu 22.04, 24.04 and 26.04 in different guides, but it does not establish which Ubuntu release is currently supported. Select the release listed by the current Tutor documentation, not merely the newest image offered by your VPS provider.
Install these prerequisites before launching Tutor:
- Python 3.9 or later, pip and the libyaml development headers. Tutor’s documentation states: “You will need Python >= 3.9 with pip and the libyaml development headers.”
- Docker 24.0.5 or later with BuildKit 0.11 or later.
- Docker Compose 2.0.0 or later.
- A 64-bit Linux kernel and enough free disk space for images and generated data.
Older mirrors mention Docker 18.06 and Compose 1.22. Do not follow those obsolete requirements. Confirm versions after installation with docker --version, docker compose version and python3 --version. If your distribution repository offers an older Docker package, use the current Docker installation instructions linked from the supported Tutor documentation instead of silently deploying an old engine.
Free tools Windows power users keep installed
One-click scans. No signup required.
Harden the VPS before installing Open edX
Do the security work while the server is still empty. Open edX will eventually expose a web application to the internet; it should not be the first thing you secure after the fact.
- Create a named administrator. Log in with the provider’s initial account, create a non-root user with sudo access, and use that account for routine administration. For example, on Ubuntu you can run
sudo adduser edxadminand thensudo usermod -aG sudo edxadmin. Replace the example name with your own account. - Install an SSH key. Add your public key to the new user’s
~/.ssh/authorized_keys, test a second session, and only then disable password authentication. Keep an existing session open while testing so a mistake does not lock you out. - Update the host. Apply the VPS provider’s normal security updates and reboot if the kernel requires it. Do not start the application stack until the host is in a known, patched state.
- Configure UFW. A conservative sequence is
sudo ufw default deny incoming,sudo ufw default allow outgoing,sudo ufw allow OpenSSH, followed bysudo ufw enable. Keep ports 80 and 443 closed while Docker and Tutor are being configured, as recommended by the community Ubuntu guide; open them when DNS and the web proxy are ready. - Take a snapshot. Capture a VPS snapshot before major changes. A snapshot is a recovery point for the operating-system disk, not a substitute for application-aware database and media backups.
Docker publishes container ports in a way that can bypass a host firewall rule in some configurations. Check the Docker and UFW interaction for your chosen installation and verify from another network which ports are reachable. Never expose database, cache or internal service ports directly to the public internet.
Plan DNS and hostnames first
You need a domain that you control. A production installation is intended to be reached by names, and HTTPS certificate issuance depends on those names resolving to the VPS.
Choose a naming scheme before running the launch workflow. A common arrangement is:
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →learn.example.comfor the LMS.studio.example.comfor Studio (CMS).apps.example.comor another dedicated name for the MFE host.
One Edly Academy walkthrough creates an A record for the LMS subdomain (for example, learn) and a CNAME so additional subdomains resolve to the same server. The exact records depend on the hostnames Tutor asks for. Set the A record to the VPS IPv4 address and, where you use a CNAME, point it at the canonical name rather than creating conflicting records.
DNS propagation often takes only a few minutes, but do not assume it is complete. Query the records from more than one resolver or use a DNS-checking service before requesting certificates. A community Ubuntu 22.04 tutorial cautions that its instance could not simply be reached by visiting an IP address; treat that as a practical warning that name-based configuration is required, not as a universal protocol limitation.
Install Docker, Compose and Python
Use the Docker packages and repository recommended for the Ubuntu release you selected. Verify that the Docker daemon starts at boot and that your administrative user can run Docker without repeatedly switching to root. If you add the user to the docker group, sign out and back in before testing; group membership is not retroactive to an existing shell.
Install Python 3.9 or newer, pip and the libyaml development package using your distribution’s package manager. Then verify:
python3 --version
pip3 --version
docker --version
docker compose versionDo not proceed until Docker reports at least v24.0.5, Compose reports v2.0.0 or newer, and the Docker build engine satisfies the BuildKit 0.11 requirement. Version mismatches commonly surface later as image-build failures, so finding them now is cheaper than debugging a partial deployment.
Install Tutor
Tutor can be installed from pip or as a standalone binary published through its releases. The pip route is straightforward on a server where you already manage Python:
python3 -m pip install "tutor[full]"
tutor --versionUse a virtual environment if your operating-system policy prevents system-wide pip installs. The standalone binary is an alternative when you want Tutor isolated from Python packages; obtain it from the release channel referenced by the official documentation and confirm its version before use.
Pin the Tutor version and the Open edX release you have tested. Do not copy a historical tutorial’s version number simply because its commands still look familiar. The official snippets that mention Tutor 21 and Ulmo may be dated, and the current pairing as of 14 October 2026 is not established by the available material.
Configure and launch the platform
The launch process asks for the LMS and CMS domain names and generates the local configuration. A commonly cited command is tutor local launch; because command names and prompts can change between Tutor releases, confirm the exact sequence in the current documentation before running it.
- Run Tutor’s configuration or launch command from the account that owns the deployment. Answer the prompts with the fully qualified LMS and Studio hostnames you created in DNS.
- Review every generated value before accepting it: domain names, administrator email, platform release, database credentials and any optional integrations. Record secrets in a password manager rather than in shell history or a public repository.
- Allow Tutor to pull or build the required Docker images. On a 4 GB machine this can be slow and may fail if the kernel runs out of memory; stop and resize the VPS rather than repeatedly retrying a starved build.
- Start the local production stack using the command prescribed for your Tutor version. Confirm that all expected containers are running before opening public web ports.
- Open TCP 80 and 443 in UFW and in any provider-level firewall only after DNS points to the VPS and the proxy container is listening.
Keep the generated Tutor configuration under controlled access. It contains connection details and platform settings that are operationally sensitive even when passwords are stored separately.
Enable HTTPS and verify name-based routing
Tutor’s production setup is reported to include a Caddy container that serves web traffic and obtains certificates automatically. A separate Apache or Nginx installation is therefore normally unnecessary. Automatic certificates still require all of the following:
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall- The LMS and Studio names resolve publicly to the VPS.
- Port 80 is reachable for the certificate authority’s validation and port 443 is reachable for encrypted traffic.
- No other service is already bound to those ports.
- Server time is correct and the DNS records are not split between old and new addresses.
After launch, visit each hostname over HTTPS, not just the server IP. Check that the certificate covers the requested name, that HTTP redirects to HTTPS where configured, and that Studio, the LMS and the MFE load their assets without mixed-content errors.
Post-install checks
Use a short acceptance checklist before inviting learners or authors:
- Create an administrator account and sign in to both LMS and Studio.
- Create a small test course, publish one unit and enroll a test learner.
- Verify login, logout, password-reset email configuration and the course catalog.
- Upload a representative asset and confirm it is retrievable after restarting the stack.
- Inspect container status and logs for crash loops, failed migrations, certificate errors or repeated task-worker failures.
- Confirm that internal services are not listening on public interfaces and that only the intended web and SSH ports are reachable.
- Record the Tutor version, Open edX release, Ubuntu release, DNS records and VPS size in your operations notes.
Backups, updates and capacity management
A VPS snapshot protects the machine image at a point in time; it does not give you a reliable, portable Open edX backup by itself. Establish a schedule for database dumps, uploaded course media and configuration backups, store copies outside the VPS, and test restoration on a separate instance. Include encryption keys and secret-management procedures in the recovery plan without publishing the secrets themselves.
Before an upgrade, take a snapshot, read the release notes for your pinned Tutor and Open edX versions, verify free disk space, and rehearse the process on a disposable server when possible. Do not mix an operating-system upgrade, a Docker upgrade and an Open edX upgrade in one untested change window. Keep a rollback path and document the command sequence that actually worked.
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 glitchesMonitor RAM, swap, CPU, disk consumption and container restarts. Memory exhaustion is especially likely during image builds, migrations, search indexing and large background queues. Increase RAM or CPU before the server begins killing containers; expanding disk later cannot repair a database that has already filled the filesystem.
Troubleshooting common failures
Image build stops or the kernel kills a process
Check available RAM, swap and disk. A 4 GB VPS is the documented minimum, not a guarantee that every build will complete comfortably. Free space by removing unused images only when you understand which versions are still needed, or resize to the recommended 8 GB RAM and 25 GB disk profile.
Docker or Compose is rejected
Run the version checks again. Docker older than 24.0.5, BuildKit older than 0.11 or Compose older than 2.0.0 is outside the stated Tutor requirements. Upgrade the engine and plugin from the supported repository rather than installing obsolete Compose v1 binaries.
Certificate issuance fails
Check A and CNAME records from an external resolver, confirm that ports 80 and 443 are open at both UFW and the VPS provider firewall, and ensure no old server address remains in DNS. Use the exact hostnames entered during Tutor configuration; a certificate for the LMS name does not automatically cover an unrelated Studio name.
The site works by IP but not by hostname
Verify DNS, the configured LMS and CMS domains, and the proxy’s host routing. Open edX deployments are name-based, and the community guidance specifically warns against assuming that an IP-only URL is sufficient.
A non-root user cannot run Docker
Confirm group membership with groups, sign out and back in after adding the user to the Docker group, and check that the daemon is active. Do not run the entire Open edX installation as root merely to bypass a permissions error.
VPS versus home or dedicated hardware
A VPS is the standard path described by the installation material because it supplies a routable address, provider snapshots and a predictable Linux environment. Home hosting can work, but you must solve inbound routing, changing residential IP addresses, power and connectivity outages, DNS updates and backup storage yourself. Dedicated hardware gives you control over capacity but transfers hardware failure, replacement and network redundancy to your team. For a first self-hosted deployment, a resizeable VPS with external backups is usually the least operationally complicated choice.
Quick Recap
Deployment checklist
- Choose a supported 64-bit Ubuntu image and a resizeable VPS.
- Start at no less than 2 CPUs, 4 GB RAM and 8 GB disk; prefer 4 CPUs, 8 GB RAM and 25 GB disk for a small production site.
- Create a non-root sudo user, install SSH keys and test key-only access.
- Apply updates, configure UFW and take a VPS snapshot.
- Install Docker 24.0.5 or newer, BuildKit 0.11 or newer, Compose v2.0.0 or newer, and Python 3.9+ with pip and libyaml headers.
- Plan LMS, Studio and MFE hostnames and create the required A/CNAME records.
- Install Tutor through pip or its standalone binary, pin the versions you have tested, and review generated settings.
- Run the current Tutor configuration and launch workflow, then open ports 80 and 443.
- Verify HTTPS, administrator access, a test course, logs, backups and resource monitoring before production enrollment.
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.
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 →
