Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I heard about this at a talk over the weekend and it sounded like a great idea for a few reasons I can think of:

  • ensures dependencies are met and not broken (e.g. web app requires specific version of imagemagick)
  • helps make spinning up new servers fast
  • consistency with os packages and ease of deployment
  • (potentially) keeping configs updated with the code so that changes to apache, php, etc. configs are kept current with code dependencies. I can see this is a gray area since it's getting into config management.
share|improve this question

There is nothing wrong with it. It is certainly better than the default. Too many peopel simply check out from version control on each server. However, it is not as good as programs made for web deployments. I personally like using chef with the deploy resouce.

The deploy resouce does a checkout from svn or git into a new directory, symlinks config files, and then changes the symlink your webserver used to point there. This means that if you need to, rollback is as simple as changing a recipe. Then chef just changes a symlink.

It really is all subjective. Chef does have a learning curve but it simplifies many administrative tasks. It also makes it easy to "spin up servers", manage dependencies, and keep configuration files updated. It allows you to combine package management, config management, and system management in one place.

EDIT: Added more information about chef

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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