One of the key decisions for organisations implementing Moodle is whether to host the site internally, leveraging your existing IT resources, or to host your site using a third-party service provider, taking advantage of their expertise. In this post we'll look into what to consider when hosting in house so you can make an informed decision on whether this is the best option for you.
We'll look at items that have an impact on the total cost as well as items, which may not have a direct cost but may impact the total cost of ownership of the system. The actual costs involved may vary significantly depending on your existing IT infrastructure, software licensing agreements (e.g. if using SQL Server) and the skill sets available to you.
Throughout this post we'll use the term LMS (Learning Management System) but these points apply equally to Moodle and Totara Learn, unless stated otherwise.
What do I need to think about if I host my Moodle / Totara Learn site in-house?
Spec your web server
You'll need a server with sufficient resources for the anticipated load. If you have a virtualisation infrastructure this may be simply a case of adding a Virtual Machine (VM) and the resources as necessary. Adding the LMS to an existing web server may not be ideal as there may be differences in software dependencies – e.g. PHP versions and maintenance requirements for one application may adversely affect the other. We've assumed that a single-node web server environment will be in use in this post i.e. no high-availability or load-balancing. You should also consider future storage requirements as your users start to use the system more.
Select an operating system
Most of Moodle and Totara Learn's development and support is centred around Linux, making this the default choice if there are no other factors influencing your decision. However, if all your other systems use Microsoft Windows servers then both Moodle and Totara have full support for this also. You should base this decision on any existing guidelines or policies you have for server operating systems and the skill set of your IT team who will implement and support the site.
Select a database server
The majority of the LMS systems are probably running on MySQL/MariaDB but Microsoft SQL Server and PostgreSQL are also very popular choices with full support. Support for Oracle is limited and not recommended. This decision may be based on your IT teams in house experience or having existing database which you can utilise such as a central clustered server.Select a web server
Typically, you'll use Apache on Linux or Microsoft IIS on Microsoft Windows. There are other options available such as Nginx and Lighttpd however these are less widespread so it may be harder to recruit staff with the necessary skills or locate third-party support.Select location
You may have a well-specified server in the corner of the office but will that offer the connectivity and security needed for an important application with personal information? If not, you’ll need to evaluate suitable datacentres and manage the relationship with the one you select. Bear in mind that overseas datacentres may seem good from a cost perspective but may not enable you to comply with data protection legislation.
2 Site installation
Step 1 | Install and configure PHP
Linux distributions include PHP as part of the default packages available for installation. However, these packaged versions may not meet the minimum versions required for either LMS.
On Microsoft Windows servers there is an installer for PHP for IIS. Whilst this makes the installation simple, in our experience this does not install the latest PHP version and the configuration settings need updating to work correctly with either LMS. It would be preferable to download PHP and configure IIS manually.
Step 2 | Install the LMS
Once your web server has been installed and configured you can install the LMS. Obtain the LMS source code and copy this to your web server. You'll need to create the database and follow the documented installation steps specific to your environment. On the web server Apache or IIS will need to be configured with the domain name for your site along with a certificate for secure HTTPS access. Don’t forget a DNS name for your site and you may need to liaise with your networking team to set up firewall rules if Internet access to the site is required.
Step 3 | Configure your site
You can then set up additional functionality or services that may be required. You can install third-party plugins to extend the site's functionality (with the usual caveats about using 3rd party code) and probably a custom theme to enhance your LMS with your corporate branding. You may also require integration with other systems, e.g. using Active Directory for integrated user authentication.3 Go-live
Ahead of bringing the site into production your support teams will need to be ready to handle any issues reported by site users. This may involve some combination of staff training, reference documentation and updating your in-house processes.
A crucial part of bringing the site into production is to make sure a suitable data backup regime is in place so that full recovery of the site is possible and compliant with your disaster recovery policies. If you have performance or availability monitoring you may wish to extend this to cover your LMS site.
With the site in production it makes sense to create a sandbox site ideally on a separate web server where you can test changes without affecting your users.4 Maintenance
1. Minor version updates
Moodle and Totara release regular version updates. These are cumulative updates so you can skip releases unless you're affected by an issue that's addressed. Ideally you should avoid becoming too far behind as this can affect the support available. Updates may also include security fixes and you would ideally track announcements and release notes. Generally, minor version updates do not require a great deal of planning simply schedule a maintenance window, take a backup of the site beforehand and apply the update. If you have a staging environment you'll want to make the change there first.
2. Major version upgrades
Major version upgrades include new features but may have changes that introduce compatibility issues with any third-party plugins or your theme. Consequently, greater emphasis must be placed on the planning and implementation for these than with minor version updates.
Both Moodle and Totara publish the period of support for versions where updates are available. You should perform acceptance testing with stakeholders and resolve any issues before proceeding on to the upgrade of the production site.
3. Plugin and theme installation
Moodle's functionality can be enhanced and extended through a plugin architecture, Totara Learn is the same but there are fewer plugins available. As plugins are third party code released separately to the LMS these may need evaluating on your staging site before installing them for your live users. As with the LMS you should aim to keep your plugins up to date to ensure you have the latest bug fixes and security updates. A backup of your site database should be taken before installing plugins.
4. PHP updates and upgrades
Your web server software should be kept up to date particularly if your server is Internet-facing to ensure any security vulnerabilities are addressed or mitigated. PHP particularly needs to be kept up to date to ensure security fixes are applied and this may be required ahead of an upgrade to ensure the minimum version requirements are met. Again, these changes should be tested on a staging server ahead of applying them to a production system.
If your IT team have the skill set and infrastructure resources or are already supporting similar systems then hosting your site in house may be attractive. When hosting in house you still have the option of engaging expert third parties e.g. Moodle or Totara Partners to underpin your existing support capabilities or for help with specific work.
If there's no overlap with your existing in house abilities then implementing a system you're unfamiliar with can be problematic, adversely affecting the credibility of your site. In this scenario you can avoid potential headaches for both support staff and users by outsourcing the hosting of your site.
The largest proportion of our clients adopt the outsources approach i.e. we host their site but the great thing about open source is that you’re free to choose to host in house (with or without support from HowToMoodle).