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 we don’t know how your script is supposed to work, we can’t provide assistance with scripts unless the 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 website 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 website 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.
  • Individual PHP script memory limits are set at 500 MB for PHP 7.2 and older, and 1000 MB for PHP 7.3 and later.
  • Multiple programs running simultaneously: You may not run more than 50 simultaneous programs on a server (“programs” includes scripts, FTP connections, and POP/IMAP email connections). No more than 30 of the processes can be Web scripts; no more than 20 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 (although you can change the latter number). 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 2000 MB (2 GB) of RAM, and the combined RSS memory usage of all your simultaneously running programs may not exceed 4000 MB of RAM. Again, this is unlikely to be a problem unless there is something wrong with a script you upload.
  • CPU usage per program: A single program should use no more than 60 minutes of CPU time before exiting.
  • CPU usage average: 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 (no longer available to new customers), 10% on our Basic Hosting plan, 15% on our Plus Hosting plan, or 25% on our Business Hosting 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 Basic Hosting 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, you’ll need to upgrade to a plan that allows the higher usage. (If you routinely exceed the CPU limit on the Business Hosting plan and you can’t reduce it by optimizing your site, you almost certainly need a “dedicated server” from a different company.)
  • Disk writes: You should not write more than these amounts:
    • Silver plan (now discontinued): 60 writes or 40 MB in any minute; 1,000 writes or 200 MB in any hour; 10,000 writes or 2 GB total in any day
    • Basic Hosting plan: 120 writes or 80 MB in any minute; 2,000 writes or 400 MB in any hour; 20,000 writes or 4 GB total in any day
    • Plus Hosting plan: 180 writes or 120 MB in any minute; 3,000 writes or 600 MB in any hour; 30,000 writes or 6 GB total in any day
    • Business Hosting plan: 300 writes or 200 MB in any minute; 5,000 writes or 1 GB in any hour; 50,000 writes or 10 GB total in any day
    "Writes" includes both file writes and database writes; for example, Business Hosting customers shouldn’t issue more than 300 UPDATE or INSERT queries per minute. Again, these limits are actually quite high, and this is unlikely to be a problem with a normal site. To help customers meet these limits, most customer programs are run using a wrapper that limits write speed.
  • 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.
  • More generally, processes you run should meet the intent of “shared hosting”, which is that your processes are idle and “waiting for something to do” most of the time, consuming CPU or disk resources in brief bursts such as when handling a web request. (This is how most web scripts work, even on fairly busy sites: they might run for 0.1 seconds, then wait in an idle state for the next visitor for 0.9 seconds, for example.) If you need to run processes that continually consume CPU or disk resources more than 25% of the time, or that regularly attempt to consume all available “idle” resources on a server to finish a task lasting more than a few seconds, that process isn’t appropriate for shared hosting: you need a “dedicated server” from another company instead. (We don’t currently sell dedicated servers.)

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

Sending E-Mail from Scripts

You may use scripts to send a small quantity of email 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 email to other people without our prior permission. Using such scripts without permission is considered a violation of our anti-spam policy. See the sending email from scripts page to learn how to get permission to use scripts to send email.

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

Copyright © 2000-2024 Tiger Technologies LLC