Serving html and php files

I just started hosting files for a website on my server, and I'm not sure where is an appropriate place to keep them to provide access for multiple users.
When I started hosting the site, I put the site files in: /var/www/name.of.virtualhost.site/www/.

I am deploying directly from a checked out repository, for convenience & simplicity, so to update the website codebase another developer or I only have to check out the latest version of the files in order to have everything up to date (using git, in this case). However, the root of the repository has files that I prefer to be non-public.

Right now that's obviously not the case because anything below the final public /www/ folder is also available on the default domain or ip since the /var/www/ contents are already being served up by default by apache. For example, /var/www/name.of.virtualhost.site/docs/site_policies.txt is accessible via some url like defaultsite.com/name.of.virtualhost.site/docs/site_policies.txt.

So where is a better place to store a website's files on linux?

When it's a site that only I'm developing, I can obviously just stick them in /home/my_username/sites/name.of.virtualhost.site/, but that doesn't work well when I want other developers to be checking out the repository and sometimes editing the site's files as well. And I'm running a LAMP stack, not that I expect it to matter.


There is no one size fits all answer to your problem. /tmp would be accessible to all users but is a poor place to put such files.

I am not sure why you aren't using proper version control so all developers are developing in their respective development environments and then pushing to a master repository.

If you are referring to a dev box (which you don't say) then create directory, in some place like /usr/local/src and make it writable by a group that all the developers belong to. Then create a deployment script that puts the files that need to be publicly accessible under the web root.


The new hotness is /srv.

  • hmmm, I guess part of the problem is I'm not sure how to provide a location where I can easily give multiple users editing access?
    – Kzqai
    May 13 '10 at 1:58

/srv has started to be used for things like web servers. However, as you are using apache you can block access to /var/www/www.example.com on the default virtual server.

With Apache you can restrict access directory by directory either by ip or password. You can also require both a matching ip and a password if necessary. Unless you are modifying the files from a process on the web server, the directories and files should not be owned by or writable by the apache servers user id.


I don't really get what you're asking.

Files served from a server should go under /srv according to FHS. But why would several users need to have access to those?

I suggest you start using version control and give developers access to that.

Then automate deployment using a script or func or capistrano.

Give those who need the right to trigger a deployment. Maybe using continuous integration so that it is only possible after all tests pass.

  • Right now deployment is simple: git pull It's just that I'd like to keep that simplicity while -not- serving the root of the repository (and instead only serving /www/ and deeper). Thus /var/www/ doesn't work, and I'm trying to figure out where the perfect location is.
    – Kzqai
    May 13 '10 at 16:56
  • I use /srv/www/$hostname/{htdocs,logs,cgi-bin,...}, if that's what you mean.
    – ptman
    May 13 '10 at 19:25

/home/<user>/<repo> each users's checkout

/srv/git/<repo> for your master repo (point redmine/trac at this one)

/usr/local/bin/deploy.sh very simple script to "deploy" from the central git repo to the actual webserver environment. Try to either keep it under 5 lines of bash, or look into Capistrano.

/srv/www/<vhost>/ for your site

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.