Your developer pushes an update on a Saturday evening, and for twenty minutes your online shop shows an error page. Orders stop, customers call, and nobody can say when it will be back. A blue-green deployment is one of the simple ways to stop that from happening.
This guide explains it in plain words for a shop, cafe, clinic or factory owner. You will see how blue-green and canary releases work, what they cost, and the questions to ask before your next update goes live.
Quick answer
Why does an update take your app offline?
Many small apps are updated in place: the old version is stopped, the new one is started. In the gap, visitors see errors. If the new version has a bug, the only fix is to rebuild the old one, which can take even longer.
AWS describes this exact problem in its guide to blue/green deployments. Rolling back means "redeployment of an earlier version from scratch", which "takes time, making the application potentially unavailable for long periods".
What "deployment" means
A deployment is the moment new code is put on the live server (the computer that runs your app for customers). Each new feature, bug fix or price page change your developer makes reaches customers through a deployment.
What "downtime" means
Downtime is any time customers cannot use your app or website. For a restaurant mid-service or a shop during a sale, even ten minutes can mean lost orders and angry calls.
How does a blue green deployment work?
You run two copies of your app, called blue and green. Blue serves customers while green gets the new version and is tested. Then traffic is switched to green in one step, and blue waits as a backup in case something goes wrong.
Martin Fowler described the method on his site on 1 March 2010. He wrote: "You have two production environments, as identical as possible. At any time one of them, let's say blue for the example, is live." He credits Daniel Terhorst-North and Jez Humble with the name.
The steps, one by one
- Blue is live. Every customer uses the current version.
- The developer puts the new version on green, which no customer can see yet.
- The new version is tested on green with real settings.
- A switch (usually a setting on the load balancer, the traffic director in front of your app) sends all visitors to green.
- The team watches errors and orders for a while.
- If anything breaks, the switch goes back to blue. Fowler calls this "a rapid way to rollback".
What it costs
For a short time you pay for two copies of your app. AWS notes that in the cloud you can shut down the old copy once the update succeeds, and stop paying for it. On a single rented server, a developer can often run two copies side by side, so ask what your setup needs.
Canary deployment vs blue-green: what is the difference?
Blue-green moves all customers to the new version at once. A canary deployment moves a small group first, watches for problems, and then moves more people in stages. Canary is slower but limits how many customers see a bad update.
Danilo Sato explained canary releases on martinfowler.com on 25 June 2014. The name comes from miners who carried a canary into coal mines: if toxic gas leaked, the bird showed it first. To undo it, you "reroute users back to the old version until you have fixed the problem".
| Point | Blue-green deployment | Canary deployment | Update in place |
| Who sees the new version first | Everyone, after testing | A small group | Everyone |
| Downtime during update | Near zero | Near zero | Often some |
| Undo a bad update | Switch back to the old copy | Send the small group back | Rebuild the old version |
| Extra cost | Second copy for a short time | Extra setup to split traffic | None |
| Good for | Most business apps and shops | Apps with many users each day | Very small sites with quiet hours |
Rolling updates: the third common method
Kubernetes, a popular system for running apps on many servers, replaces old copies with new ones a few at a time. Its docs say rolling updates allow an update "to take place with zero downtime". This is its default method.
Blue-green and canary are not A/B testing
The two use similar tools, but the goal differs. Sato puts it plainly: canary releases "are a good way to detect problems". A/B testing "is a way to test a hypothesis", such as which page layout gets more orders.
The database is where zero downtime deployment usually fails
Two copies of your app can sit side by side easily. Your database cannot, because both copies read and write the same orders and customers. If the new version changes how data is stored, the old version may break, and switching back stops being safe.
Fowler's advice is to "separate the deployment of schema changes from application upgrades". A schema is the layout of your data, like the columns of a spreadsheet. First the developer changes the layout so both versions work, checks it, and only then switches the app.
A practical tip most owners miss
Ask your developer to take a database backup just before any update, and to tell you where it is stored. Also ask them to show you one practice rollback on a test copy. A rollback nobody has tried is a guess, not a plan.
If you are planning an order, billing or booking system and want updates that do not stop your counter, see The Beyond Horizon's custom software development service for Indian businesses.
How we handle updates in our own projects
Kafe Kufe, our restaurant software, runs with separate staging and production setups on Railway. Staging is a private copy where changes are checked before customers see them. Its design notes put it plainly: for a restaurant mid-service, a lockout is far worse than brief unauthorised access.
Some updates do not need a deployment at all. YUMI's site reads its headlines, images and FAQs from 18 config files, so content changes go live without a code deploy. In Prodeazy, built for Bang Diamond Tools, admins change form fields and print templates from a settings screen, with no redeployment.
What your hosting may already give you
Some hosts have a rollback button built in. Vercel's Instant Rollback lets a project go back to an earlier live version. On its free Hobby plan you can go back only to the version just before, while Pro and Enterprise plans can pick any eligible earlier one.
What should you ask your developer before the next update?
Ask how an update is tested before customers see it, how fast it can be undone, and what happens to your data if it is undone. The answers matter more than the tool names. Here is a short list to use.
- Is there a staging copy where I can check changes before they go live?
- Do you use blue-green, canary or rolling updates, or do you stop the app to update it?
- How long does it take to go back to the old version, and who can do it?
- Will this update change the database? If yes, is that done as a separate step?
- Is a backup taken before each update, and where is it kept?
- Can updates be done outside my busy hours, such as lunch rush or sale days?
Keeping your app open while it changes
A blue-green deployment is not just for big companies. With today's cloud hosting, a small shop or clinic app can be updated without going dark, as long as the developer plans the database step. If you want your current update process checked, call or WhatsApp The Beyond Horizon on +91 75973 92744.