In today’s world of web development, working on a staging site is a pretty standard practice. It allows the developer to try things out, fix bugs, and privately show proposed layouts and additions to the client. However, care should be taken when working with a staging environment. Many developers will maintain their live site and the staging site on the same server, without realising that this can be a risky way to work.
In this article, we’re going to look at some of the reasons to think twice about putting your production and staging environments together on one server – and look at the benefits of keeping them at arm’s length from one another.
The risks of staging on your live server
From one point of view, it might seem sensible to keep your staging environment on the same server hardware as the live site. After all, if you are testing performance improvements, it would make sense to test the hardware that real users are actually going to be interacting with… right? Unfortunately, this is a dangerous way to work.
The first thing to realise is that both your live and staging environments are going to be sharing the same resources. There is only so much CPU, RAM, and disk space to go around – and while this may not seem to matter too much while everything is working as it should, this simple fact can spell trouble down the line. For example, imagine the live site receives an unexpected spike in traffic that it can’t handle, and gets knocked offline. If your staging site is on the same server, it will get knocked out too, preventing you from making the changes and performance fixes you might need to get things back up and running.
Worse, the problem can strike the other way around. If something goes wrong on the staging site – say a dodgy bit of test code gets stuck in an infinite loop – it can hang the entire server, taking the live site down in the process. When you think about it, a staging site that risks the integrity of the production site if it breaks is probably unfit for purpose.
When you think about it, a staging site that risks the integrity of the production site if it breaks is probably unfit for purpose. The whole point of a staging site is that it is a safe environment, where things can be tested and broken without any major consequences.
A staging site is supposed to break; that’s what it’s for. Of course, you also need to be mindful of security. If your live site becomes compromised by hackers or malware, this can also put your staging site in jeopardy. This is probably the last thing you want to lose when you need to be cleaning up the mess and patching out the vulnerabilities!
If a hacker deploys a worm or a rootkit on your server, this can spread through the hardware undetected, infecting other sites and projects before you realise what’s happening. And once your staging site and your backups have been affected, you may find that you are rapidly running out of options for repair and recovery. At the most basic level, working on a staging environment that shares a server with your live site can also lead you to fall foul of that most mundane of web development issues: everyday human error.
It’s simply not a good idea to be continuously updating and changing the configuration of sites on your live server. Ideally, it’s best to touch your production server as little as possible and make changes only when necessary – minimising the chance that a silly mistake or lapse will result in downtime for your clients.
UK hosting expertise you can rely on.
Our UK-based support team are techie experts, and they’re ready to help you deliver for your clients.The benefits of a separate staging server
With all of the above in mind, it’s clear that hosting your live and staging environments together on the same server is a bad idea. The good news is that by keeping these two environments on two different servers, you can completely insulate them from each other. Mistakes made on the staging site can’t possibly affect the live site, and any external factors that could cause your live site to go dark won’t also take your staging site with it.
With your staging site on a separate server, you can make sure it has different access details, such as SSH, SFTP/FTP, IP addresses and hostnames. This way, even if your production site is entirely compromised by hackers, you still have a second environment that they can’t touch. You can then use that to patch out the vulnerabilities, before putting a more robust version of the site live at a later date.
Testing your site on a separate server can also give you a more realistic understanding of its impact on the server’s resources. Not only will load testing not impact the performance of the live site, but user testing will also be less likely to cause bugs and other unwanted surprises.
A separate staging server can also be helpful when fixing bugs, as it removes the variable of hosting from the equation. If you can’t replicate the issue on two different servers with the same configuration, that could indicate that the website itself is causing the issue, providing a useful piece of diagnostic information. And while it shouldn’t be your only copy, a staging site on a separate server also acts as a good backup if anything should happen to the production server. It’s not just embarrassing for your clients to have their site go down – it can cost them real money, and cause real damage to their reputation. That damage can easily bounce back to you, both in terms of your relationship and how they talk about you to others. For that reason, it always makes sense to handle every live site with the utmost care, and to insulate them from the volatility of your staging environments.
Separating your production and staging sites onto different servers is a robust best practice that will serve any developer well. Much like buying insurance, it’s the kind of thing that’s easy to handwave away as unnecessary – right up until something goes wrong. With your environments stored on separate servers, you can develop solid code and protect it from emergencies – and your clients will know they can rely on you as a result.
