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

Basically I'm wondering what the most common server setup up is for a web company. At the company i work out now we have 1 server with all our clients sites on. We sometimes work locally and upload, but 9 time out of 10 end up developing on the live server itself. Now this isn't ideal and it causes all sorts of problems, not to mention making problem finding difficult (due to logs being clogged with debug errors etc.).

i have been hearing alot about people having production servers, staging servers and development servers and im thinking that would be the way to go.

The setup I'm thinking is:

Production Server - Only live sites go on this. Nobody has FTP access except server admin. phpSuExec is installed so each site runs as its own user. Server is highly optimised. All uneccesary ports disabled etc.

Staging Server - clone of production server, without phpSuExec, but still restricted access.

Development Server - Internal server that all employees use. No FTP restrictions, can install productivity aiding software like SASS, xdebug and have less restrictive security rules etc.

The work flow would then be: everybody works on the development server. When the site needs to be viewed by the client, or tested in a production environment it is moved to the staging server. If there are issues, back to the development server, fix issues and push back to the staging server. Then once all issues are fixed and the client is happy we move the site to the production server.

I would be interested in any advice / pitfalls of the above system, and how other companies do this.

All servers are LAMP, running Ubuntu


locked by HopelessN00b Jan 22 '15 at 5:03

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as not constructive by mailq, Shane Madden, Iain, MDMarra, sysadmin1138 Oct 20 '11 at 15:46

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

Go that way. Don't develop on production machines. – mailq Oct 20 '11 at 10:44
up vote 1 down vote accepted

The 3-tier setup is very common, for obvious reasons.

I recommend some changes to what you already listed, though:

  • Your staging server should be an exact copy of the production environment.
    This has the huge advantage that staging -> production deployments are as smooth and error-free as humanly possible, and since such deployments may involve downtime, you want this.

  • That said, actual access to the staging environment can be less restricted than it is on production, simply so DEV and QA/UA can also get access for troubleshooting purposes.
    You may want to restrict this to read-only access to check configuration and read log files, but it may save time in the long run; this typically depends on your usage patterns of these environments.
    If the shop is big enough that you have separate DEV and QA departments, then by all means keep the staging environment completely separate from DEV as well; large shops usually have a completely separate release team that is responsible for exactly this stage of deployment.

I agree, though I'd add that it's good to have a well-defined and frequently-invoked procedure for resyncing both staging and dev to the production site, otherwise they become so different that "it didn't break staging" becomes useless as a test for "it won't break prod". – MadHatter Oct 20 '11 at 15:46

I agree with @adaptr and would add that developers should each use their own environment for development and check changes into source code control. This prevents them from stepping on each others changes and prevents one developer from breaking the server and putting everyone out of work for a day. The "development server" should be published to automatically from those checkins and will serve as an integration environment for all the changes.


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