Finding and Selecting A Web Host
Purpose
These pages are meant to serve as a resource to help users work through variety of questions, issues, etc. as they choose the best way to provide Moodle as an LMS to their users.
Also see the the Decision FAQ
Planning a Moodle installation
If you are interested in installing and using a Moodle instance in your school, organization, or business, there are many things you must consider. Not only do you have to think about the technical aspects, you also should put some thought into how you would like to use the system, maintain the system, create the content, and support the users.
Depending on the size of your proposed Moodle, and the technical expertise you have available, you may decide that you can host Moodle yourself or you may need some help! This page focuses on making decisions about how or where to host a Moodle site.
Roles and Staffing
There are a number of roles to be considered. Some will be the same person, some you will hire in when needed and some you won't need at all...
- Administrator - day to day running of the site (creating courses, users, fixing problems)
- Developer - create new functionality, integrate Moodle with existing systems etc.
- System administrator - run the server, backups, security etc.
- Content creator(s) - create the actual course materials
Who are you? Types of Moodle Instances
There are many types of Moodle users but here are some examples. Take a look at the examples that seem to fit you best and we will attempt to describe the skillsets you will need and our best advice for the type of hosting you may find most practical:
The classroom teacher, instructor, professor, or course creator
The Hosting for moodle teachers page describes the default role of "editing teacher" and sets out some considerations for evaluating your ability to manage a Moodle instance on your own.
If you decide that this category describes you best, you will likely be interested in full service hosting possibly with a moodle partner. If you have an in-house IT department, you may be able to negotiate an agreement with them to provide the hosting and assume responsibility for the administrative tasks related to running a Moodle instance. Depending on your situation and the level of support you need, outsourcing might be the more attractive option.
The (limited) Moodle admin
The hosting for moodle admins page describes the role of the Moodle admin. Not the server admin. This role is limited to managing Moodle, but not other software packages on the server.
If you decide that this category describes you best, you will likely be interested in full service hosting possibly with a moodle partner. If you have an in-house IT department, you may be able to arrange for them to provide the hosting and you assume responsibility for the administrative tasks related to running a Moodle instance.
The Advanced Moodle admin
As you by now expected, the hosting for moodle advanced admins page is for those people who manage Moodle as well as getting into server side considerations, such as cron, email, database management and php.
If you decide that this category describes you best, you will likely be interested in hosting without service.
The Server admin
There is also a page addressing hosting for server admins, for people who have the necessary skills and knowledge to manage the server and stack software. If you fit into this category, you may be less or not involved in managing the moodle instance. Some individuals will be able to run the server as well as manage the moodle instance in its entirety.
Types of Hosts
Hosts who provide full Moodle management/maintenance services
Some hosts are ready to support Moodle as a software package as well as providing and maintaining the server it runs on. They may provide training, content building, and development services as well. Service packages will likely include moodle upgrades, installation of approved third-party blocks/modules/question types, database maintenance, phone or email support, and backups.
There are two types of full-service hosts for the purposes of this discussion: Moodle Partners and hosts who are not Moodle Partners.
Moodle Partners are an international group of Moodle-based service companies that work closely with Moodle Pty Ltd.
There are a variety of other companies providing similar services (sometimes under other names like "lms hosting" and sometimes not) that are not affiliated with the Moodle project and who do not support the project through royalties. Some of them even offer free services that are supported by third-party advertising. Note that for commercial purposes, 'Moodle' is a trademark and you should only find official Moodle Partners using it sell services.
Each of these companies is an individual concern, and a prospective client is ultimately responsible for understanding what service package they are purchasing and how long it might be likely to be around. Do your research and articulate your needs and expectations very carefully!
If you google "moodle hosting" you will find Moodle Partners and a large number of sites offering Moodle hosting that are not full-service hosts. Be very careful. Many sites that advertise "Moodle hosting" are really offering you hosting of the software only, without additional management and maintenance services. These hosts do provide the software you need to run Moodle, but you are on your own after that!
Hosting without Moodle management and maintenance services
Hosting without Moodle management and maintenance services is perhaps the most common situation. Many people select this option when they have decided they do not want to be responsible for hardware or the basic software "stack" used to run a Moodle instance, but also do not want to pay the premium for someone else to provide administrative expertise in the management of Moodle. There are thousands of web hosts available, and each probably offers a slightly different set of service options.
While full-service or managed hosting packages may include upgrades, installation of approved third-party blocks/modules/question types, database maintenance, phone or email support, and backups, no-frills hosting will assume that you are willing to manage all these aspects of running a moodle instance.
If you have a reasonable level of confidence in hosting your own site this can be a very inexpensive solution.
In-house hosting (or "do it yourself")
If you have the necessary background and interest, you (or your IT team) can set up your own server and run one or more Moodle instances to support your institution, business, or project. You may choose to deploy Moodle on a variety of different operating systems (Mac, Linux, Windows) and with several different database options (MySQL, Postgres, MSSQL). While this page is not intended to provide assistance in accomplishing this goal, it does attempt to describe the sort of knowledge base you or your team will require for successfully hosting your own Moodle instance. You could also consider commercial support for in-house hosting from any of the commercial support providers mentioned above.
Choosing a Web Host
The User Experience
Your Compendium
A matrix has been created so that users can provide information on various web hosting options here. Please feel free to add to the matrix, but respect the footnoting conventions and the table structure please. There is some exploration of using Google Docs to address user feedback on Web Hosts. While a Google Doc may eventually be embedded in the Web Host doc, an experimental version can be seen here.
'NB:' If the wiki structure for the matrix is too much of a hassle, please just use the + tab from the "page comment" tab (you must be logged in to docs to see this, and that is still a separate log in....) to add your comments and someone will transfer them to the matrix.
Discussion in the Forums
While the forums should not be viewed as authoritative as circumstances change over time, they have been a focal point for quite a bit of discussion of various web hosts over time.
A collection of posts largely focusing on GoDaddy can be found here or a install steps here and a list of discussions concerning quite a few other hosts, courtesy of Richard Enison (RLE), appears in that collection at this address.
Why Use A Web Host
General areas of concern are:
General Management and Installation Assistance
Many web hosts offer GUIs that provide shortcuts to install and manage web applications. Some typical "panel" options are Fantastico and cpanel, while an example of a management application that many webhosts make available is phpmyadmin (for managing mysql databases.)
CPanel
If you decide to choose a hosting company that has cpanel then this tutorial may provide some guidance in choosing a host and setting up moodle via the old cpanel. It is a VERY large file (that runs for about 12 minutes) and you will have to wait for it to load but Eric Hagley indicates it is worth the wait as affords a step by step approach. If you have the new cpanel please use this link for an updated tutorial.
Keeping Your Software Current
Software such as Moodle is not static; it changes all the time. Indeed Moodle software changes sometimes daily. Software may be altered to fix security issues or to make improvements. Sometimes a fix in one respect causes a bug in another.
Additionally, as noted below, Moodle is not the only product you may want to keep current, and any time you are trying to keep multiple applications current you are bound to run into compatibility issues.
As noted elsewhere, some web hosts provide utilities for web application management. For a discussion of updating software using such utilities (Cpanel for example) see the section on General Management and Installation Assistance above.
Keeping Your Software Compatible
Moodle is not "just" Moodle. The Moodle experience relies on a set of software applications, including a web server (often but not necessarily Apache), PHP, and a database engine (often but not necessarily mySQL), as well as the Moodle code itself. Each of the elements involved is regularly updated and this will result in compatibility issues. A fix to one application may cause a problem in another. Moreover, the manner in which an issue is addressed in one version may change with the next (an example being the use of php.ini files, which were required in every directory in php 4.x, a practice unnecessary in php 5.)
In addition to the four primary Moodle components (again, web server, database engine, PHP and Moodle code) you may wish to install a variety of additional software to use with Moodle (Moodle offers many modules to provide for the integration of external applications). The addition of an external application to your overall system increases complexity because as the various applications develop the modules integrating them may fail.
Module installation might be handled by a firm offering dedicated Moodle services, but will not be typically addressed by a vanilla web-host, which leaves the install of aspell, dragmath, asciimathml, etc. all to you.
One of the most intelligent questions that may be heard in a Moodle class is whether a course developed in Moodle A will work in Moodle B. The best answer is, "Maybe".
Backups
Murphy's Law offers no exceptions; it is an absolute, and without knowing who you are, where you come from or what you do, your Moodle may some day fail. The good news is that the odds of multiple failures are in your favor, so if you are well prepared, this eventuality can be viewed with same equanimity as that stubbed toe.....
Keeping very good records of your hacks, your additions, and the settings you have used for moodle as well as all the other software that it takes to support a moodle instance provides invaluable information. A backup regime, including course backups, software backups, and database backups is also important.
The Moodler must remember that while Moodle itself can do some backups, Moodle backups are very intensive and are only a small facet of an effective backup program, which must address the variety of data that is encompassed by a Moodle web site.
We'll discuss various backup types and issues below, but first let's talk about the underlying issue: who is doing what?
Some web hosts provide "snap shots", some provide site wide backups. Some offer shell access and tell you to roll your own, while some web hosts honestly couldn't care less.... You must remember that, without a specific agreement otherwise, it is unlikely that your web host acknowledges any responsibility for maintaining your data. Unfortunately, typically each of your data types may require a different kind of backup and you either need to learn how to do effective backups of your site on your own, or you will have to negotiate what amounts to bare metal backup with your Web Host (and you will need to identify an appropriate window, because you want your backups to be rather more current than your web host might find sensible....)
If you have shell access the good news is that there are quite a few scripts out there you can use to help yourself build an effective backup regimen.
There are critical points with respect to backing up your data that need to be addressed. They range from the global, such as addressing the location for the backups and managing remote backups (rsync can be helpful in this respect) and actually handling and recycling of the files themselves (when do you back up, what do you backup when you do backup, and how long do you keep a specific file) to the narrow (for example the db should be locked during backup.) While we have broken up this discussion because different types of data need to be treated in different ways, one could script one's system to address backups for all the different types of data.
Another option that we should mention in passing is that one can also look at replication of data, either to a simple store or to a failover unit. Be aware that mysql replication requires access to mysql commands that some web hosts do not provide. Chances are that if you are looking at replication you are having multiple private systems hosted by a vendor or are running your own installation and have looked at fail-over, clusters and replication in depth.
Lastly, please remember that if you are paying a web host for bandwidth used, remote backup could become a source of significant expense
Note: AT present there is one Backup page, Site_backup, in the docs, and it might be helpful at some time to break that up so that separate docs address different aspects of backup with one page addressing scripting options. In any event link to backup page needs to be added
Data
By data we mean the contents of the moodledata directory, which may represent some of your most important material.
GUI
Your GUI is what is most often neglected when addressing backups. More often than not much of what you think of as your GUI will be reflected in any customizations to your theme, with pertinent data located in your Moodle code installation (/moodle/theme - see below) and possibly moodledata (a possible site for images used.)
Databases
Whatever database you are using, it is critical that you dump and store your db regularly, especially because it can be so simple to restore a site if you have a recent db dump. This can be accomplished manually via a GUI as with phpmyadmin or mysql admin or via command line if the user has access and the requisite skills. It can also be automated via commercial or open scripting (as in HandyBackup or automysqlbackup).
Software
Not only your Moodle configuration (additional modules, hacks and twiddles), but complementary software that you have integrated (like Mahara, etc) should be backed up.
You might ask why you should back up your Moodle code when you can just download it from Moodle and reinstall. There are a couple of issues here. First, the version of Moodle you download today is going to be different than the same version of Moodle you download tomorrow. This is confusing but that is how things lie. It is possible that a new install will result in problems on a restore and if you are facing down some failure you DO NOT want to then also have to try and figure out why what was working yesterday isn't working today. All things being constant is the hallmark of restore, and you don;t want to deal with any changes you are not aware of.
The second issue is your potential customization, whether that amounts to hacks to php code or just to the installation of additional modules. If speed is of interest (and when doing a restore after failure the most oft heard words are "how soon" ) you don't want to have to recreate your Moodle application, you want to be able to restore.
And a third issue related to the previous point is theme customization. Themes are stored in /moodle/theme.
Security
Most often we talk about security in the context of potential threats to your data. Of course, what can cause some consternation here is that different folks think of data in different ways. There is the data Moodle places in the mysql database. There is the data that Moodle places in the moodledata file structure, and there is the Moodle code itself. You may want to consider protecting all of these types of data from unauthorized reading, writing and execution. Think of this as a two dimensional matrix. Now add a third dimension that includes various ways one might be able to access any cell in the existing table, including coding flaws, external configuration problems and internal Moodle configuration issues
Code Flaws
Code exploits are addressed regularly through patches.
Need links to the various fora, etc for security reporting and info)
Configuration
The most typical issue in this area is placing the moodledata directory in the web root.
Moodle set-up
This includes such matters as enrollment, internal role configuration, etc.
Perhaps the most widely discussed problem here has been the matter of profile spam that can be produced when admins allow open e-mail enrollment. There are arguments as to whether this is a security issue or not (and sometimes it seems that the same folks are on both sides of the issue at times) but what it means from a practical standpoint is that you can have a Moodle targeted at your elementary school which contains enough pornography to make Bosche blush.
Sophisticated authentication relying on Moodle Networking, LDAP etc. will require some administrative skill sets pertinent to the scheme employed. One should also be acquainted with the underlying nature of access control including the difference between authentication and authorization. See, e.g. http://en.wikipedia.org/wiki/Access_control
More more prosaic but as important are matters of security policy and enunciation of protocols addressing access rights to data (in the U. S. consider HIPAA, FERPA, IDEA, etc.)
Integration
After an initial basic Moodle installation there are quite a few tasks that need to be addressed to integrate the Moodle with all the bells and whistles you are expecting to use.
Cron
One of the most important post-install tasks is to invoke cron.php via the system cron daemon (or Task Scheduler...) Among other tasks, such as backup, cron triggers mail. Cron explains a good deal but there may be issues when trying to use smtp (some of these have been fixed in Moodle 1.9.3) to alternative ports.
While typically Moodle will use PHP's mail routines, in some cases you may have to configure mail manually and some issues may require manual database edits. See, Email settings and Email setup gmail as examples of possible manual configuration.
Max File Upload
The maximum size of file uploads for Moodle can be controlled via the Moodle GUI but are also constrained via Apache and PHP, and to adjust these you may need to be able to edit .htaccess and/or php.ini. Here are some examples of the discussin of such matters: http://moodle.org/mod/forum/discuss.php?d=98064&parent=433245 and http://moodle.org/mod/forum/discuss.php?d=103190&parent=456650
Criteria for Selecting Web Hosts
What Purpose Will Your Site Serve
Production, Experimentation, etc Classroom support or Asynchronous Remote Gradebook and critical classroom data Number of concurrent users
Issues of scale can be very important. A relatively small number of concurrent users can generate enough email through forum postings to get you in trouble with your host. Email volume, storage space for users and courses, number of accounts,
Will You Be Running a 5 Nines Site
What is all this you hear about "five nines". This is a way to discuss system uptime and the implications thereby for the amount of time that a system is down and not available.
While five nines is not that difficult to achieve, it becomes obvious quickly that without redundancy bringing down any part of a system for maintenance quickly knocks one out of the park.
Downtime can grossly be divided into planned and unplanned outages. You may determine that since you only serve people in one time zone who had beeter be in bed between 2 and 4 in the morning, that you can live with 2 hours of planned downtime a night. On the other hand, you may feel that from 7:00 a.m. to 10 p.m. Monday through Friday no outage is acceptable.
Are you Prepared to Serve as a SYSADMIN?
How are you planning to staff your project (see above??) Do you have buy in from your IT dept? Is everyone involved familiar with the realistic demands of a Moodle install (crank the FTEs!)
Is Your Web Host Willing to Negotiate for the Services You require
SLAs
What is an SLA? An SLA is a Service Level Agreement. While wikipedia provides a basic discussion of SLAs, a review of Naomi Karten's site, which is pitched at the vendor might prove helpful. There are commercial SLA kits as well.
By way of example, consider the SLA between Delhi SUNY and Moodlerooms (and see this comparison), an SLA in pdf format for North Umbria Learning, and an SLA in MS Word format for Kwantlen, Canada.
Remedies
Well, having considered an SLA hard and fast, the question is whether your SLA sets out specific remedies for those occasions when your vendor doesn't provide the services agreed upon, and if not, what recourse you may have.
To put this another way, you have no rights if you have no remedies. Depending on the relative bargaining power of the parties remedies could run from monetary damages to a term extension. In many cases your potential vendor may refuse to agree to any specific remedies. Consider the vendor who "guarantees" band width and when asked what the client receives when the bandwidth drops below the guaranteed service level, the vendor states that they will work to resolve the issue; there is no remedy and the guarantee is mere puffing.
Negotiating for remedies is an excellent way to explore the amount of faith the vendor puts in his own stock. Most often you will be told that the vendor can't provide any remedy as remedies could put them out of business. Chances are that this vendor does not have redundancy or experience necessary to provide mission critical service.
Notes to selves: Here is the real meat and potatoes, which we can put here or actually put on additional pages (my prefs) SO a link to range of service, types of support, security, e-mail, mysql support, panels.... perhaps as well, pages on SLAs generally, boilerplate and guarantees, punchlists Perhaps specific sections, with brief descriptors and links to more detailed pages.
Planning an Installation
Outsourcing
Developing your specs
Often a larger installation will not be a vanilla Moodle site, and needs to be tuned or customised to a particular purpose or environment.
If possible, try to develop a really clear specification of what you want internally. Create a written document that is clear and concise about your needs, including a statement of your purpose and goals. Resist the temptation to get too detailed, though - 100 page specifications full of descriptive text and mock screenshots may result in your Request For Quote (RFQ) ending up in a too-hard basket.
If you aren't sure exactly what you need, consider consulting with experts who have implemented similar systems before. The Moodle forums are a useful place to ask questions and get results from a variety of Moodle experts (but everyone will appreciate it if you read the pertinent docs first.)
Approaching providers
When sending your request for a quote to providers, make sure to include information about your deadlines and resources to help the provider make a balanced judgement on their costs and availability (depending on the work you need).
Comparing quotes
Generally you do get what you pay for. Like most things you should consider the following variables beyond cost value:
- Stability of the company
- Service level agreement (SLA) details
- Reputation of the provider
- Experience with Moodle
