Skip to content
MooDIY Blog

Appearance

How to Use Your Own Domain with Moodle: The Complete 2026 Guide blog illustration
MooDIY TeamMoodle Hosting Specialists
8 min read

How to Use Your Own Domain with Moodle: The Complete 2026 Guide ​

A Moodle URL is part of the learning experience. learning.yourcompany.com feels official, is easier to remember, and keeps every email notification, certificate link, browser bookmark, and login page tied to your brand. A generic provider subdomain can be fine for a pilot, but it often feels temporary once learners and customers rely on the platform.

This guide was re-audited in May 2026 to remove outdated plan references and focus on current setup patterns: DNS, Moodle's $CFG->wwwroot, SSL, redirects, provider rules, and migration checks.

Should You Use A Root Domain Or Subdomain? ​

Most Moodle sites should use a subdomain:

  • learn.example.com
  • training.example.com
  • academy.example.com
  • courses.example.org

A subdomain is easier to manage because it can usually point to your Moodle host with a CNAME record. It also keeps your main website, email, marketing pages, and LMS separated cleanly.

Use a root domain such as example.com only when Moodle is the primary web presence. Root domains often require A or AAAA records, ALIAS/ANAME support, or provider-specific DNS behavior. That adds complexity and can affect other services.

The Four Technical Pieces ​

1. DNS ​

DNS tells browsers where your Moodle hostname lives.

  • An A record points a hostname to an IPv4 address.
  • An AAAA record points a hostname to an IPv6 address.
  • A CNAME record points a hostname to another hostname.

For most managed Moodle platforms, the provider gives you a CNAME target or verification record. For self-hosted Moodle, you often use an A record pointing at your server or load balancer.

2. Web Server Or Hosting Route ​

Your Moodle server must be configured to answer for the new hostname. On managed hosting, the provider handles this. On self-hosted Moodle, you configure Apache, Nginx, or a load balancer.

3. Moodle config.php ​

Moodle must know its canonical URL. This is controlled by $CFG->wwwroot in config.php:

php
$CFG->wwwroot = 'https://learn.example.com';

Moodle documentation is explicit that this setting must be updated when the site changes from HTTP to HTTPS. A mismatch can cause redirects to the old domain, broken file URLs, login issues, or mixed-content warnings.

4. SSL/TLS ​

Production Moodle should run on HTTPS. The certificate must cover the custom domain your learners use. Managed hosts usually provision and renew certificates for you after DNS is correct. Self-hosted sites typically use Let's Encrypt, another certificate authority, or platform-managed certificates.

Provider Rules To Check Before You Start ​

Do not change DNS until you know whether your plan supports custom domains.

MoodleCloud ​

MoodleCloud's current public docs say custom domains are available on Medium and Standard plans. The Standard plan includes a custom domain, while Medium uses a custom domain add-on priced at 160 AUD per year, billed annually in Australian dollars. Starter, Mini, and Small plans use MoodleCloud subdomains.

MoodleCloud also says the custom domain process is started from the MoodleCloud Portal and requires a domain from a third-party registrar.

MooDIY ​

MooDIY's current managed hosting page lists "Use your own domain" and custom domain capability in the hosting offer, including the free base plan feature list. Because plan terms and older accounts can differ, confirm availability in your MooDIY client portal or with support before scheduling a cutover.

When a managed provider supports custom domains, ask for:

  • The exact DNS record type and value.
  • Whether a TXT verification record is required.
  • Whether SSL is automatic.
  • Whether the old subdomain redirects to the new domain.
  • Whether email links, SSO callbacks, LTI registrations, and payment callbacks need updates.

Self-Hosted Moodle ​

Self-hosted Moodle gives you full control, but you own every step: DNS, server routing, certificate issuance, certificate renewal, Moodle config, redirects, monitoring, and rollback.

Step-By-Step Setup ​

Step 1: Pick The Domain ​

Choose a stable hostname before learners start bookmarking it. Good examples:

  • learn.company.com
  • academy.school.edu
  • training.nonprofit.org

Avoid hostnames tied to a temporary project, internal department, or vendor name unless that is intentional.

Step 2: Lower DNS TTL Before Migration ​

If you are moving an existing Moodle site, reduce the TTL on the old DNS record before the cutover. A TTL of 300 seconds is common during migration windows. Do this at least one old TTL period before the change so cached records expire faster.

After the migration is stable, raise the TTL again if your DNS policy requires it.

Step 3: Add The DNS Record ​

For a managed host, follow the provider's exact instructions. Typical examples:

text
Type: CNAME
Name: learn
Target: your-provider-target.example.net
TTL: 300 or 3600

For self-hosted Moodle:

text
Type: A
Name: learn
Value: 203.0.113.10
TTL: 300 or 3600

Do not guess. If your provider asks for a CNAME, do not use an A record unless they explicitly approve it. If they ask for a verification TXT record, keep it in place until setup is complete.

Step 4: Configure The Hostname In The Hosting Layer ​

Managed hosting:

  • Add the domain in the provider portal or ask support to add it.
  • Wait for validation.
  • Confirm SSL provisioning status.
  • Confirm whether the old provider subdomain remains available.

Self-hosted Apache example:

apache
<VirtualHost *:80>
    ServerName learn.example.com
    DocumentRoot /var/www/moodle
</VirtualHost>

Self-hosted Nginx example:

nginx
server {
    listen 80;
    server_name learn.example.com;
    root /var/www/moodle;
}

Reload the web server after validating syntax.

Step 5: Update Moodle config.php ​

Update $CFG->wwwroot to the HTTPS version of the custom domain:

php
$CFG->wwwroot = 'https://learn.example.com';

If Moodle is behind a proxy or load balancer that terminates SSL, confirm the correct Moodle proxy settings for your environment. Misconfigured proxy settings can produce redirect loops or mixed HTTP/HTTPS behavior.

Step 6: Install Or Validate SSL ​

Managed hosts usually handle certificate provisioning after DNS validation. For self-hosted environments, install a certificate and confirm automatic renewal.

Validation checklist:

  • The browser shows a valid certificate for your custom domain.
  • The certificate includes the hostname in SAN/CN fields.
  • HTTP redirects to HTTPS.
  • Renewal automation is tested.
  • Monitoring alerts before certificate expiry.

Step 7: Purge Caches And Test Moodle Workflows ​

After the hostname change:

  • Purge Moodle caches.
  • Log in as administrator, teacher, and student.
  • Open a course file and assignment submission.
  • Submit a test assignment.
  • Trigger an email notification and inspect links.
  • Test mobile app login.
  • Test SSO, LTI, payment, video, and repository integrations if used.

Do not treat the migration as complete until Moodle-generated links use the new domain.

Redirect The Old Domain ​

Keep redirects from the old provider subdomain or old hostname to the new custom domain. Use 301 redirects when the change is permanent.

Redirects help:

  • Preserve bookmarks.
  • Reduce support tickets.
  • Keep old email links usable.
  • Consolidate search signals.

For self-hosted Apache:

apache
Redirect 301 / https://learn.example.com/

For self-hosted Nginx:

nginx
return 301 https://learn.example.com$request_uri;

Keep redirects for at least one academic term or training cycle. Longer is better if old certificates, archived emails, or public course links are still in use.

Common Problems And Fixes ​

Moodle Redirects To The Old Domain ​

Check $CFG->wwwroot, purge caches, and search plugin settings for hardcoded old URLs.

SSL Works On The Provider Domain But Not Your Domain ​

The certificate must cover the custom hostname. Wait for managed certificate provisioning, or reissue the certificate for the correct domain.

Some Users Still See The Old Site ​

DNS caches may still hold the previous record. Check propagation using multiple DNS resolvers and compare against the old TTL.

Purge caches, wait for queued messages to clear, and inspect customized language strings, templates, and plugin settings.

SSO Or LTI Breaks ​

Update callback URLs, entity IDs, redirect URIs, issuer URLs, launch URLs, and allowed origins in the external system. Many integrations treat a domain change as a new application URL.

Mobile App Login Fails ​

Verify mobile services are enabled, the SSL certificate is valid, the URL is reachable from mobile networks, and any QR login or site finder settings reference the new domain.

Cost And Planning Notes ​

Custom domains are technically simple but operationally sensitive.

Self-hosting usually means you pay for:

  • Domain registration.
  • DNS hosting if not included by your registrar.
  • Certificate management if not using a free automated certificate.
  • Staff time for setup, monitoring, and troubleshooting.

Managed hosting usually means the provider bundles DNS guidance, routing, and SSL into a plan or add-on. MoodleCloud currently limits custom domains to Medium and Standard plans. MooDIY's current hosting page positions custom domain support as part of its hosting offer, but you should verify plan eligibility before changing DNS.

The biggest cost is not the domain registration. It is a failed cutover during a live course or assessment window. Schedule changes outside peak use, keep rollback instructions ready, and test the full learner workflow.

Sources Checked May 2026 ​

Related Topics

MooDIY 6Security & Compliance 5Multi-Tenancy 4Cost & Pricing 4Performance 4Upgrades & Migration 3Course Design 2Backup & Recovery 2Installation & Setup 2Comparison 2