Operations

Zero-Downtime Deployment Prompt

Ship without a maintenance window — a deployment strategy (blue-green or rolling) that keeps the service up, handles in-flight requests, and stays compatible across versions.

Open in Markdown Output Builder

Overview

A deploy that needs downtime is a deploy you'll postpone — and postponed deploys get big and risky. This prompt designs a zero-downtime strategy: blue-green or rolling, how traffic shifts, how in-flight requests and connections drain, and the backward-compatibility rules (API, schema, sessions) that let two versions run side by side during the switch.

How to use this resource

Describe the deploy and its versions

Note what is shipping, how traffic reaches it, and what must stay compatible - API, schema, sessions - so two versions can run side by side.
Open this resource in Markdown Output Builder

Load the prompt into Markdown Output Builder and fill in the deploy. It returns the zero-downtime strategy as a clean Markdown plan you can follow during the switch.
Walk through the cutover strategy

Read the blue-green or rolling approach, how traffic shifts, how in-flight requests drain, and the backward-compatibility rules that keep both versions working.
Fill the gaps before you cut over

Resolve any compatibility break the plan flags between versions, then run the switch keeping the service up the whole time.

Why This Works

Choosing the pattern on real constraints beats cargo-culting blue-green
Compatibility rules are what make two-version coexistence safe, not luck
Connection draining is the detail that separates zero-downtime from dropped requests

Best for

Services where downtime is unacceptable or expensive
Frequent deploys that can't each take a window
Stateful services that complicate naive deploys

Not for

Internal tools where a brief window is fine
The data-migration specifics — use the Database Migration Plan Prompt

Use cases

Designing a blue-green or rolling deploy
Eliminating the maintenance window from releases
Handling in-flight requests during a version switch

FAQ

Does this prompt actually deploy my service or just plan the cutover?

It plans only. Markdown Output Builder returns the strategy as a clean Markdown document covering the chosen PATTERN, the TRAFFIC SHIFT, and the VERSION COMPATIBILITY rules, but nothing here touches your load balancer or ships anything. You run the actual switch yourself, following the plan, and own every cutover decision it describes.

How does the prompt decide between blue-green and rolling for my service?

The PATTERN section chooses on the constraints you supply in the INPUT block: architecture, traffic, statefulness, and current deploy method. It states the trade-off rather than defaulting to blue-green, and the STATEFUL CONCERNS section handles anything stateful — sessions, sticky connections, in-memory data — and how it survives the switch, so the choice isn't made blind to your setup.

Why does the strategy keep insisting both versions run at the same time?

A stated RULE drives it: "Two versions WILL run at once," so every VERSION COMPATIBILITY rule (backward-compatible APIs, expand/contract schema, session/cache compatibility) must hold during the overlap window. The output is only a plan though. Confirm the compatibility breaks it flags are genuinely resolved before you cut over, since it can't verify your real code.

Customize This Resource

Opens this setup in Markdown Output Builder. Generate to get the full markdown prompt — then adjust the sections, table rules, and consistency level.

Open in Markdown Output Builder

Prompt Template

Copy it as-is, or use Open in Markdown Output Builder to load it pre-filled and customize it with your own context.

ROLE
You are designing a zero-downtime deployment strategy for a running service.

INPUT
The service and constraints:
[Architecture, traffic, statefulness, current deploy method]

PRODUCE A STRATEGY
1. PATTERN: blue-green vs rolling vs other — chosen on the service's constraints, with the trade-off.
2. TRAFFIC SHIFT: how requests move from old to new (load balancer, DNS, service mesh) and how fast.
3. IN-FLIGHT WORK: how active requests, connections, and background jobs drain without being dropped.
4. VERSION COMPATIBILITY: the rules that let old and new run simultaneously — backward-compatible APIs, schema (expand/contract), session/cache compatibility.
5. HEALTH GATING: the checks the new version must pass before it takes traffic, and the automatic abort if it doesn't.
6. STATEFUL CONCERNS: anything stateful (sessions, sticky connections, in-memory data) and how it survives the switch.

RULES
- Two versions WILL run at once — every compatibility rule must hold during that window.
- No request in flight may be dropped by the switch.

OUTPUT
The chosen pattern with rationale, the traffic-shift and draining plan, and the version-compatibility rules.

More resources from Markdown Output Builder

Resource

Markdown Output Prompt — Lock the Document Structure

The contract that stops AI documents from restructuring themselves: a pinned section skeleton, forced tables, and strict consistency rules.

Prompt Engineering

Resource

README Prompt Template

Overview, Installation, Usage, Examples, Configuration — the README skeleton with required, runnable code examples.

Engineering

Resource

API Documentation Prompt

Overview, Authentication, Endpoints, Error Handling, Rate Limits — endpoint docs in an identical structure, with parameter tables and runnable examples forced.

Engineering

Resources that pair well

Resource

Executive Summary Prompt

Summary, Why It Matters, What Happens Next — the executive summary contract for readers who will never open the source.

Operations

Resource

Force JSON Output from AI

Stop getting 'Sure, here is the JSON…' — the output-contract pattern that forces models to return only parseable JSON: schema, example, and a strict rule block.

Prompt Engineering

Resource

Fix Invalid JSON from AI

The JSON won't parse and you can't see why. Deterministic cause-sniffing — trailing commas, single quotes, unclosed brackets — and the repair prompt that fixes it.

Engineering

Related tools

Tool

Markdown Output Builder

Build prompts that produce documents in a fixed structure — headings, sections, and tables.

Structured Output

Guides for this resource

Guide

How to Plan a Database Migration With AI Safely

The ALTER is one line. The migration is everything around it — because for a while, two versions of your code share one database. Here's how to turn a schema change on a live table into phases that stand alone, a backfill that can resume, and one step you can never take back.

Software Development with AI

Guide

How to Plan a Zero-Downtime Deployment With AI

"We do rolling deploys, so we have zero downtime" is true about the mechanism and often false about the change. Here is how to plan a zero-downtime deployment with AI: work out whether the old and new versions can actually run at once, across the database, the queue, and the traffic switch, before you ship.

Software Development with AI

Tip: Save time by exploring related resources and tools that integrate with this resource.