I am thinking about rolling out a very stripped down version of release management for some PHP apps I have running.

Essentially the plan is to store each release in /home/release/1.x etc (exported from a tag in SVN) and then do a symlink to /live_folder and change the document root in the apache config.

I don't have a problem with setting all this up (I've actually got it working at the moment), however I'm a developer with just basic knowledge of the server admin side of things.

Is there anything I need to be aware of from a security or performance perspective when using this method of release management?


  • 1
    Have you considered using git for release management? I know this wasn't the point of the question, but we migrated from symlinks like this to git a while back, and it has been far easier to maintain. – Bryan Agee Jun 28 '11 at 23:20
  • We use git for all of our SCM, and then the servers have a trigger that does a forced checkout of the current maint branch. We tag each of our releases, but the maint branch is always live. To update, I just push the repo to the live servers, with one command: git push live-servers – Bryan Agee Jun 28 '11 at 23:39

If you are really worried about the performance issue (minimal) of a symlink, then you could always use a bind mount instead. You also, will not have any of the security implications either. A bind-mount is basically a symlink that exists purely at the kernel level.

But you probably shouldn't really be worrying about the performance aspect unless you have proof that it is a real issue.

Also, actually enabling symlinks in Apache actually improves performance in some cases, because some filesystem checks are removed. Unless you have a reason to have it disabled, you probably want FollowSymLinks on.

See the performance tuning section about symlinks in the Apache docs. http://httpd.apache.org/docs/2.2/misc/perf-tuning.html#symlinks

FollowSymLinks and SymLinksIfOwnerMatch

Wherever in your URL-space you do not have an Options FollowSymLinks, or you do have an Options SymLinksIfOwnerMatch Apache will have to issue extra system calls to check up on symlinks. One extra call per filename component.

The security implications of FollowSymLinks tend to be all centered around permitting non-trusted users the ability to create files. If you are on a shared server, if you permit non-trusted users to write to the filesystem, or if you have any bugs in any hosted webapps, then a hostile user could be create a symlink to a file that wouldn't normally be available via the web server. They could display it, or if your permissions are really bad, and you have a buggy webapp, then a symlink could permit modifications. On a system that is well locked down this shouldn't be that much of an issue. If you have any directories where you permit store user-supplied content, you should disable symlink following there.


a single symlink to correct directory won't hurt performance at all, because it will be cached by VFS.

As for security considerations, you might need to enable symlink following in your server, which could become a concern. The first thing to do would be to disable symlink following other than application directory link. However, I think it's better to have a proper, full security solution that ensures that all applications only have the permissions they need - you could for example run your PHP applications under their own user accounts, with FastCGI.


Symlinks hurt performance, in that the disk has to seek to two places (or more, if there are multiple links to follow) to read a file. Other than that, it shouldn't be an issue. I'm not aware of any security implications...

  • If you're doing something often enough to impact performance, the symlink will be in disk cache which mitigates the impact entirely. – womble Jul 31 '11 at 0:44

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.