How to Self-Host an LMS

Updated June 2026
Self-hosting an open source LMS gives your organization complete control over student data, platform features, and infrastructure costs. This guide walks through the full process from requirements planning to ongoing maintenance, covering server sizing, platform installation, security hardening, and the operational practices that keep a self-hosted learning platform running reliably.

Running your own learning management system means you own the deployment end to end. There is no vendor controlling your data, no per-user licensing fees that scale with enrollment, and no limitations on customization. The trade-off is that your organization takes responsibility for infrastructure, updates, backups, and security. This guide covers each stage of that responsibility so you can make informed decisions and avoid common pitfalls.

Step 1: Define Your Requirements

Before selecting a platform or provisioning a server, document your specific needs. The answers to these questions determine everything that follows.

User count and growth: How many learners will use the system at launch? How quickly do you expect that number to grow? A department with 200 employees has very different infrastructure needs than a university with 30,000 students or a MOOC platform targeting millions. Estimate both total registered users and peak concurrent users, as the latter drives server sizing.

Course types: Will your courses consist primarily of document uploads and quizzes, or will they include video content, interactive simulations, peer assessments, and proctored exams? Media-heavy courses require more storage and bandwidth. Interactive components may require specific plugins or extensions.

Integration needs: List every system the LMS needs to communicate with: student information systems, HR platforms, single sign-on providers, video conferencing tools, content authoring tools, and analytics systems. Integration requirements often eliminate platforms that lack specific connectors.

Data residency: Identify any legal or policy requirements about where data must physically reside. GDPR, FERPA, HIPAA, and national data sovereignty laws may restrict your hosting location options. If data must stay within a specific country, that limits your cloud provider and region choices.

Technical resources: Assess your team's capabilities honestly. Do you have Linux system administrators, database administrators, PHP or Python developers, and staff available for ongoing maintenance? If not, budget for hiring, training, or engaging a managed hosting partner.

Step 2: Choose Your Platform and Hosting Environment

With requirements documented, select the LMS platform and hosting approach that best match your situation.

Platform selection: For most organizations, Moodle is the default recommendation due to its PHP-based simplicity, massive plugin ecosystem, and the largest support community of any LMS. Choose Open edX if you need to serve tens of thousands or millions of learners with structured sequential courses, and your team includes Python and Docker expertise. Choose Chamilo if you need the simplest possible deployment for a smaller user base.

Hosting options: On-premises servers provide maximum control and are required when regulations prohibit cloud hosting. Cloud VPS providers like DigitalOcean, Linode, Hetzner, or AWS EC2 offer the best balance of control and convenience for most deployments. Managed Kubernetes on AWS EKS, Google GKE, or Azure AKS is the standard approach for Open edX deployments at scale. For organizations that want open source software without infrastructure management, Moodle Partners and Open edX hosting providers offer managed hosting with full data ownership.

Server sizing for Moodle: A single server with 2 CPU cores, 4 GB RAM, and 50 GB SSD storage can serve a small organization of up to a few hundred users. A medium deployment of a few thousand users should plan for 4 to 8 cores, 16 GB RAM, and 200 GB SSD. Large university deployments use multiple application servers, a dedicated database server, Redis for caching, and may require 32 GB or more of RAM per application node.

Server sizing for Open edX: Open edX requires more resources than Moodle due to its multi-service architecture. The minimum recommended specification for a production instance is 8 GB RAM and 2 CPU cores, but a comfortable single-server deployment for up to a few thousand users should have 16 GB RAM and 4 cores. Larger deployments require Kubernetes with multiple nodes.

Step 3: Provision and Prepare Your Server

Set up the operating system and foundational services that your chosen LMS requires.

Operating system: Ubuntu 22.04 LTS or 24.04 LTS is the most widely supported choice for all major open source LMS platforms. Debian, Rocky Linux, and AlmaLinux are also viable. Use the latest LTS release for the longest support window.

For PHP-based platforms (Moodle, Chamilo): Install the web server (Nginx or Apache), PHP (version 8.1 or later for current Moodle releases), and a database server (MySQL 8.0 or MariaDB 10.6+ or PostgreSQL 14+). Install PHP extensions required by your platform, typically including mbstring, curl, gd, intl, xml, zip, soap, and opcache. Configure PHP memory limits (at least 256 MB for Moodle, 512 MB recommended), upload size limits, and execution time limits appropriate for your use case.

For Open edX: Install Docker and Docker Compose, then use the Tutor deployment tool which handles the provisioning of all required services (MongoDB, MySQL, Elasticsearch, Redis, Caddy, and the Open edX application itself) within containers. Tutor significantly simplifies what was historically a complex multi-service deployment.

Networking: Point your domain name to the server's IP address. Configure DNS A records for the main domain and any subdomains the platform requires. Open ports 80 and 443 in your firewall. Block all other inbound ports except SSH (port 22, restricted to your management IPs).

Step 4: Install and Configure the LMS

Download the platform source code and run the installation process.

Moodle installation: Download the latest stable release from moodle.org or clone the Git repository. Place the files in your web server's document root. Create a MySQL or PostgreSQL database and user. Create the Moodle data directory outside the web root for security. Navigate to the site URL in a browser to launch the installation wizard, which checks prerequisites, configures the database connection, creates tables, and sets up the admin account.

Open edX installation via Tutor: Install Tutor via pip, run the quickstart command which pulls Docker images, configures services, and starts the platform. Tutor's interactive configuration asks for the site domain, admin email, and platform name. The process creates all required databases, generates SSL certificates, and starts the web server.

Post-installation configuration: Set the site name, default language, time zone, and email delivery settings. Configure authentication (LDAP, SAML, OAuth, or local accounts). Set up the enrollment method (self-enrollment, manual enrollment, or cohort-based). Create initial course categories and user roles. Configure the cron system for Moodle (a scheduled task that runs every minute for notifications, cache cleaning, and other background tasks) or verify that Celery workers are running for Open edX.

Step 5: Secure Your Installation

Security is not optional for a system that stores student data, grades, and personal information.

HTTPS: Install SSL certificates using Let's Encrypt (free, automated via Certbot) or certificates from your organization's certificate authority. Configure the web server to redirect all HTTP traffic to HTTPS. Set HSTS headers to prevent protocol downgrade attacks.

File permissions: Set restrictive file permissions on the LMS codebase. The web server user should only need read access to application files. Write access should be limited to the data directory (Moodle's moodledata), upload directories, and cache directories. The config.php file should be readable but not writable by the web server.

Database security: Use a strong, unique password for the database user. Restrict database connections to localhost or specific application server IPs. Never expose the database port to the public internet. Enable SSL for database connections if the database server is on a separate machine.

Backup strategy: Implement automated daily backups of both the database and the file storage directory. Store backups in a location separate from the application server, such as a different cloud region or an off-site backup service. Test backup restoration regularly to verify that backups are actually usable. Document the restoration procedure so it can be executed under pressure during an actual disaster.

Update policy: Subscribe to your platform's security announcement mailing list. Apply security patches within 48 hours of release. Schedule minor version updates quarterly and major version upgrades annually, with testing in a staging environment before applying to production.

Step 6: Set Up Ongoing Maintenance

A self-hosted LMS is a long-term commitment. Establish operational procedures from day one.

Monitoring: Set up server monitoring for CPU, memory, disk space, and network usage. Use a service like UptimeRobot, Pingdom, or a self-hosted tool like Uptime Kuma to alert you if the site goes down. Monitor database performance with slow query logging. For Moodle, check the admin notifications page regularly for configuration warnings and pending updates.

Performance tuning: Enable OPcache for PHP-based platforms to avoid recompiling PHP scripts on every request. Configure Redis or Memcached as the session and cache store instead of the default file-based storage, which becomes a bottleneck at scale. Tune the database query cache and buffer pool size based on your server's available memory. For Moodle, the caching configuration page allows fine-grained control over which data is cached where.

Scaling plan: Document how you will add capacity when the platform outgrows its current server. For Moodle, this typically means moving the database to a dedicated server, adding a reverse proxy cache, and eventually adding multiple application servers behind a load balancer. For Open edX, scaling involves adding Kubernetes nodes and adjusting resource allocations for individual services.

User support: Establish a help desk or support channel for instructors and learners. Create documentation for common tasks like course creation, enrollment management, and grade export. Train a small team of power users who can handle first-line support before issues escalate to the IT team.

Key Takeaway

Self-hosting an LMS requires upfront planning and ongoing maintenance, but it provides complete control over data, features, and costs. Start with clear requirements, choose the platform that matches your technical resources, and invest in security and operational procedures from day one.