Frequently Asked Questions
With respect to the software we provide, our goals are:
To meet those goals, we divide software into four broad categories, two that we're responsible for and two that you're responsible for:
#1 and #4 are clear enough, but the demarcation line between #2 and #3 is always a tricky balancing act. The lower-level a module, or the more security implications it has, the more likely that we should provide it. The more customization a module needs, the more restrictions using it imposes, or the more often it has backwards compatibility issues, the more likely that you should provide it.
This entry discusses how you can install third-party libraries modules yourself for the most common languages, and how to request that we install things when appropriate.
For PHP, we recommend the use of Composer or a similar tool to set up and manage your application's PHP environment. This will make sure that the modules (and versions of those modules) that your application expects are present and that they don't change out from under you as we continuously update our system. Consequently, we provide only PHP binaries, core extensions (both builtin and from PECL), and a library of commonly-used PEAR modules, and we can only install additional modules if they are of great general interest.
For Python, we strongly recommend the use of virtualenv to set up and manage your application's python environment. Unlike other languages, Python's performance degrades as more modules are added to its central library; you will usually get better performance and a more stable site if you use virtualenv feature to set up exactly (and only) the modules you need, rather than diving into the deep pool of modules provided by our system. Consequently, we can centrally install PIP modules if (and only if) they are of great general interest.
For Ruby, we recommend setting the $GEM_HOME environment to a path of your own (we recommend /home/protected/gems or similar) and using gem or bundler or a similar tool to set up exactly (and only) the modules you need. This will make sure that the modules (and versions of those modules) that your application expects are present and that they don't change out from under you as we continuously update our system. Consequently, we can centrally install Gems if (and only if) they are of great general interest.
For perl, you can use local::lib to set up a per-site perl module repository that will work with CPAN to allow you to obtain and use exactly the modules you want. We can also centrally install modules from the CPAN archive with appropriate justification. In this case, there is an additional requirement that the module's built-in tests pass in our environment.
If you have questions about how to perform per-site module installation for one of these languages, please review the support tab for your support options.
For other general purpose utilities not specific to one of the above languages, we rely on the FreeBSD ports collection, which contains 27,000+ software packages. If a utility is of sufficient general interest (and not in one of the prohibited categories below), we are generally able to provide it.
To request that we centrally install a new software package, please submit an Assistance Request. (Make sure to follow the instructions on that page.)
When we install software, we require that the requested software package have some applicability to web hosting, and that central installation of the software will not interfere with others' use of the service. For example, we cannot install the following categories of software: