Project Web Services

Project Web

The project web service provides a robust web server platform which can be used to:

  • Host static HTML content about your project.
  • Run a Content Management System (CMS) or other dynamic website with content about your project.
  • Deploy third-party Open Source web applications to support the needs of your project team. (We also provide a number of popular Open Source web applications for your immediate use through our Hosted Apps offering.)
  • For those projects implementing web applications, give you a platform to run a demo for your users, or for your development team to perform testing.

Quick Start Guide for Project Web

What's that you say, you want to just get to it? Use one of our supported protocols like SFTP, SCP, or rsync to upload your files:

[jsmith@linux ~]$ sftp
Connecting to
The authenticity of host ' (' can't be established.
RSA key fingerprint is b0:a8:eb:30:ce:1a:0e:6a:4d:7a:6b:3a:0a:c6:27:60.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ',' (RSA) to the list of known hosts.'s password:
sftp> cd /home/project-web/fooproject/htdocs
sftp> put index.html
Uploading index.html to /home/project-web/fooproject/htdocs/index.html
index.html                                                       100%  241     0.2KB/s   00:01
sftp> exit

The key to this process is authenticating.

Connection Settings

If using a GUI SFTP client (such as Filezilla) to upload to Project web, the following settings should be used:

Setting: Value

Protocol: SFTP
Port: 22
Username: Your Login Name (User Name) (e.g. jsmith)
Password: Your Login Password
Upload path: /home/project-web/fooproject/htdocs


  • Our project web servers frequently handle more than 50M hits per day; we handle server scaling, load balancing, and performance tuning.
  • The project web platform has been standardized on CentOS 5.x Linux, running Apache 2.2.x.
  • Support for many programming languages, including PHP (via mod_php), Perl, Python, Tcl, Ruby, and shell scripts.
  • Support for several database platforms is provided, including MySQL (through our Project Database service), DBM, and SQLite.
  • Project web content may be uploaded using our File management service or be managed directly using our Shell service.
  • Each project is allocated the VHOST (virtual host), which is used to serve their project web content.
  • Our servers will answer traffic for a domain you register, when configured as a custom VHOST.
  • Common web server features are provided, such as mod_rewrite, Server-Side Includes (SSI), HTTP Basic Auth, and custom error handler support.
  • Page views are counted in the statistics system based on display of a project-specific logo.
  • Additional web analytics are available using Piwik, part of our Hosted Apps offering.
  • Service usage is not restricted by quotas.


  • Project web service is an "always-on" service; no opt-in is necessary. To begin using project web, simply upload new content or scripts to your project web space.
  • Uploads may be performed using our File management service, or you may choose to manage your files directly over a SSH session to our interactive shell service.
  • Until you upload an index page to your project web space, a default index page will be shown, containing details about your project.

Re-directing to Hosted Apps

Many projects simply want their project web page to point to one of their preferred Hosted Apps like MediaWiki, Trac, or Wordpress.

This is allowed and may be achieved via an HTML redirect or a PHP redirect. An example for PHP:

/* Redirect browser */
/* Make sure that code below does not get executed when we redirect. */

Place this in the directory as file name index.php and set the URL to be the URL of the Hosted App desired to be the main page for your project.

Special Filesystem Permissions

The filesystem for your project-web files has special handling of permissions, which makes it easy for multiple users to cooperate when updating the projects files without having to worry about file ownership issues that used to restrict and/or hamper file changes. For full details, see Project Web Filesystem Permissions. That page also explains how to make your files writable by your own web apps on the project-web servers.


Virtual hosts (VHOSTs) are a way of serving many websites from a single pool of servers. At, each project is provided the (replace UNIXNAME with the your project's UNIX name) VHOST. You may access your project web site via web browser at:

For example, the project web site for the "leaf" project may be seen at:

Sending email from a web-app

You can setup an authorized email connection for software on project web to be able to send out emails. The full details are specified on our Project Web Email Configuration page. Please note that we track abuse of this service.

Access Logs

Your projects access logs for the last couple weeks are available in the /home/logs/project-web/PROJECT_NAME directory. Older files will be gzipped to reduce their size. IP addresses have been obscured so that you can see the general locale of the accessing user, but not determine the full IP number. The logs have date-based names, one for each of our servers, so to see a full day's logs, you need to look in all the YYYY-MM-DD-hostN.log files (e.g. 2011-02-09-host6.log.gz).


Users may find data to help trouble shoot their project web space by looking over the Apache log files.

Users may copy one or more error.log.web-NUM.gz files from /home/project-web/error_logs.

Custom VHOSTs

Project web sites may additionally be served using a domain you register. Our servers will route this traffic to your project web site when configured through our Custom VHOST service.

For example, the phpMyAdmin project on has a project web site which can be accessed at or

Backups performs routine backups for all of our servers and will restore from these backups in the event of catastrophic server failure. We encourage projects to make their own backups of project web data as that data restore can be performed by the project in the event of accidental data destruction by a member of the project team.

Backups of project web data may be made using the File management service.

Service-specific restrictions

Our policies require the following when using the project web service, in addition to the requirements of our Terms of Use:

  • We encourage all projects to display the logo we provide for statistics tracking (sflogo) to highlight that the site is hosted on
  • Content and applications in project web space must be related to the project. For hosting of personal content, please instead use our developer web service.
  • We ask that all projects give consideration to resource usage, particularly since our servers are shared among many projects. Our servers may not be used for bandwidth intensive or CPU-intensive (e.g. SETI or brute force cryptography cracking) things. Similarly, project web may not be used to host services, such as MMORPG games or whole-Internet search engines.

Changes as of February 2011

We made a number of improvements in our February 2011 project-web upgrade:

  • A new server pool with upgraded software (such as php 5.3 instead of 5.2)
  • You may need to tweak your php scripts to work with some practices that were made obsolete in 5.3.
  • Authorized email can be sent from project-web applications.
  • The upload path for files changed to /home/project-web/PROJECT_NAME.
  • The old upload path of /home/groups/P/PR/PROJECT_NAME will continue to work for a while, but you should transition over to the new path as soon as possible.
  • You should edit any scripts that refer to the old /home/groups and/or /home/persistent path
  • There is no longer a /home/persistent directory for projects, as the main filesystem now supports a user-selectable write permission for your web applications.
  • If you had content in your /home/persistent/P/PR/PROJECT_NAME directory, it has been copied to the directory /home/project-web/PROJECT_NAME/persistent and the permissions modified as necessary to work with the new filesystem.
  • Any symlinks that pointed into /home/persistent have been updated for you during the copy.
  • You should mark any files containing secrets (such as DB passwords) as only owner and group readable (without world readability). That will keep your secrets known only to project members and your own web apps.
  • You can feel free to relocate files/directories out of this persistent directory into your normal htdocs hierarchy, as you see fit.
  • One thing that is nice about having the writable area separate is that you can more easily make sure that the main files in the htdocs directory are not marked as group-writable, which means that they can't be exploited by a web-app vulnerability.
  • Improve file permissions for all your files (see above: Special Filesystem Permissions)
  • Access logs are now available (see above: Access Logs)