Zero-downtime blue-green releases

When it applies

Blue-green is used automatically for applications that are published on a domain through the reverse proxy, because that is where traffic can be moved from one container to another.

An application with no domain has nothing to switch traffic between, so it is recreated normally: the container is replaced in place.

The sequence

1. 01The new image is pulled.
2. 02A candidate container is started next to the running one, with the same configuration, networks, volumes and health check.
3. 03MihraOps waits for the candidate to report healthy. A container that stops or reports unhealthy fails the deployment right here — before any traffic reaches it.
4. 04The proxy is pointed at the candidate.
5. 05The old container is renamed aside and the candidate takes its name.
6. 06The proxy configuration is restored, now resolving to the new container.
7. 07The old container is stopped and removed.

What happens when it fails

Every step above is undone in reverse if the one after it fails. Traffic goes back to the container that was serving it, the candidate is removed, and the release is reported as failed. The version your users were on keeps running.

Health checks decide the outcome

The candidate is judged by the health check defined in your image or compose file. Without one, MihraOps can only confirm that the container is still running — which is a much weaker signal.

If you take one thing from this page: add a HEALTHCHECK that actually exercises your application. It is what turns a blue-green deploy from a rename into a safety net.