🚦Intermediate20 minCI/CD

Set up a CI/CD pipeline with blue-green deploys

Define a multi-stage pipeline, gate production behind a manual approval, and switch traffic blue-green so a bad release is one click away from rollback.

What you'll build

A build → test → staging → approval → production pipeline
Blue-green traffic switching with a health gate
One-click rollback by flipping the active slot

Before you begin

A registered node and a deployed app to put a pipeline around
A Git provider connected (GitHub, GitLab, or Jenkins)
Completed at least one deploy tutorial

Create the pipeline

Go to CI/CD → Pipelines → New. A pipeline binds a repo to build/install/start commands and a target. It’s stored in the pipelines model with a JSONB config that holds your stages.

app.prodxcloud.com/cicd

ProvidergithubRepositoryacme/orders-apiBuild commandnpm ci && npm run buildTargetnode: api-prod-fra-1

A pipeline is repo + commands + a staged config.

Define the stages

Stages live under config.stages. Add a manual-approval gate before production and turn on blue-green for the production stage:

pipeline config.stages

{
  "stages": [
    { "name": "build", "image": "node:20", "script": ["npm ci", "npm run build"] },
    { "name": "test",  "image": "node:20", "script": ["npm test"] },
    { "name": "deploy-staging", "environment": "staging",
      "script": ["docker build -t app:${COMMIT_SHA} .", "docker push registry/app:${COMMIT_SHA}"] },
    { "name": "manual-approval", "type": "approval", "required_reviewers": 1 },
    { "name": "deploy-production", "environment": "production",
      "blue_green_enabled": true }
  ]
}

Each run is recorded

Every push creates a builds row (commit, status, duration, logs) and each promotion a deployments row — that’s your audit trail and rollback index.

Configure blue-green switching

Blue-green keeps two slots. New releases deploy to the idle slot; traffic only moves once the health check passes. Set this in the production stage’s deployment_config:

deployment_config

{
  "blue_green_enabled": true,
  "active_slot": "blue",
  "health_check_path": "/health",
  "health_check_interval_seconds": 5,
  "traffic_switch_type": "instant",
  "rollback_trigger": "error_rate > 5%"
}

Canary instead of instant

Set traffic_switch_type: "canary" with canary_percentage: 10 to bleed 10% of traffic to green first and auto-rollback if the error rate trips.

Run it and approve production

Push to the branch. The pipeline runs through to the approval gate and waits for a human.

Deployment progress100%

build25%
test45%
deploy-staging (green slot)65%
manual-approval — waiting for reviewer75%
deploy-production + health gate100%

Production never proceeds until a reviewer approves and the new slot is healthy.

Roll back in one click

Because the previous release is still warm in the other slot, rollback is a slot flip — no rebuild, seconds not minutes:

bash

# Flip traffic back to the last good slot$ vxcli deploy rollback --pipeline orders-api --to blueactive_slot: green -> blue (traffic switched in 1.8s)

Safe releases

Gated promotion + warm standby + instant rollback. Next, run this same pipeline headlessly from GitHub Actions with vxcli.

Nice work — you're done!

You completed Set up a CI/CD pipeline with blue-green deploys. Keep the momentum going with the next walkthrough, or jump back to the full catalog.

Next: Run vxcli inside GitHub Actions All tutorials

Provision MetalDB — self-hosted Postgres Run vxcli inside GitHub Actions