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 a 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 if we disabled a 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:

  • A Web script (such as a CGI program or PHP script) must output the HTTP headers within 5 minutes, must send some data to the Web server at least once every 10 minutes while it’s running (using flush if necessary), and must completely finish within 30 minutes.
  • Multiple programs running simultaneously: You may not run more than 50 simultaneous programs on a server (“programs” includes scripts, FTP connections, and POP/IMAP e-mail connections). No more than 30 of the processes can be Web scripts; no more than 12 of those scripts can be FastCGI processes; and no more than 4 FastCGI processes can be simultaneously handling requests from a single remote IP address. 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, you should use no more than 5% of the CPU time of one Xeon processor core 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 routinely exceed these limits on the Silver or Gold plan, you’ll need to upgrade to a plan that allows the higher usage. (If you routinely exceed the CPU limit on the Platinum plan and you can’t reduce it by optimizing your site, you almost certainly need a “dedicated server” from a different company.)
  • Disk writes: On average, you shouldn’t write more than 60 files, or more than 2 MB, per minute on our Silver plan. The limit is 120 files / 4 MB per minute on our Gold plan, and 300 files / 10 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. Again, these limits are actually quite high, and this is unlikely to be a problem with a normal site.
  • Disk reads: You shouldn’t read more than 1 GB of unique data from a server’s disks per hour. (This limit is only on reading unique, different data: There are no limits on reading the same data many times, because the files will be cached in memory and won’t require any physical disk access after the first time.)
  • Scripts are subject to our general policy on disk limits for total disk space used, total number of files, and number of files per directory.
  • Daemons and background processes: We don’t allow “daemons” or “background processes”. For example, you can’t run “IRC bots” or other software that opens network ports for listening. More details are on our “background processes” page.
  • Batch processes: We don’t allow resource-intensive “batch processes” that could be done on your own computers instead. Examples include video or audio transcoding and statistical processing of large data sets. (If you want a server for tasks other than serving Web pages and handling e-mail, you probably need to rent a “dedicated server” instead.)

Scripts that don’t comply with the policies may be stopped by our systems.

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 install 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”.