Blue-Green Deployments with Flightcontrol

Blue-Green deployment is a deployment strategy that enables zero-downtime deployments by maintaining two identical production environments. This allows you to deploy new versions of your application, test them in a production-like environment, and then seamlessly switch traffic to the new version.

What is Blue-Green Deployment?

In a Blue-Green deployment strategy, you maintain two separate but identical environments:

• Blue Environment - Always serves production traffic
• Green Environment - Always serves as standby/preview for testing new deployments

At any time, one environment (Blue) serves live production traffic while the other (Green) is idle or serves preview traffic. When you’re ready to release a new version, you simply swap which environment receives production traffic.

How It Works

Flightcontrol’s Blue-Green deployment implementation uses the following architecture:

Architecture Overview

1. Two ECS Services - Flightcontrol creates two separate ECS services that can run your application
2. Two Target Groups - Each ECS service is bound to its own Application Load Balancer target group
3. Load Balancer Routing - The load balancer routes traffic based on rules:
   • Default action → Routes production traffic to the Blue environment
   • Header-based rule → Routes preview traffic to the Green environment

Deployment Flow

When you enable Blue-Green deployments:

1. Initial Setup - Flightcontrol provisions both Blue and Green environments
2. First Deployment - Your application is deployed to the Blue (production) environment
3. Subsequent Deployments - New deployments always go to the Green (standby) environment first
4. Testing - You can test the Green environment using a special header before swapping
5. Swapping - When ready, you swap Blue and Green, making the Green environment become production
6. Rollback - If issues occur, you can swap again to revert back
7. Pre/Post-Deploy Commands - Pre-deploy and post-deploy commands execute normally during each deployment to the Green environment, before you swap to production

Key Principles

• Blue = Always Production - The Blue slot always represents the current production environment
• Green = Always Standby - The Green slot always represents the standby/preview environment
• Services are Interchangeable - The actual ECS services swap between Blue and Green slots

Configuration

To enable Blue-Green deployments for a service, add the deploy configuration to your service’s target property in flightcontrol.json:

Requirements

• Service type must be "web" or "worker"
• Works with any target type (fargate, ec2, etc.)

Sample Configuration

{
  "$schema": "https://app.flightcontrol.dev/schema.json",
  "environments": [
    {
      "id": "production",
      "name": "Production",
      "region": "us-west-2",
      "source": {
        "branch": "main"
      },
      "services": [
        {
          "id": "my-web-service",
          "name": "My Web Service",
          "type": "web",
          "buildType": "nixpacks",
          "target": {
            "type": "fargate"
          },
          "deploy": {
            "type": "bluegreen",
            "greenAutoShutdownTimeoutInHours": 1
          },
          "cpu": 1,
          "memory": 2,
          "minInstances": 2,
          "maxInstances": 4,
          "buildCommand": "npm run build",
          "startCommand": "npm start"
        }
      ]
    }
  ]
}

Configuration Options

• type (required) - Set to "bluegreen" to enable Blue-Green deployments
• greenAutoShutdownTimeoutInHours (optional) - Number of hours to wait before shutting down the old Green environment after a swap. If not specified, the Green environment will not be shut down automatically. This gives you time to quickly rollback if needed.

Testing Before Swap

Before swapping your Blue and Green environments, you should test the Green (standby) environment to ensure the new deployment works correctly.

Preview Header

Flightcontrol automatically creates a custom header rule that routes traffic to the Green environment. You can find the header name and value in the Flightcontrol dashboard under your service’s Domains section.

The header format is:

• Header Name: x-fc-green-deployment
• Header Value: A unique value specific to your service (displayed in the UI)

Testing with curl

To test your Green environment before swapping:

curl -H "x-fc-green-deployment: <your-unique-value>" https://your-service.com

Replace <your-unique-value> with the actual header value shown in your Flightcontrol dashboard.

Testing with Browser

You can also use browser extensions like “ModHeader” to add the custom header to your browser requests, allowing you to browse your Green environment as if it were production.

Swapping Blue and Green

Once you’ve tested your Green environment and are confident it’s working correctly, you can swap the Blue and Green environments to make the new deployment live.

Using the Dashboard

In the Flightcontrol dashboard:

1. Navigate to your service’s overview page
2. Find the Blue-Green Deployment section
3. Click the Swap blue / green button

The swap process will:

1. Verify both services are stable
2. Synchronize the desired instance count between services
3. Swap the load balancer routing (default action and header rule switch)
4. Scale down the old production service (now in Green slot) after the grace period

Using the API

You can also trigger swaps programmatically via the API. See the Swap Blue-Green API documentation for details.

curl -X POST \
  https://api.flightcontrol.dev/v1/services/{serviceId}/swap-blue-green \
  -H "Authorization: Bearer YOUR_API_KEY"

Rollback Strategy

If you discover issues after swapping to a new version, Blue-Green deployments make rollback simple:

Immediate Rollback

Simply swap again! The previous version is still running in the Green (standby) slot, so swapping back promotes it to production immediately.

1. Click the Swap blue / green button again
2. The previous version becomes production (Blue)
3. The problematic version moves to standby (Green)

This is much faster than traditional rollback strategies because:

• No need to rebuild the previous version
• The previous version is already running and warm
• Database state is preserved (unless you made schema changes)

Best Practices

1. Test Thoroughly in Green

Always test your Green environment before swapping. Use the preview header to:

• Verify all functionality works correctly
• Check performance metrics
• Test critical user flows
• Validate integrations with external services

2. Database Migrations

Handle database migrations carefully:

• Use backward-compatible migrations when possible
• Run migrations as part of the deployment (before swap)
• Test migrations in a staging environment first
• Have a migration rollback plan ready

3. Monitor After Swap

After swapping:

• Watch application logs for errors
• Monitor performance metrics
• Check error tracking services (Sentry, etc.)
• Keep an eye on customer support channels

4. Gradual Rollout

Consider keeping the grace period longer (e.g., 2-4 hours) during business hours so you can quickly rollback if needed.

Troubleshooting

If you encounter issues with Blue-Green deployments, check:

1. Swap Button Disabled - The Green environment may not have a deployment yet, or a swap operation is already in progress
2. Deployment Failures - Deployments always go to the Green slot first. Check the deployment logs if builds are failing
3. Header Not Working - Verify you’re using the exact header value shown in the dashboard (it’s case-sensitive)
4. Swap Timeouts - If services aren’t stable, the swap may fail. Check service health in AWS ECS console

If you need help, contact support with your service ID and environment details.