How to Do Blue-Green Deployments with Argo Rollouts

Introduction

Deploying new versions of applications without causing downtime or service disruption is a top priority for modern DevOps teams. One of the most effective strategies to achieve this is blue-green deployment, which keeps two separate environments one live (blue) and one idle (green) to safely switch traffic during releases.

Argo Rollouts makes implementing blue-green deployments in a Kubernetes cluster simple and reliable. With Argo Rollouts, you can manage the full deployment lifecycle, monitor traffic shifts, and roll back instantly if issues arise.

In this guide, you’ll learn how to set up blue-green deployments using Argo Rollouts, step by step, so your updates are safe, controlled, and production-ready.

Why Blue‑Green Deployments Matter in Kubernetes

When you run applications in Kubernetes, you are always trying to balance safety with speed. You want to ship new versions quickly, but you also want a reliable fallback if something goes wrong. A traditional rolling update with a Deployment can be sufficient for simple changes, but it does not provide strong guarantees if a release seriously misbehaves in production.

Blue‑green deployments were created to solve this. Instead of modifying your existing version in place, you run two full environments side by side:

• One environment (“blue”) is the currently serving version.
• The other environment (“green”) is the new candidate you want to promote.

Traffic flows entirely to one color at a time. When you are confident in the new version, you switch traffic from blue to green in a single, controlled move. If something goes wrong, you still have the old version ready and can flip back without re‑deploying anything.

Argo Rollouts brings this blue‑green pattern directly into Kubernetes. It lets you model blue and green as part of a Rollout resource and uses services (and optionally ingress or service mesh integrations) to control where traffic goes. Instead of wiring all of this logic manually, you declare the behavior once in YAML and let the controller handle the mechanics.

In this guide, you will walk through how blue‑green works conceptually, how Argo Rollouts implements it, and how to design manifests that are safe, predictable, and easy to debug.

Core Concepts: Active, Preview, and the Promotion Switch

A blue‑green deployment is easiest to understand if you picture three main pieces:

• The active environment currently serving real users.
• The preview environment running the new version you want to test and validate.
• The switch mechanism that controls which environment receives production traffic.

In Argo Rollouts, these ideas map to concrete Kubernetes resources.

Active service

The active service is the Kubernetes Service that your users or upstream systems rely on. Other teams may know it by name, dashboards monitor it, and ingress or gateway resources point at it. During normal operation, this service should always route to exactly one color: either blue or green.

With Argo Rollouts, you configure your Rollout so that the active service selector points to the replica set holding the currently promoted version. When you promote a new version, the controller updates which pods the active service targets.

Preview service

The preview service is a second Kubernetes Service that points at the new version but is not wired into normal user traffic flows by default. You can use it for smoke tests, automated checks, QA review, or manual exploration. In some teams, the preview service is exposed through a separate URL that only internal users can reach.

In a blue‑green rollout, the preview service lets you run the new version at production scale and configuration without risking all of your users. You can test configuration, logs, metrics, and integrations while most users remain on the previous stable color.

Promotion and rollback

The final piece is the promotion switch. In Argo Rollouts, promotion means updating which replica set the active service selects. When you promote green, the active service starts routing to the green pods. Blue is still running, but it is no longer receiving production traffic.

If you discover a serious problem, rollback simply means promoting blue again. Because that older version never disappeared, rollback is effectively instantaneous. You are not waiting for new pods to pull images or initialize; you are just sending traffic back to the previously known‑good environment.

Designing a Blue‑Green Rollout in Argo Rollouts

Before you write YAML, it helps to outline how your application and services are structured. Blue‑green deployments work best when the application is stateless or when state changes can be managed carefully across both colors.

Start by deciding:

• Which namespace the rollout will run in.
• What you want to call your active service (often the existing service name you already use).
• What you want to call your preview service (often the same base name with a suffix like -preview).
• How many replicas you need in each environment to handle traffic.

A simple mental model is:

• my-app-active – the service everyone uses.
• my-app-preview – the service only internal testers hit.
• my-app-rollout – the Rollout resource that coordinates everything.

With that map in place, you can start defining the rollout itself.

Example Blue‑Green Rollout Manifest

The following example shows a basic blue‑green rollout with separate active and preview services. The specifics (image, labels, ports) will vary for your environment, but the structure is what matters.

apiVersion: argoproj.io/v1alpha1

kind: Rollout

metadata:

  name: my-app-rollout

  namespace: production

spec:

  replicas: 4

  revisionHistoryLimit: 3

  selector:

    matchLabels:

      app: my-app

  template:

    metadata:

      labels:

        app: my-app

    spec:

      containers:

        - name: my-app

          image: my-registry/my-app:1.0.0

          ports:

            - containerPort: 8080

  strategy:

    blueGreen:

      activeService: my-app-active

      previewService: my-app-preview

      autoPromotionEnabled: false

      autoPromotionSeconds: 0

In this configuration:

• The selector and template labels define how pods are grouped under the rollout.
• blueGreen strategy points at the services that will route traffic.
• autoPromotionEnabled: false tells Argo Rollouts to wait for manual promotion. This gives you time to validate the preview environment before shifting users.

You would pair this rollout with two services:

apiVersion: v1

kind: Service

metadata:

  name: my-app-active

  namespace: production

spec:

  selector:

    app: my-app

  ports:

    - port: 80

      targetPort: 8080

---

apiVersion: v1

kind: Service

metadata:

  name: my-app-preview

  namespace: production

spec:

  selector:

    app: my-app

  ports:

    - port: 80

      targetPort: 8080

Initially, both services will point at the same replica set. As you deploy new versions, Argo Rollouts will create new replica sets and adjust which one is wired to which service.

Running Your First Blue‑Green Deployment

Once your manifests are defined, you can create the rollout and services using kubectl:

kubectl apply -f my-app-bluegreen.yaml

After the resources are created, verify that the rollout exists and is healthy:

kubectl argo rollouts get rollout my-app-rollout -n production

You should see the current revision, which pods are associated with it, and which service is considered active. At this point, your existing version is running under the rollout, and both the active and preview services should resolve to the same pods.

When you are ready to introduce a new version, you change the image in the rollout manifest from 1.0.0 to something like 1.1.0 and apply again.

kubectl apply -f my-app-bluegreen.yaml

Argo Rollouts creates a new replica set for the green version while keeping the blue version running. The preview service starts pointing at the new pods, but the active service remains pinned to the current stable version until you promote.

You can confirm this by checking the rollout status and examining which replica set each service is associated with.

Validating the Preview Environment Safely

A blue‑green deployment pays off when you take validation seriously. Instead of immediately switching traffic, you deliberately spend time verifying the preview version.

Common validation steps include:

• Running automated smoke tests against the preview service URL.
• Having QA or product stakeholders manually explore critical flows.
• Monitoring logs and metrics for unusual errors, latency spikes, or resource usage.

You may wire the preview service to a separate ingress path such as preview.my-app.example.com that only internal users can access. That way, you can perform realistic tests with production‑like dependencies without accidentally exposing unstable behavior to customers.

As you validate, pay attention not only to functional correctness, but also to:

• Startup behavior and readiness times.
• Compatibility with existing database schemas or external APIs.
• Performance under expected load.

If anything looks off, you can choose to fix the issue and build a new version rather than promoting the current candidate.

Promoting the Green Version to Production

When you are confident in the new version, you are ready to promote it. With autoPromotionEnabled: false, promotion is a deliberate manual action.

You can promote directly from the CLI:

kubectl argo rollouts promote my-app-rollout -n production

This command instructs Argo Rollouts to switch the active service from blue to green. Under the hood, the controller updates service selectors to point at the new replica set. Existing connections are drained naturally as pods stop receiving traffic from the active service.

From the user’s point of view, the transition should feel nearly instantaneous. There is no lengthy rolling update; instead, traffic begins targeting the green pods almost at once.

After promotion, continue watching metrics and logs closely. You have moved real traffic onto the new version, so any regressions should be detected quickly. Many teams treat the first minutes or hours after promotion as a heightened observation window.

Rolling Back Quickly if Something Goes Wrong

Even with thorough validation, problems sometimes show up only when a full production load hits the new version. One of the biggest advantages of blue‑green deployments is how quickly rollbacks become.

If you notice severe errors, rising latency, or unexpected behavior shortly after promotion, you can instruct Argo Rollouts to roll back by promoting the previous revision.

kubectl argo rollouts promote my-app-rollout -n production –to-revision=<previous-revision>

Because the blue version is still running and healthy, this rollback is simply another traffic switch. You do not need to build new images or reapply manifests; you are telling the controller to re‑designate which replica set should be wired to the active service.

After the rollback, you can leave the green version in place for investigation or scale it down to free up capacity. The key is that your users see the rollback’s impact almost immediately.

Operational Considerations and Best Practices

Blue‑green deployments can look straightforward in a demo, but real‑world systems add complexity. A few practical guidelines will help keep things manageable.

First, be intentional about resource usage. Running both blue and green at full capacity doubles the resource footprint while both are live. On smaller clusters, this may cause scheduling problems or noisy neighbor effects. If full duplication is too expensive, you can temporarily run green at lower replica counts while still exercising the deployment path and most functionality.

Second, pay close attention to stateful components. If your application writes to a shared database, both blue and green may interact with the same data. Schema migrations, background jobs, and data‑shaping logic must be compatible with both versions during the overlap window. It is often safer to design forward‑compatible changes and phase in destructive migrations only after the new version has fully replaced the old.

Third, document traffic routing clearly. People should know which URLs or ingress paths point at the active environment and which expose the preview. Monitoring and alerting need to align with this understanding so teams are not surprised when dashboards suddenly shift as traffic moves.

Finally, embed blue‑green into your release culture rather than treating it as a special operation. Create standard runbooks, define clear promotion criteria, and make rollback an accepted response rather than a failure. When teams see blue‑green as a normal part of shipping, they are more willing to use it early and often.

Conclusion: Using Argo Rollouts to Make Blue‑Green Practical

Blue‑green deployments give you a powerful way to introduce new versions without betting the entire production environment on a single change. By running two complete environments side by side and switching traffic in a controlled way, you gain fast rollback, predictable behavior, and a safer place to experiment.

Argo Rollouts brings this pattern into Kubernetes as a first‑class strategy. By defining a Rollout resource with blue‑green settings, active and preview services, and clear promotion rules, you can automate most of the heavy lifting that used to require custom scripts and manual coordination.

As you adopt blue‑green with Argo Rollouts, start with a non‑critical service, refine your manifests and runbooks, and gradually bring more applications under this strategy. Over time, your deployments can become both faster and more reliable, giving your team confidence to ship improvements more frequently.

FAQs: Blue‑Green Deployments With Argo Rollouts

Latest Post:

• How Argo Rollouts Works: Canary & Blue-Green Strategies
• Argo Rollouts Features: Blue-Green, Canary & Traffic Control
• Argo Rollouts vs Kubernetes Deployments: Key Differences & Benefits
• Is Argo Rollouts Safe? Security & Production Readiness Explained
• Business Use Cases for Argo Rollouts: Safe Deployments, KPIs & Continuous Delivery