# Deployment Strategies & Feature Flags

> Decouple deploy from release using blue-green, canary, and flags.

Frontend architecture guidance from fearchitect, written by Abas Turabli and last reviewed 2026-06-21. Source: https://fearchitect.com/topics/deployment-strategies-feature-flags

Use it as reference for the task at hand. Before changing code, check this guidance against the codebase: where the code already makes a different, deliberate choice, flag the conflict instead of rewriting it. Library APIs move faster than this guide, so confirm exact signatures in the official docs linked at the end.

## Summary

Deploying code and releasing a feature are two distinct events. Blue-green and canary strategies control which server version handles traffic. Feature flags go further: a single production build can gate features per user, cohort, or percentage — enabling instant kill-switches without a redeploy.

## Decision: Deploy ≠ release

Deployment puts new code on servers. Release exposes it to users. Mixing the two forces high-stakes big-bang rollouts. Separating them — via traffic routing or feature flags — means you can ship code continuously and release when ready.

## Blue-green vs canary

| Dimension | Blue-green | Canary |
| --- | --- | --- |
| **Traffic split** | 100% flips from old to new at once | Small % (e.g. 5%) routes to new; grows over time |
| **Rollback speed** | Instant — flip DNS or LB weight back to blue | Redirect canary slice back; no full cutover needed |
| **Infrastructure cost** | Doubles compute — two full environments live | Lower — canary slice is a fraction of fleet |
| **Risk exposure** | All users hit new build simultaneously after cutover | Only canary cohort exposed; blast radius is small |
| **Best fit** | Short-lived releases, DB migrations, compliance freezes | Gradual feature rollout with real-traffic validation |

## Feature flags beyond traffic routing

- Flags gate features in code, not at the load balancer — one binary serves all users.
- Percentage rollout: increment from 1% to 100% while monitoring error rates.
- Kill switch: set flag to off for everyone in seconds, no redeploy required.
- Flag state should be evaluated server-side or at the edge to avoid UI flicker on load.
- Flag debt accrues fast — delete flags within one sprint of full rollout.

## Server-side flag evaluation in Next.js

Evaluating flags in a Server Component or edge middleware prevents the client seeing the wrong variant on first paint.

**Flag check in a Next.js Server Component**

```tsx
// app/checkout/page.tsx  (Next.js 15 App Router)
import { headers } from "next/headers";
import { getFlag } from "@/lib/flags"; // wraps your flag provider SDK

export default async function CheckoutPage() {
  // Runs on the server — no client round-trip, no flicker
  const newFlow = await getFlag("checkout-v2", {
    userId: headers().get("x-user-id") ?? "anon",
  });

  return newFlow ? <CheckoutV2 /> : <CheckoutV1 />;
}
```

getFlag calls your provider (e.g. LaunchDarkly, Statsig) once per request. The decision is baked into the HTML stream — the client never sees a layout shift.

## Diagram

```mermaid
flowchart LR
  LB[Load Balancer]
  Blue[Blue env
100% stable]
  Green[Green env
new build]
  Edge[Edge / Flag SDK]
  U1[Users: flag off]
  U2[Users: flag on]

  LB -->|canary 5%| Green
  LB -->|95%| Blue
  Green --> Edge
  Edge -->|off| U1
  Edge -->|on| U2
```

Canary routing at the load balancer + per-user flag evaluation at the edge: two independent control planes.

## Key terms

- **Blue-green deployment**: Two identical environments; traffic flips 100% from old (blue) to new (green) atomically.
- **Canary deployment**: New build receives a small traffic slice (e.g. 5%) before gradual promotion to 100%.
- **Feature flag**: A runtime boolean (or multivariate value) that gates code paths without a redeploy.
- **Kill switch**: A feature flag set to off for all users instantly; stops an incident without rollback.
- **Flag debt**: Stale flags that remain in code after full rollout, adding dead branches and review cost.

## Related topics

- [CI/CD for Frontend](https://fearchitect.com/topics/ci-cd-frontend.md): Automated pipeline from commit to production with quality gates.
- [Edge Computing & Rendering](https://fearchitect.com/topics/edge-computing-rendering.md): Run code at CDN PoPs to cut latency before origin is hit.
- [A/B Testing & Experimentation](https://fearchitect.com/topics/ab-testing-experimentation.md): Ship variants without flicker using server-side bucketing and guardrail metrics.
- [Incremental Migration / Strangler Fig](https://fearchitect.com/topics/incremental-migration-strangler-fig.md): Replace a legacy frontend route-by-route behind a shared proxy.
- [Error Boundaries & Resilience](https://fearchitect.com/topics/error-boundaries-resilience.md): Isolate render failures so one widget can't crash the page.
- [CDN & Edge Caching](https://fearchitect.com/topics/cdn-edge-caching.md): Serve cached responses from PoPs near users, sparing the origin.

## Further reading

- [Martin Fowler — BlueGreenDeployment](https://martinfowler.com/bliki/BlueGreenDeployment.html)
- [Martin Fowler — CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html)
- [Martin Fowler — Feature Toggles](https://martinfowler.com/articles/feature-toggles.html)
- [Vercel — Feature flags with Edge Config](https://vercel.com/docs/edge-network/edge-config/edge-config-and-feature-flags)