The steps to taking an application from development to production

Going Live

Setting Up

Your application will have some requirements to run as a server. Operating system, data base,  some third party tools and apis at the minimum. The setting up process makes sure that all of these tools are compatible and work in sync with each other.

This setup is necessary if we don’t want any further complications on incompatible tools to haunt us. There’s a dedicated team to deal with setting up systems for development, staging, testing and production servers called Devops.

Speeding Up

Throughout development, your code has been running in an ‘evaluation mode’.  This is to help us identify what and where should things go wrong. Useful, but makes the code run pretty slow. – Cant have that.

Everything in the production system is optimized for speed. From DB management, data caching, OS memory management to network caching and session handling is throttled up.

You can expect to see a 2X – 3X faster production for the same traffic.


There are a good number of pests the trouble web servers these days. Phishing, XSS and CSRF are the most common of them. Code and SQL injection attacks are also becoming frequent.

Some of these are handled by the system architecture and some by the server. All applications are fitted with SSL 256 bit encryption as default these days. They’ve come a long way from being a pain and expensive to setup and install to being a couple of lines of code and a free service. No excuse for not having SSL any more.

Port handling in the server OS also needs to be checked. Server login should always require a key file. keep it safe. If you need to, you can encrypt your db as well.


No production server with out database backup! Period. I say again. Don’t even think about going live with out a back up and restore procedure. Should something go wrong, you’d be dead in the water without a disaster recovery system.

DB backup seems to be increasingly missing in new applications with developers not bothering until its too late. Disasters are rare but they do happen. That worsens the situation. Most applications start with out a disaster recovery system or strategy with this very idea. But remember, if a disaster should happen, which it will, the chances if it happening increase with your application’s age. And  so do your losses.

Depending on the volume of your data and your data retention policy, your data should be backed up ideally every couple of hours in rotation.

Not just that, you should be able to go back to a database and server snap shot rather quickly.

Zero Down time

Your cloud host will promise that your application will be up 99.9% of the time. In most cases this is fine. It wouldn’t make much difference. The traffic may not be heavy to notice the down time.

But in a increasing number of cases where having the server available is absolutely essential. Any down time will result not just in missed sales or profits but also in direct losses.

To avoid such a predicament we run your application in two different servers. – that’s two different physical machines. Yet another machine set to serve the database, and a master server to direct the traffic and balance the load on each server.

The set up is tailored to the application and the business demands. The setup for example would be a bit different to cater high traffic vs high availability.

Each machine is set up to report the systems health, trigger alarms on system parameters and report logs on a daily or a weekly basis.

Hosts usually give out notifications on scheduled maintenance or required server restarts. This is something your maintenance team should keep its ears open for.