The Agentic Blue/Green Deployment Pipeline
Blue/green deployments are the gold standard for zero-downtime releases: you run the new version (green) alongside the old version (blue), switch traffic to green when it is healthy, and tear down blue. Deployxa handles blue/green deployments automatically via Traefik v3, but for teams that want more control (e.g., custom health checks, staged rollout, automatic rollback), an agentic pipeline that orchestrates the deployment is the right approach. With the Deployxa MCP server and an LLM, you can build a pipeline that handles blue/green deployments automatically, with custom health checks, staged rollout, and automatic rollback. Here is how.
The direct answer is that an agentic blue/green deployment pipeline is a script that orchestrates the deployment: it deploys the new version (via deployxa_deploy_workflow), waits for the new version to be healthy (via deployxa_doctor), switches traffic to the new version (automatic via Traefik), monitors the new version for issues (via deployxa_get_metrics), and rolls back if issues are detected (via deployxa_rollback_release). The pipeline uses an LLM to interpret the health check results and make go/no-go decisions, which means it can handle complex scenarios (e.g., "the new version is technically healthy but the error rate is 2x higher than the old version, which suggests a subtle issue"). For more on blue/green deployments, see our article on Traefik v3 dynamic routing.
Why Manual Blue/Green Deployments Are Risky
Three problems make manual blue/green deployments risky. First, they are slow. A manual deployment involves multiple steps (deploy, check health, switch traffic, monitor, roll back if needed), each of which takes time, which means the deployment window is long. Second, they are error-prone. A human might forget to check a health metric, might misinterpret an error, or might not notice a subtle performance regression. Third, they do not happen at 3 AM. If an issue is detected after the deployment, a human needs to be woken up to roll back, which means the issue persists until the human responds. An agentic pipeline solves all three problems: it is fast (executes in seconds), reliable (checks all health metrics), and automatic (rolls back without human intervention). For more on agentic patterns, see our article on the agentic incident response pipeline.
What the Pipeline Does
The agentic blue/green deployment pipeline performs the following tasks:
- Deploy the new version. The pipeline calls deployxa_deploy_workflow to deploy the new version, which starts the green container alongside the blue container.
- Wait for the green container to be healthy. The pipeline calls deployxa_doctor on the green container, waiting for the readiness grade to be A or B.
- Switch traffic to the green container. Traefik switches traffic from blue to green atomically, once the green container is healthy.
- Monitor the green container. The pipeline monitors the green container for a configurable period (e.g., 5 minutes), checking metrics (error rate, response time, CPU usage) via deployxa_get_metrics.
- Compare to the blue container's baseline. The pipeline compares the green container's metrics to the blue container's baseline (collected before the deployment). If the green container's metrics are significantly worse (e.g., error rate 2x higher), the pipeline rolls back.
- Roll back if needed. If the green container's metrics are worse than the baseline, the pipeline calls deployxa_rollback_release to switch traffic back to blue.
- Report the result. The pipeline sends a Slack notification with the deployment result (success or rollback, metrics comparison, recommendation).
Step-by-Step: Building the Pipeline
Here is how to build the agentic blue/green deployment pipeline in Python, using the Deployxa MCP server and an LLM.
Step 1: Install dependencies
pip install openai requests schedule
npm install -g @deployxa/mcp-server
deployxa-mcp loginStep 2: Create the pipeline script
# blue_green.py
import openai
import requests
import time
import json
from datetime import datetime
# Configuration
APP_ID = "123"
APP_NAME = "acme-frontend"
SLACK_WEBHOOK_URL = "https://hooks.slack.com/services/..."
DEPLOYXA_MCP_URL = "http://localhost:3000/mcp"
MONITORING_PERIOD_SECONDS = 300 # 5 minutes
BASELINE_ERROR_RATE_THRESHOLD = 2.0 # 2x baseline error rate triggers rollback
def call_deployxa(tool, params):
"""Call a Deployxa MCP tool."""
response = requests.post(
DEPLOYXA_MCP_URL,
json={"tool": tool, "params": params},
)
return response.json()
def send_slack_notification(message, is_alert=False):
"""Send a Slack notification."""
emoji = "🚨" if is_alert else "✅"
requests.post(SLACK_WEBHOOK_URL, json={"text": f"{emoji} {message}"})
def get_baseline_metrics():
"""Get the baseline metrics before deployment."""
metrics = call_deployxa("deployxa_get_metrics", {"app_id": APP_ID})
return {
"error_rate": metrics.get("error_rate", 0),
"response_time": metrics.get("avg_response_time", 0),
"cpu_usage": metrics.get("cpu_usage", 0),
"memory_usage": metrics.get("memory_usage", 0),
}
def deploy_new_version():
"""Deploy the new version."""
print(f"[{datetime.utcnow().isoformat()}] Deploying new version of {APP_NAME}...")
result = call_deployxa("deployxa_deploy_workflow", {"app_id": APP_ID})
return result
def wait_for_health():
"""Wait for the new version to be healthy."""
print("Waiting for new version to be healthy...")
for i in range(60): # Wait up to 5 minutes
doctor = call_deployxa("deployxa_doctor", {"app_id": APP_ID})
grade = doctor.get("grade", "F")
if grade in ["A", "B"]:
print(f" New version is healthy (grade: {grade})")
return True, grade
print(f" Waiting... (current grade: {grade})")
time.sleep(5)
print(" New version did not become healthy in time")
return False, "F"
def monitor_new_version(baseline):
"""Monitor the new version for the monitoring period."""
print(f"Monitoring new version for {MONITORING_PERIOD_SECONDS} seconds...")
metrics_history = []
for i in range(MONITORING_PERIOD_SECONDS // 10): # Check every 10 seconds
metrics = call_deployxa("deployxa_get_metrics", {"app_id": APP_ID})
metrics_history.append({
"error_rate": metrics.get("error_rate", 0),
"response_time": metrics.get("avg_response_time", 0),
"cpu_usage": metrics.get("cpu_usage", 0),
"memory_usage": metrics.get("memory_usage", 0),
})
time.sleep(10)
# Calculate average metrics
avg_metrics = {
"error_rate": sum(m["error_rate"] for m in metrics_history) / len(metrics_history),
"response_time": sum(m["response_time"] for m in metrics_history) / len(metrics_history),
"cpu_usage": sum(m["cpu_usage"] for m in metrics_history) / len(metrics_history),
"memory_usage": sum(m["memory_usage"] for m in metrics_history) / len(metrics_history),
}
return avg_metrics
def analyze_with_llm(baseline, current):
"""Use an LLM to analyze the metrics and decide whether to roll back."""
client = openai.OpenAI()
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{
"role": "system",
"content": """You are a deployment analysis agent. Compare the baseline metrics (before deployment) to the current metrics (after deployment) and decide whether to keep the new version or roll back.
Return a JSON object with:
- "decision": "keep" or "rollback"
- "reason": a plain-English explanation
- "confidence": your confidence (0-1)
Guidelines:
- Roll back if the error rate is more than 2x the baseline
- Roll back if the response time is more than 1.5x the baseline
- Keep if the metrics are similar or better
- Be conservative: if in doubt, roll back
"""
},
{
"role": "user",
"content": f"""Baseline metrics:
Error rate: {baseline['error_rate']:.2%}
Response time: {baseline['response_time']:.0f}ms
CPU usage: {baseline['cpu_usage']:.1%}
Memory usage: {baseline['memory_usage']:.1%}
Current metrics (after deployment):
Error rate: {current['error_rate']:.2%}
Response time: {current['response_time']:.0f}ms
CPU usage: {current['cpu_usage']:.1%}
Memory usage: {current['memory_usage']:.1%}
"""
}
]
)
return json.loads(response.choices[0].message.content)
def rollback():
"""Roll back to the previous version."""
print("Rolling back...")
result = call_deployxa("deployxa_rollback_release", {
"app_id": APP_ID,
"confirmed": True,
})
return result
def run_blue_green_deployment():
"""Run the full blue/green deployment pipeline."""
# Step 1: Get baseline metrics
baseline = get_baseline_metrics()
print(f"Baseline: error_rate={baseline['error_rate']:.2%}, response_time={baseline['response_time']:.0f}ms")
# Step 2: Deploy the new version
deploy_result = deploy_new_version()
if deploy_result.get("status") != "success":
send_slack_notification(f"Deployment of {APP_NAME} failed: {deploy_result.get('error')}", is_alert=True)
return
# Step 3: Wait for the new version to be healthy
is_healthy, grade = wait_for_health()
if not is_healthy:
send_slack_notification(
f"Deployment of {APP_NAME} failed health check (grade: {grade}). Rolling back.",
is_alert=True
)
rollback()
return
# Step 4: Monitor the new version
current = monitor_new_version(baseline)
print(f"Current: error_rate={current['error_rate']:.2%}, response_time={current['response_time']:.0f}ms")
# Step 5: Analyze with LLM
analysis = analyze_with_llm(baseline, current)
print(f"LLM decision: {analysis['decision']} (confidence: {analysis['confidence']})")
print(f"Reason: {analysis['reason']}")
# Step 6: Keep or roll back
if analysis["decision"] == "keep":
send_slack_notification(
f"Deployment of {APP_NAME} successful!\n"
f" Grade: {grade}\n"
f" Error rate: {baseline['error_rate']:.2%} -> {current['error_rate']:.2%}\n"
f" Response time: {baseline['response_time']:.0f}ms -> {current['response_time']:.0f}ms\n"
f" Decision: {analysis['reason']}"
)
else:
send_slack_notification(
f"Rolling back {APP_NAME} deployment.\n"
f" Reason: {analysis['reason']}\n"
f" Error rate: {baseline['error_rate']:.2%} -> {current['error_rate']:.2%}\n"
f" Response time: {baseline['response_time']:.0f}ms -> {current['response_time']:.0f}ms",
is_alert=True
)
rollback()
if __name__ == "__main__":
run_blue_green_deployment()Step 3: Run the pipeline
python blue_green.pyThe pipeline deploys the new version, waits for it to be healthy, monitors it, and rolls back if needed.
Step 4: Integrate with CI/CD
Add the pipeline to your CI/CD (e.g., GitHub Actions), so it runs automatically on every push to main:
# .github/workflows/deploy.yml
name: Blue/Green Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v4
with:
python-version: '3.11'
- run: pip install openai requests
- run: python blue_green.py
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}Common Pitfalls and Troubleshooting
The first pitfall is not collecting a baseline. Without a baseline, you cannot compare the new version's metrics to the old version's, which means you cannot detect subtle regressions. The fix is to always collect baseline metrics before the deployment. The second pitfall is not monitoring long enough. If the monitoring period is too short (e.g., 1 minute), you might miss issues that only appear under sustained load. The fix is to monitor for at least 5 minutes, or longer for high-traffic apps. The third pitfall is not rolling back fast enough. If an issue is detected, you need to roll back immediately, not wait for human approval. The fix is to automate the rollback (with the confirmed: true parameter) and to notify the team after the rollback. The fourth pitfall is false positives. The LLM might recommend a rollback for a transient issue (e.g., a temporary spike in error rate) that resolves itself. The fix is to use conservative thresholds and to average metrics over the monitoring period. The fifth pitfall is not testing the pipeline. The pipeline itself is code, which means it needs to be tested. The fix is to test the pipeline in staging before using it in production. For more on testing, see our article on the testing void.
Advanced Pipeline Patterns
Beyond the basics, the blue/green pipeline can be extended with several advanced patterns. The first is staged rollout. Instead of switching all traffic to the new version at once, the pipeline can gradually shift traffic (e.g., 10 percent, 25 percent, 50 percent, 100 percent), monitoring at each stage. The second is canary deployment. The pipeline can deploy the new version to a small subset of users (e.g., internal employees, beta users) before rolling it out to everyone. The third is automatic rollback on alert. The pipeline can integrate with your alerting system (e.g., PagerDuty) and roll back automatically when an alert fires. The fourth is multi-region rollout. For apps that run in multiple regions, the pipeline can roll out to one region first, monitor, and then roll out to other regions. The fifth is A/B testing. The pipeline can run the new version alongside the old version, split traffic between them, and compare the metrics, which lets you test the new version's impact on user behavior. For more on advanced patterns, see our articles on Traefik v3 dynamic routing and the agentic incident response pipeline.
Conclusion: Automate Your Blue/Green Deployments
Manual blue/green deployments are slow, error-prone, and do not happen at 3 AM. An agentic pipeline that orchestrates the deployment, monitors the new version, and rolls back if needed is the sustainable solution. With the Deployxa MCP server and an LLM, you can build a pipeline that handles blue/green deployments automatically, with custom health checks and automatic rollback. Stop manually deploying and start letting the agent do it for you.
Ready to build your blue/green pipeline? Install the Deployxa MCP server with npm i -g @deployxa/mcp-server, run deployxa-mcp login, and start building. For more on agentic workflows, see our articles on the agentic cost optimization pipeline and building a custom AI deployment assistant. Learn about building an AI agent that cleans up unused resources and the agentic incident response pipeline in our companion articles. Explore our free developer tools to speed up your workflow.