Blue-Green Deployments

A deployment goes wrong at 2am. Your rollback is one SQL statement: UPDATE nodes SET active_color = 'blue'. Traffic switches within the next sync interval — no YAML edits, no helm rollback, no kubectl involved.

The active_color column in your database determines which environment is live. Lynq keeps both deployments running; the Service selector follows the column value.

Time to working

~5 minutes to configure. Traffic switches within 1 minute of a column update.

How It Works

Each node has two Deployments (blue and green) always running — the active one at full replicas, the inactive one at 1.

The Service selector is a template expression: color: "{{ .activeColor }}". When the column changes, Lynq updates the selector and traffic shifts.

Rollback is the same operation as a deploy: update active_color and the Service re-points to the previous environment.

Database Schema

sql

CREATE TABLE nodes (
  node_id    VARCHAR(63)  PRIMARY KEY,
  is_active  BOOLEAN      DEFAULT TRUE,

  -- Blue-green control
  active_color       VARCHAR(10)  DEFAULT 'blue',  -- 'blue' | 'green'
  blue_version       VARCHAR(20)  DEFAULT 'v1.0.0',
  green_version      VARCHAR(20)  DEFAULT 'v1.0.0',
  deployment_status  VARCHAR(20)  DEFAULT 'stable' -- stable | deploying | testing | rolled-back
);

Minimal Setup

The core of the pattern: two Deployments whose replica count follows the active color, and a Service whose selector does the same.

yaml

apiVersion: operator.lynq.sh/v1
kind: LynqHub
metadata:
  name: blue-green-nodes
  namespace: lynq-system
spec:
  source:
    type: mysql
    syncInterval: 1m
    mysql:
      host: mysql.internal.svc.cluster.local
      port: 3306
      database: nodes_db
      table: nodes
      username: lynq_reader
      passwordRef:
        name: mysql-credentials
        key: password
  valueMappings:
    uid: node_id
    activate: is_active
  extraValueMappings:
    activeColor: active_color
    blueVersion: blue_version
    greenVersion: green_version

yaml

apiVersion: operator.lynq.sh/v1
kind: LynqForm
metadata:
  name: blue-green-app
  namespace: lynq-system
spec:
  hubId: blue-green-nodes

  deployments:
    - id: blue
      nameTemplate: "{{ .uid }}-blue"
      spec:
        apiVersion: apps/v1
        kind: Deployment
        spec:
          replicas: {{ ternary 3 1 (eq .activeColor "blue") | int }}
          selector:
            matchLabels:
              app: "{{ .uid }}"
              color: blue
          template:
            metadata:
              labels:
                app: "{{ .uid }}"
                color: blue
            spec:
              containers:
                - name: app
                  image: "registry.example.com/app:{{ .blueVersion }}"
                  ports:
                    - containerPort: 8080

    - id: green
      nameTemplate: "{{ .uid }}-green"
      spec:
        apiVersion: apps/v1
        kind: Deployment
        spec:
          replicas: {{ ternary 3 1 (eq .activeColor "green") | int }}
          selector:
            matchLabels:
              app: "{{ .uid }}"
              color: green
          template:
            metadata:
              labels:
                app: "{{ .uid }}"
                color: green
            spec:
              containers:
                - name: app
                  image: "registry.example.com/app:{{ .greenVersion }}"
                  ports:
                    - containerPort: 8080

  services:
    - id: main
      nameTemplate: "{{ .uid }}-app"
      dependIds: ["blue", "green"]
      spec:
        apiVersion: v1
        kind: Service
        spec:
          selector:
            app: "{{ .uid }}"
            color: "{{ .activeColor }}"
          ports:
            - port: 80
              targetPort: 8080

Full Example

Add per-color test Services and Ingresses for smoke-testing before switching traffic.

yaml

apiVersion: operator.lynq.sh/v1
kind: LynqForm
metadata:
  name: blue-green-app
  namespace: lynq-system
spec:
  hubId: blue-green-nodes

  deployments:
    - id: blue
      nameTemplate: "{{ .uid }}-blue"
      labelsTemplate:
        app: "{{ .uid }}"
        color: blue
        active: "{{ ternary \"true\" \"false\" (eq .activeColor \"blue\") }}"
      spec:
        apiVersion: apps/v1
        kind: Deployment
        metadata:
          labels:
            app: "{{ .uid }}"
            color: blue
        spec:
          replicas: {{ ternary 3 1 (eq .activeColor "blue") | int }}
          selector:
            matchLabels:
              app: "{{ .uid }}"
              color: blue
          template:
            metadata:
              labels:
                app: "{{ .uid }}"
                color: blue
                version: "{{ .blueVersion }}"
            spec:
              containers:
                - name: app
                  image: "registry.example.com/app:{{ .blueVersion }}"
                  env:
                    - name: NODE_ID
                      value: "{{ .uid }}"
                    - name: ENVIRONMENT_COLOR
                      value: blue
                  ports:
                    - containerPort: 8080
                  resources:
                    requests:
                      cpu: 500m
                      memory: 1Gi

    - id: green
      nameTemplate: "{{ .uid }}-green"
      labelsTemplate:
        app: "{{ .uid }}"
        color: green
        active: "{{ ternary \"true\" \"false\" (eq .activeColor \"green\") }}"
      spec:
        apiVersion: apps/v1
        kind: Deployment
        metadata:
          labels:
            app: "{{ .uid }}"
            color: green
        spec:
          replicas: {{ ternary 3 1 (eq .activeColor "green") | int }}
          selector:
            matchLabels:
              app: "{{ .uid }}"
              color: green
          template:
            metadata:
              labels:
                app: "{{ .uid }}"
                color: green
                version: "{{ .greenVersion }}"
            spec:
              containers:
                - name: app
                  image: "registry.example.com/app:{{ .greenVersion }}"
                  env:
                    - name: NODE_ID
                      value: "{{ .uid }}"
                    - name: ENVIRONMENT_COLOR
                      value: green
                  ports:
                    - containerPort: 8080
                  resources:
                    requests:
                      cpu: 500m
                      memory: 1Gi

  services:
    - id: main
      nameTemplate: "{{ .uid }}-app"
      dependIds: ["blue", "green"]
      spec:
        apiVersion: v1
        kind: Service
        spec:
          selector:
            app: "{{ .uid }}"
            color: "{{ .activeColor }}"
          ports:
            - port: 80
              targetPort: 8080

    - id: blue-test
      nameTemplate: "{{ .uid }}-blue-test"
      spec:
        apiVersion: v1
        kind: Service
        spec:
          selector:
            app: "{{ .uid }}"
            color: blue
          ports:
            - port: 80
              targetPort: 8080

    - id: green-test
      nameTemplate: "{{ .uid }}-green-test"
      spec:
        apiVersion: v1
        kind: Service
        spec:
          selector:
            app: "{{ .uid }}"
            color: green
          ports:
            - port: 80
              targetPort: 8080

  ingresses:
    - id: main
      nameTemplate: "{{ .uid }}-ingress"
      dependIds: ["main"]
      spec:
        apiVersion: networking.k8s.io/v1
        kind: Ingress
        spec:
          ingressClassName: nginx
          rules:
            - host: "{{ .uid }}.example.com"
              http:
                paths:
                  - path: /
                    pathType: Prefix
                    backend:
                      service:
                        name: "{{ .uid }}-app"
                        port:
                          number: 80

    - id: blue-test-ingress
      nameTemplate: "{{ .uid }}-blue-test"
      dependIds: ["blue-test"]
      spec:
        apiVersion: networking.k8s.io/v1
        kind: Ingress
        spec:
          ingressClassName: nginx
          rules:
            - host: "{{ .uid }}-blue.test.example.com"
              http:
                paths:
                  - path: /
                    pathType: Prefix
                    backend:
                      service:
                        name: "{{ .uid }}-blue-test"
                        port:
                          number: 80

    - id: green-test-ingress
      nameTemplate: "{{ .uid }}-green-test"
      dependIds: ["green-test"]
      spec:
        apiVersion: networking.k8s.io/v1
        kind: Ingress
        spec:
          ingressClassName: nginx
          rules:
            - host: "{{ .uid }}-green.test.example.com"
              http:
                paths:
                  - path: /
                    pathType: Prefix
                    backend:
                      service:
                        name: "{{ .uid }}-green-test"
                        port:
                          number: 80

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192

Deployment Workflow

1. Stage the new version on the inactive environment

sql

-- Blue is active. Deploy v2.0.0 to green without affecting production.
UPDATE nodes
SET green_version = 'v2.0.0',
    deployment_status = 'deploying'
WHERE node_id = 'acme-corp';

Lynq updates the green Deployment image. The blue Service selector is unchanged — production traffic is unaffected.

2. Test against the inactive environment

bash

# Green is accessible via its dedicated test Service/Ingress
curl https://acme-corp-green.test.example.com/healthz
# {"status":"healthy","version":"v2.0.0"}

3. Switch traffic

sql

UPDATE nodes
SET active_color = 'green',
    deployment_status = 'stable'
WHERE node_id = 'acme-corp';

Lynq updates the Service selector. Green scales to 3 replicas; blue scales to 1.

4. Roll back

sql

UPDATE nodes
SET active_color = 'blue',
    deployment_status = 'rolled-back'
WHERE node_id = 'acme-corp';

Deployment timeline

Time	Action	Traffic
T+0	`green_version = 'v2.0.0'`	Blue (v1.0.0)
T+1m	Lynq updates green Deployment	Blue (v1.0.0)
T+5m	Green pods ready, smoke tests	Blue (v1.0.0)
T+15m	`active_color = 'green'`	Green (v2.0.0)
T+20m	Issue detected	Green (v2.0.0)
T+21m	`active_color = 'blue'`	Blue (v1.0.0)
T+22m	Traffic restored	Blue (v1.0.0)

Total rollback time: ~1–2 minutes.

Verify It Works

bash

# Service selector follows active_color
kubectl get svc acme-corp-app -o jsonpath='{.spec.selector.color}'
# blue

# After switching active_color to green:
kubectl get svc acme-corp-app -o jsonpath='{.spec.selector.color}'
# green

# Replica counts reflect active/inactive
kubectl get deployment -l app=acme-corp
# NAME              READY   REPLICAS
# acme-corp-blue    1/1     1        ← inactive (scaled down)
# acme-corp-green   3/3     3        ← active (scaled up)

Caveats

Schema changes must be backward compatible during the transition window — both colors run simultaneously and share the same database.
Stateful applications (session affinity, in-flight requests) need additional handling; the Service selector switch is instant but in-flight connections to the old pods drain naturally.
Double resource usage during deployments. The inactive environment runs at 1 replica to minimize cost, not 0 — scaling to 0 would add pod start latency to the deploy.

Blue-Green Deployments ​

How It Works ​

Database Schema ​

Minimal Setup ​

Full Example ​

Deployment Workflow ​

1. Stage the new version on the inactive environment ​

2. Test against the inactive environment ​

3. Switch traffic ​

4. Roll back ​

Deployment timeline ​

Verify It Works ​

Caveats ​

See Also ​

Blue-Green Deployments

How It Works

Database Schema

Minimal Setup

Full Example

Deployment Workflow

1. Stage the new version on the inactive environment

2. Test against the inactive environment

3. Switch traffic

4. Roll back

Deployment timeline

Verify It Works

Caveats

See Also