Development and Production Environments

When you’re working on an app that’s live, it’s a good idea to have a development version running that is completely separate from the production version. This way, when things go wrong (and they will), your users are less likely to be affected. Here are three things to consider when separating your production and development environments.


This should go without saying, but the dummy data used in testing shouldn’t be be available in production and vice versa. It shouldn’t even be stored in the same databases. Confining user data to production keeps it safer, and keeping test data out of production makes your live databases cleaner.


Keeping separate hardware is wise depending on the type of application you’re running, how many users you have, etc. It’s likely that the required load on the production server will be much higher than the server your team uses for development, so the hardware needs won’t be the same. By separating the hardware, you’re able to scale up and down independently and with minimal impact, and it also helps to reduce the impact of each environment on the other.


Dev servers can have have different authorization permissions to make sure that the right people have access to your application until it’s secure and ready for public use. Security updates and other patches for your OS, libraries, etc. can be issued on your development server without affecting production. That way you can handle upgrade issues on dev and be more prepared when you need to update production.

Two environments is the minimum you should consider configuring for any application. Depending on the size of your team and the nature of the application you’re working on, it’s usually a good idea to have a staging environment which is treated as the most-recent stable development build which is next in line to be pushed into production. It’s also a good idea to have local environments for each developer to work individually without affecting the rest of the team. So the workflow looks like this:

  1. Developers work on their branches locally.
  2. When the local build is ready, it is pushed to dev for the rest of the team to use.
  3. When the dev build is stable, it is pushed to staging.
  4. Once approved by quality assurance and beta testers, the staged build is pushed to production.

This is a very high-level overview of multiple environments, and each project has different needs, so this is in no way a comprehensive writeup about how your pipeline should operate. However, if you’re getting started on a project, I hope this article has given you some ideas to consider.

What do your environments look like? Anything you would add to this post? Let me know in the comments below!

Happy coding!
Ryan from The Bunch