Zero-downtime deploys on cloud hosting

Downtime during a deploy is rarely dramatic — it’s a few minutes of 502s, a stuck checkout, and a support queue that spikes. For commerce and lead-gen sites, those minutes are expensive. Shoppers do not distinguish between “we were deploying” and “the site is unreliable.” They just leave.

Here’s the release pattern we use on Build Me Web cloud hosting so storefronts stay online while new versions roll out. The ideas are familiar — blue-green, health checks, expand/contract migrations, fast rollback — but the value is in making them default, documented, and boring enough that every release uses them, not only the scary ones.

Blue-green in plain language

We keep the current “blue” version serving traffic while we bring up “green” with the new build. Health checks must pass before the load balancer shifts traffic. If anything fails, green is drained and blue never blinked.

Blue-green is not the only zero-downtime strategy, but it is the clearest mental model for most marketing and commerce sites we host. Canary releases (shifting a percentage of traffic) are available when risk warrants finer control — for example, a checkout rewrite — but the baseline remains: never take blue down to bring green up.

Artifact immutability matters. Green is a known build from CI, the same bits that passed preview checks, not a snowflake assembled on the server. That traceability is what makes rollback a traffic shift instead of an archaeological dig.

DNS and CDN layers need to cooperate. We warm caches for critical assets on green, confirm TLS and redirect rules, and only then flip. A perfect app health check still fails users if the edge is pointing at the wrong origin or serving a stale error page.

Health checks that mean something

Shallow checks create false confidence. We define a health surface that matches how money and leads actually move through the site.

• HTTP readiness on critical routes (home, cart, auth)
• Dependency checks for database and cache connectivity
• Warm caches and critical assets before cutover

A 200 on / isn’t enough if checkout still 500s. We define the health surface with the client during discovery. For commerce, that usually includes cart add, checkout boot, and payment provider sandbox reachability. For lead-gen, form submit endpoints and CRM connectivity. For content sites, preview of a representative CMS-driven template and search if it is customer-facing.

Dependency checks catch the classic failure where the new app boots but cannot reach the database because a connection limit or secret rotation went wrong. Cache connectivity matters when sessions or inventory counters live in Redis-like stores — a “healthy” app that cannot read session state will look like random logouts after cutover.

Warming is underrated. Cold caches after a flip can look like a performance incident even when the deploy is fine. We pre-hit critical URLs and assets so the first real customers are not the cache warmers.

Database and migrations

Schema changes ship expand/contract style: additive first, dual-write if needed, then remove old columns after the app no longer reads them. That keeps blue and green compatible during the flip.

Destructive migrations in the same release as the code that requires them are how you get undiagnosable outages. If green needs a new column, add it while blue is still live and ignores it. Deploy green. Only later remove the old column when no version still reads it. Dual-write periods exist for renames and splits that cannot be atomic.

Long-running data backfills do not belong in the cutover window. They run as separate jobs with progress monitoring, or they happen before the release that depends on them. We call this out in release plans so stakeholders do not confuse “migration finished” with “backfill finished.”

For content and commerce platforms with their own migration tooling, we still apply the same compatibility rule: blue and green must be able to coexist for the duration of the flip and the rollback window.

Rollback without heroics

Every release keeps the previous artifact warm for a short window. Rollback is a traffic shift, not a rebuild. We document who can trigger it and how customers are notified if a partial incident occurred.

Heroic rollbacks fail because they require tribal knowledge at 1 a.m. We keep a short runbook per project: dashboard links, health check URLs, who is on point, and the exact command or console action to shift traffic. Practice matters — launch rehearsals on preview and staging include a deliberate rollback drill so the motion is familiar.

Not every defect needs a full rollback. Feature flags can disable a risky path while blue remains green’s sibling. But flags are not a substitute for artifact rollback when the defect is in shared infrastructure or data access. Knowing which lever to pull is part of the runbook.

Communication plans are part of zero downtime too. If checkout errors affected a slice of customers before rollback, support needs a factual note — what happened, what to tell shoppers, whether orders need reconciliation. Silence creates rumors; clear notes create trust.

Observability around the flip

Zero-downtime deploys still need watching. During the cutover window we watch error rates, saturation, payment or form success ratios, and Core Web Vitals lab snapshots against the new build. A quiet error budget burn that starts at flip time is a deploy problem until proven otherwise.

We keep the window staffed. Calendar the deploy, name the owner, and avoid stacking unrelated production changes in the same hour. Preview URLs and the green environment give stakeholders a final look before traffic moves, which reduces “wait, can we also…” surprises mid-flip.

What clients see

Cloud and Managed engagements include this deploy path by default. You’ll get preview URLs before cutover, a deploy window on the calendar, and a short post-release note with vitals and error rates. Launch projects establish the pattern early so the first production cutover is not an experiment.

If you are migrating from a host that still uses maintenance windows, bring your current release pain to discovery: how long deploys take, what breaks, who gets paged. We will map blue-green (or canary) onto your stack and write the health surface into the engagement so “zero downtime” is a tested property, not a slide.

For stores with peak calendars — product drops, seasonal campaigns, conference launches — we schedule non-essential deploys outside those windows and keep the rollback artifact warm longer. Zero downtime is the mechanism; release discipline is how you avoid testing it under maximum traffic.

The best compliment for a deploy process is that nobody outside engineering noticed. Blue kept serving. Green proved healthy. Traffic moved. Rollback stayed ready and unused. That boredom is the point.