My (new) development team is setting up its software development environment. I won't describe the whole scenario, since that's another, much-maligned question.

Anyway, we're going to have services such as source control (mercurial), a wiki, an issue tracker, a file/document server, DNS and possibly other things. My question: Is it a good idea to put as many as possible as these on a single 'kitchen-sink' server machine? Or is it better to spread them out as much as money, power and server room space allows?


  • I know that some things have to go on a different server, like continuous/periodic building, with a lot of crunching involved. I'm talking about the (theoretically) lighter stuff.
  • Our team has 4 people, expected to grow to maybe double that within the next couple of years.
  • We're not going to be 'hammering' services, as far as I can tell.
  • The expected hardware for the server is a plain vanilla PC, ~ $1,000 at most, maybe with an SSD.
  • 1
    wiki's and basic tools for 4 to 8 people? One server should be plenty. Aug 30 '13 at 16:22


Is it a good idea to use a kitchen-sink server for various services?

There's no universally-correct answer to this question. It is fundamentally a business decision based on the budget you have and the problems you are trying to solve for.

Arguments for Separating Services

There are many reasons for separating services, but two of the biggest reasons for separating services are:

  1. Service isolation.

    Ensure so that system failures, resource exhaustion, or security flaws related to one service don't take down all the others. Also good for enforcing a separation of duties at the system level.

  2. Capacity planning.

    Ensure that services aren't contending for limited resources such as disk I/O, memory, or CPU.

Arguments for Combining Services

Putting multiple services on a single host or cluster has some advantages, too. Some specific examples include:

  1. A potential reduction in equipment costs.

    A lot of this depends on whether you have to scale up as an alternative to scaling out. If not, then fewer machines is generally cheaper.

  2. Lower administrative burden.

    Fewer machines to manage can simplify administrative tasks and reduce administrative costs.


It's not all-or-nothing. You can do a lot to isolate services and manage resource consumption on a single box, and you can also use tools and work-flows to reduce costs and administrative burden as you scale out.

Determining what your team needs and what you hope to get out of your design choices is generally the right first step. The critical thing is to ensure that everyone in the organization is on the same sheet of music about whatever decisions are made.

  • Good points here. I'd like to stress that backups of the various services not should be forgotten. You could also set up multiple virtual servers on the same hardware which allows you to both separate services and make regular snapshots in case something goes wrong.
    – sbrattla
    Aug 30 '13 at 9:16
  1. In my opinion it heavily depends on your resource consumption. If one server is overloaded it may cause problems. So if you have a small team I don't see many problems.

  2. If you want to be able to scale this infrastructure it is maybe better to keep things separated.

  3. If you are has me, a guy that like the beauty of the big car and engines, you might have fun having a beautiful and powerfull setup.

  • Is the number of team members enough info to give an answer?
    – einpoklum
    Aug 29 '13 at 18:05
  • It is not enough, depends also in the usage pattern, in the size of the server, etc.
    – Joqus
    Aug 29 '13 at 18:25

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.