Are there any script policies I should be aware of?

Before using scripts, you should be aware of our script policies. These restrict how much of the server’s resources you may use, for example. By installing and using scripts, you’re agreeing to these policies.

On this page:

Technical Support for Scripts

If you plan to install scripts, you should have the ability to troubleshoot the software you install, or have access to someone who does (such as the author of the script).

Because scripts can be complicated, and we don’t know how your script is supposed to work, we can’t provide free support for scripts unless your question or problem seems to be unique to our servers.

No Destructive or Insecure Scripts

For obvious reasons, you may not create any scripts that attempt to perform destructive, insecure, malicious or illegal actions (this is covered by our general Terms of Service). For example, you may not create a script that attempts to make another Web site crash by making repeated requests to another server.

We will also disable any script that unintentionally does something destructive or insecure — for example, if your script tries to run hundreds of copies of itself due to a bug, or if it creates a security risk as discussed below. (Of course, we would notify you right away if we disabled your script for this reason.)

Server Resource Limits

Because a server must be able to support the sites of multiple customers, we have to set limits on what a Web site can use. This makes sure that one site doesn’t use up all the available resources of a server and cause problems for others. Here are our resource limit policies:

  • Background processes: We don’t allow “background processes” that are unrelated to normal Web site and e-mail activity. For example, you can’t run “IRC bots”, and you can’t routinely use the servers to perform resource-intensive tasks that could be done on your own computers, such as video or audio transcoding, batch processing of large data sets, and so on. A Web script (such as a CGI program or PHP file) must output the HTTP headers within 5 minutes and completely finish within 30 minutes.
  • Multiple programs running simultaneously: You may not run more than 30 simultaneous programs on the server (“programs” includes scripts, FTP connections, and POP/IMAP e-mail connections). Up to 16 of the processes can be FastCGI processes. This limit is usually not a problem unless you accidentally create “runaway scripts” that don’t end properly (in which case you’ll have to ask us to “kill” them for you).
  • Memory (RAM) usage: A single program may not use more than 300 MB of RAM, and the combined memory usage of all your simultaneously running programs may not exceed 800 MB of RAM. Again, this is unlikely to be a problem unless there is something wrong with a script you upload.
  • Resource-intensive scripts: Averaged over each day, programs you run should use no more than 5% of the “CPU time” of one CPU of a 2.33 GHz Xeon L5410 processor if your account is on our Silver plan, 10% on our Gold plan, or 25% on our Platinum plan. Note that this is a daily average; peaks are okay — if your site uses 50% of a server’s CPU for one hour a day and is idle the rest of the time, that counts as 2% for the day (we make sure our servers have idle CPU time to handle peaks). As a rough guideline, a PHP script using FastCGI, such as an "out-of-the-box" WordPress installation, could serve about 50,000 pages a day on our Silver plan (and far more than that if you enable "caching" as we recommend). This should be plenty for nearly any site, but if you exceed these limits, we’ll ask you to upgrade to a plan that allows higher usage.
  • Disk writes: Programs you run on the server shouldn’t write more than 60 files, or more than 6 MB, per minute on our Silver plan. The limit is 120 files / 12 MB per minute on our Gold plan, and 300 files / 30 MB per minute on our Platinum plan. This includes database writes, too; for example, Platinum customers shouldn’t do more than 300 UPDATE or INSERT commands per minute. (By the way, there are no particular limits on reading files in normal situations, because the files will be cached in memory and won’t require any disk access after the first time — the limits are just on writing files to the disk.) Again, these limits are actually quite high, and this is unlikely to be a problem with a normal site.

Sending E-Mail from Scripts

You may use scripts to send a small quantity of e-mail messages to you — for example, sending the results of feedback forms.

(Please do not install your own version of the feedback script named “FormMail” from “Matt’s Script Archive”, as it has a number of issues that may allow others to use it to send spam. We provide a preinstalled secure version of FormMail for you to use instead.)

You may not use a script to send e-mail to other people without our prior permission. Using such scripts without permission is considered a violation of our anti-spam policy. See the sending e-mail from scripts page to learn how to get permission to use scripts to send e-mail.

Security Issues

You are responsible for the security of your own scripts. You, or the author of the scripts you upload, should have an understanding of common security issues related to creating scripts to ensure you don’t inadvertently create security problems. While a complete discussion of this topic is beyond the scope of this page, we will mention a few examples of things that script authors should be concerned about.

One common problem is the possibility of creating a bug that allows others to hijack your scripts to send spam or access other servers. For example, old versions of the widely used “FormMail” script from Matt’s Script Archive had this problem: anyone visiting a Web page that used FormMail could cause the script to send mail to random recipients by altering the information passed from the Web page to the script. (The version of FormMail we supply does not have this bug.) If your script sends e-mail or accesses other servers, be sure that your script uses a hard-coded list of destinations, rather than accepting the information from the parameters passed in from the Web page.

Another possibility is that a determined attacker might be able to read the source code for your script due to a bug or configuration problem, either in your code or our server software. While the Apache Web server software tries to ensure this is impossible, past bugs in that software, for example, have allowed clever attackers ways to view the source code. If your source code contains passwords or other sensitive information, consider moving that information to a separate file in your home directory and having your script read that information when it starts.

You’ll also want to keep in mind that our servers run the Linux operating system, which is designed to be a shared system in many respects. In particular, other users can see the names of programs that you run, as well as the “command line” of those programs. Make sure that the name of your script and the command line of any program you run do not reveal any private information.

A good place to begin learning more about these issues is by performing a Web search for the phrase “script security”.