The Three Versions of Your Website: Live, Staging and Local

Introduction

I know that I have written a lot of articles lately that revolved around SEO and analytics. I wanted to write those articles so that I could get a group of them out under a related topic, which is based on getting your website found on Google. Now I want to return to writing about web development and talk about something that I have varying opinions on. How many different versions of your website do you actually really need? You will always have your live version in most cases. I have done many different websites over the years and most of the time, people just have their single live version. For large websites that act more like applications, there are typically at least two more, staging and local. I will go through each of the different versions, or rather environments. The reason why I call them environments is because it is the more formal term to describe your website running on a web server that has a database on it. So there is this complete environment that is needed to run these different versions of your website. One thing that I have learned over the years is that the more environments that you have, the more maintenance involved.

Web Development: The Three Different Environments

Live: This is Your Actual Website

This is your live environment, also called production. In more formal circles where you are part of a team of developers, they sometimes call the live environment the production server because that is the version that everyone is using, collecting data and performing transactions. All of your current data will be on live and requires daily backup in case there is ever need of a rollback. A rollback is just reverting your website to its latest version in the event that something happened to your website. Your website might have gone down due to some error or because some data has corrupted the database. This is pretty standard protocol. Websites are always breaking and having errors. We put out a lot of fire when websites suddenly go down. Then you have to rush and check some server log files for errors and try to trace what the error is. Those were some really fun times as you felt the sweat of getting everything running back up again.

E-Commerce: Simulating User Transactions on Live

I can get really technical here and talk about how e-commerce transactions only occur on a live environment so data is more sensitive on a live environment, unlike staging or local. I will merely just touch upon it because in e-commerce only test transactions are run on staging and local. Then you will have to do a real transaction on live because you need to simulate an actual user purchase. A lot of e-commerce websites have this added overhead of keeping the payment gateway settings different than staging or local. So if you are using something like WooCommerce or Shopify, then your live version will always have payment gateway settings that are connected to real accounts compared to local or staging which connect to test accounts.

Staging: This is a Copy of Your Website Used for Testing

Staging environments sit between a live and local environment. The purpose of a staging server is to have a place online that people can see website updates before setting it live. This is important because you cannot set updates to live directly when someone wants to look at them first. Plus, your local environment is used for development. So you might be in the middle of something and cannot use your local environment to showcase change that people want to see. So this is why staging is needed. Depending on how complicated your website is or how often you will update your website outside your CMS, you might not even need a staging environment. That is what I will discuss next.

When Do You Need a Staging Environment?

Easy, you only need a staging environment if you have a large website with a lot of data coming from databases and APIs, a lot of traffic and users who are constantly on your website and make updates to your website all of the time. What each of these reasons indicate is that you have a lot of activity on your website. This means that updating your website directly on life is very dangerous and risky. You should avoid this if you can because any mistake might be hard to revert. This is why I mentioned backups and rollbacks because when a crisis occurs, you might just have to. Even if you do a restoration, you still might lose critical data because your latest backup that you used to perform the restoration did not have all of the data in it right when the fire occurred. So this is why staging is needed in this case.

However, if you have a very simple website like this one. This is just a blog. I am just writing articles on this website and sharing my thoughts and opinions with you. Nothing fancy here. No e-commerce, no APIs and very few code file updates. I am trying to keep all updates within the CMS to prevent the need to touch any code files. Very basic websites like this one do not need a staging version because there are not a million things going on here. I can just relax and write my thoughts to you without having to worry about maintaining a staging website. On that note, I need not a local environment either for the same reason. You should keep a backup of your website and download it to your computer, but you do not need to set up a local environment for it.

Do Not Allow Staging to Be Indexed on Search Engines

This is pretty important to remember when creating your staging environment. Make sure that you set up your SEO so that your staging website will not be indexed on search engines. The reason why is because staging is just another development server and not your live or production server. This is easy to do in WordPress because you tell your website not to be indexed. WordPress will modify a file called robots.txt to tell search engines not to crawl it. If you do not do this, then when you create your pages and publish them, Google will start to crawl your content and add it to its search engine if it deems your pages worthy. This will be problematic because staging does not represent your actual website, your live version does. So if staging makes it onto Google, then you will have that conflict with your live website. So if both staging and live are indexed on Google, you will run into duplicated and outdated content issues. So just be careful and make sure that only live is indexed on Google and not staging or any other development or testing servers.

Local: This is a Copy of Your Website On Your Computer

The local environment is one that runs off your computer using something that runs a local web server. Local is meant purely for development and also you to tinker without dealing with either staging or live. The best part about local is that you can abandon any updates that you no longer want because it is just local. This is where you can have tons of errors and do all of your troubleshooting. You can do whatever you want here and it will not affect staging or live. So this is the best part of local, just being able to try new things without affecting your users on live. Your users will never see your changes because they do not have access to your local environment.

Using a Local Environment with MAMP

If you would like to run a local web server off your computer, then you can use MAMP for Windows. This is very easy and simple to install, then you just follow the instructions when migrating your website to a local environment. I have an article on a list of plugins that I like to use for running a simple blog on WordPress. You should use the UpdraftPlus plugin that I mentioned in that article and move those files into MAMP. Then you can start developing your WordPress website on your local and upload them to live via FTP or your web hosting’s File Manager. This is only needed for more complicated WordPress websites. If you are running a simple blog like this website, then you do not need to do this. On a side note, it is nice to write content over code for a change. This is definitely a different feeling.

Local Can Have Multiple Copies Due to Multiple Developers

Typically, you only have one live and one staging environment each. For local, you have several copies depending on how many developers are on a website. If you are part of a team then you have your local and other developers have their own version of local. This is where you usually have a repository, which I have not spoken about yet. A repository is a code base that synchronizes code between all environments, local, staging and live. This definitely beats FTP for teams. If you are a developer flying solo then you can use FTP if you want.

Maintaining Multiple Environments Can Be Hard

This might be one of the hardest things to do with multiple environments, keeping them all the same. A repository can help with code files but you still have the databases and the servers. You might have to sync your database and do regularly scheduled exports from live and import them into staging and local. This is no easy task and you can not just simply export from live and expect a smooth import into your other environments. Each environment has different things about each one. The domains are different so that affects URLs. If you have cron jobs running then they are usually only affecting the live version, same with APIs. There are ways to keep data sync even if everything is going into the live database.

The server version, that is very hard to keep the same version on every environment. You have the operating system Linux, the web server Apache, and programming language PHP and finally the database MySQL. Really, you do not have to keep the same exact versions of all of these pieces for each environment. I would say that you would need to just keep them updated and not obsolete. Then again, it really depends on how many environments you need to maintain, how complicated your website is and how long your websites have been around for. Eventually, everything has an end of life and that makes it hard because you have a really important decision to make. You have to decide if you are going to update the version of something that might break something. When you have applications that are heavily dependent on APIs and other sources of dynamic information, this is more often than not a reality.

Space Constraints With Multiple Environments

One thing to consider when managing multiple environments is the amount of space each instance takes up. If your original live website is really large, then creating a staging server means having an exact copy that will take up the same amount of space. So if you are on shared hosting and have a space limit on how much space your website can take up, be aware. This is why you need to really think if you actually need a staging server or not because as your live website grows, you will need to sync it up with your staging version. So both your live and staging servers grow together and can take up space. However, maybe you will be at a point where you need to upgrade servers and get something that has more space and is faster.

Summary

This has been an interesting post. This topic is something that I really think is something that you only need in larger websites that are really applications. Having a staging and local server means that you need to maintain both of them, along with your actual website in your live environment. So simple blogs like this one can really just do with live and have no need to over complicate things with the creation of other instances. I would say that in the future, if you need to make modifications to your blog that you do not want your users to see until they are ready, then you should go with another instance. Since I want to make things simple and easy for you, I really think that you should just stick with your live website and have a simple design so that you can focus on your content. Make sure that you have good articles with unique content before you try to get too deep into making changes that require another instance that you can use as your playground. I just do not want you to lose focus on content. I merely bring up the possibility of creating local and staging instances as something that is more for the future.