Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

For those who aren't familiar with the term "staging", it consists of privately deploying your code to a production server (or a clone of your server) so you can make sure nothing is going to break when you go live.

I usually stage my code on domain where is my production domain.

The problem I frequently run into is when some of the application logic depends on the domain name, especially if the domain name is hard coded somewhere.

How do you deal with that situation, assuming you staging and production environments are on the same server?

share|improve this question
up vote 3 down vote accepted

You could add an alias IP (or use the other NIC) and bind IIS or Apache for your staging server virtual host/server to that particular IP address; you could then create a HOSTS file entry for to resolve to this new aliased (or secondary) IP address on your test machine (or if you want LAN-wide access to staging through, you'd create an A record in your LAN DNS server).

Of course you won't be able to hit the actual live server because your new A record or HOSTS file entry will resolve to the wrong IP address until commented out or removed.

share|improve this answer
Seems like a good solution, but it assumes I have access to an additional IP right? Not a big deal but just making sure I understood properly. – Olivier Lalonde Dec 16 '10 at 23:08
I'm making an assumption that your webserver is on your LAN and is NAT'ed to the outside. If it's in a colo with a static WAN IP assigned to it, then yes, you'd need another static IP address from your colo. – gravyface Dec 17 '10 at 15:19

I design all applications to pull information from a database. All my work is in java. Extend the java.util.Properties class so everything is pulled from a database, not a file. The only thing that is different from server to server is the JNDI entry for the datasource. All of your logic on what to do is encapsulated in the class that extends the java.util.Properties class.

This makes it easier for moving from DEV -> UAT -> STAGING - > PROD. We have zero code changes, NO DNS mucking, absolutely No Rebuilding WAR files when going from UAT -> STAGING -> PROD.

We you deal with developers that don't all work in the same environment, DNS mucking/Virutal IPS can become difficult to debug.

This also makes life easier as you start to scale when you have a load balanced/clustered environment. Trying to deal with DNS/ Virtual IPS in your application at that point when scaling up is very difficult and adds more moving parts that can break.

share|improve this answer
Fixing the code would be best, yes. – gravyface Dec 17 '10 at 15:21

You can setup a DNS server with views. In the internal view return the IPs of your staging environment. In order to avoid conflict only configure the test clients to use these DNS servers.

share|improve this answer

I always set the staging server to respond on the real domain and then change my local hosts file to point the real domain name to the IP address of the staging server. Of course this only works if you have separate servers, which you should!

There are some utilities for windows to change the hosts file on the fly, on the mac I use Gas Mask. On windows you might need to flush the dns (ipconfig /flushdns) on mac Gas Mask changes it as soon as you click apply.

share|improve this answer
That's also what I do for my dev server but I have no guarantee it is setup identically as my production server. – Olivier Lalonde Dec 16 '10 at 21:03

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.