I’ve been there—pushing an update late on a Friday, holding my breath, and watching the monitoring dashboards light up with errors. It’s a feeling every developer knows too well. That moment of vulnerability, where a single deployment can disrupt real users, is what pushed me to find a better way. Today, I want to share a method that changed how my team ships software: setting up blue-green deployments. This approach lets you release new versions without stopping your application, and I’ll show you how to build it with tools you likely already use: Spring Boot and Kubernetes, with Spring Cloud Gateway steering the traffic.
So, what is a blue-green deployment? Think of it like having two identical stages for a play. One stage, Blue, has the current show running for the audience. The other, Green, is a hidden stage where the crew sets up the next act. When the new act is ready and tested, you flip a switch. The audience is instantly directed to the new stage. They never see the set change, and the show never stops. In technical terms, you maintain two separate but identical production environments. Only one receives live user traffic at a time.
Why go through this effort? Because downtime, even for a few seconds, can mean lost revenue, frustrated users, and eroded trust. A blue-green setup removes that risk. It gives you a clean, fast way to switch versions and an equally fast way to revert if something goes wrong. It turns deployment from a stressful event into a routine, safe operation.
Let’s build this from the ground up. We start with the application itself. Your Spring Boot service needs to be aware of which environment—Blue or Green—it’s running in. This is key: the exact same compiled artifact (your JAR file) should be deployable to either slot. We use environment variables to tell the application its identity.
Here’s a basic example. In your application.yml, you define placeholders that Kubernetes will fill.
deployment:
slot: ${DEPLOYMENT_SLOT:blue}
version: ${APP_VERSION:1.0.0}Then, a simple controller can expose this information. This becomes vital later for the gateway to check where it’s sending traffic.
@Value("${deployment.slot}")
private String slot;
@GetMapping("/info")
public DeploymentInfo info() {
return new DeploymentInfo("my-service", slot, "1.2.3");
}But how do we ensure the new ‘Green’ environment is truly ready for real users? We can’t just assume it works because it started. This is where a readiness gate becomes essential. Beyond the standard Kubernetes liveness probe, we add a custom health check that the service itself controls.
I implement a custom Spring Boot Actuator HealthIndicator. When the Green deployment starts, this indicator reports the service as OUT_OF_SERVICE. It stays that way until our deployment pipeline runs a set of integration or smoke tests against it. Only after these tests pass does an internal flag get set, changing the health status to UP. This is our signal that promotion is safe.
@Component
public class DeploymentReadinessHealthIndicator implements HealthIndicator {
private AtomicBoolean isWarmedUp = new AtomicBoolean(false);
public Health health() {
if (isWarmedUp.get()) {
return Health.up().withDetail("ready-for-traffic", true).build();
}
return Health.outOfService().withDetail("ready-for-traffic", false).build();
}
public void markAsReady() {
isWarmedUp.set(true);
}
}Now, picture this: your new version is running in the Green slot and has passed its health gate. How does user traffic get to it? This is the role of the API Gateway. We use Spring Cloud Gateway as the single entry point for all traffic. Its configuration isn’t static; we design it to be dynamic.
The gateway’s routing rules are based on a simple external value—like a Kubernetes ConfigMap—that stores the name of the active slot: “blue” or “green”. All traffic for a path like /api/orders is directed to the Kubernetes Service for that active slot. Changing traffic is as simple as updating that one value in the ConfigMap and refreshing the gateway’s routes. Have you considered what happens if a bug only appears under full production load? This setup lets you find out on the Green stage without affecting a single Blue user.
Let’s look at the Kubernetes side. We don’t have one Deployment; we have two: myapp-blue and myapp-green. They are identical except for labels and the environment variable that sets the DEPLOYMENT_SLOT. They are connected to two different Kubernetes Services: myapp-blue-svc and myapp-green-svc. These Services are how other pods, like our gateway, find the right set of pods.
The gateway’s configuration points to these service names. Here is a simplified version of how a route might be defined in code, reading the active slot from a property.
@Bean
public RouteLocator customRouteLocator(RouteLocatorBuilder builder, SlotService slotService) {
return builder.routes()
.route("myapp_route", r -> r
.path("/api/**")
.uri("http://myapp-" + slotService.getActiveSlot() + "-svc:8080"))
.build();
}The magic happens in the promotion process. A script or a dedicated “promotion controller” application manages this sequence. First, it checks the readiness health endpoint of the Green environment. If it’s not UP, the process stops. If it is healthy, the controller updates the active-slot ConfigMap from “blue” to “green”. It then tells the Spring Cloud Gateway to refresh its routes. Within moments, all new requests flow to the new version.
But we’re not done. The controller now monitors the Green environment’s metrics and error rates for a short period. If something spikes unexpectedly, it immediately switches the ConfigMap back to “blue”. This is the rollback safety net, and it can often happen before most users notice a problem. What does this mean for team confidence? It transforms deployment anxiety into a predictable, automated procedure.
Putting it all together requires practice. You begin by packaging your application into a container image. Your CI/CD pipeline first deploys this image to the Green Kubernetes Deployment, scaling it up while Blue handles live traffic. The pipeline then runs automated tests against the Green service’s internal endpoints. If they pass, it calls the actuator endpoint to mark the service as ready. Finally, it executes the promotion script to switch traffic.
This setup might seem involved, but the payoff is immense. You gain the ability to release updates during peak business hours. You can perform A/B testing by slowly directing a percentage of traffic to Green. Most importantly, you get sleep-filled nights, knowing a failed deployment isn’t a crisis.
The path to smooth, reliable deployments is within reach. By combining Spring Boot’s flexibility with Kubernetes’ orchestration and Spring Cloud Gateway’s smart routing, you build a system that serves your users continuously. This isn’t just about technology; it’s about delivering value reliably and without fear. I encourage you to try setting up a single service this way. Start small, learn the process, and scale the pattern.
Was this walkthrough helpful? Do you have a different strategy for managing deployment risk? I’d love to hear about your experiences and questions. If you found this guide useful, please share it with a teammate who might be facing these same deployment challenges. Let’s build more resilient systems together.
As a best-selling author, I invite you to explore my books on Amazon. Don’t forget to follow me on Medium and show your support. Thank you! Your support means the world!
101 Books
101 Books is an AI-driven publishing company co-founded by author Aarav Joshi. By leveraging advanced AI technology, we keep our publishing costs incredibly low—some books are priced as low as $4—making quality knowledge accessible to everyone.
Check out our book Golang Clean Code available on Amazon.
Stay tuned for updates and exciting news. When shopping for books, search for Aarav Joshi to find more of our titles. Use the provided link to enjoy special discounts!
📘 Checkout my latest ebook for free on my channel!
Be sure to like, share, comment, and subscribe to the channel!
Our Creations
Be sure to check out our creations:
Investor Central | Investor Central Spanish | Investor Central German | Smart Living | Epochs & Echoes | Puzzling Mysteries | Hindutva | Elite Dev | JS Schools
We are on Medium
Tech Koala Insights | Epochs & Echoes World | Investor Central Medium | Puzzling Mysteries Medium | Science & Epochs Medium | Modern Hindutva
