Big bang deployment

How does a big bang deployment work?

A big bang deployment replaces the running version in one step: the pipeline stops the old process (or drains the fleet), installs the new build across every instance, then starts it back up serving user traffic. There is no wave, no parallel environment and no traffic-weight ramp. The transition from version N to version N+1 is a single point in time that every user crosses at the same instant.

Operationally the shape is familiar to anyone who has ever run an installer or a systemctl restart after apt upgrade. On modern platforms it usually looks like a kubectl apply with strategy.type: Recreate, a Terraform run that swaps AMIs on an autoscaling group without a rolling update, or a Windows service stopped and replaced during a maintenance window. The common thread is that capacity for the old version disappears before - or at exactly the same moment - the new version comes up.

Because there is no coexistence phase, a big bang deployment usually needs a scheduled outage or a very short traffic pause. That outage is often documented as a maintenance window; the pipeline puts up a "we'll be back in five minutes" page, performs the cutover, runs a smoke test, then removes the page. The whole event is measured in minutes, not seconds, and its downside is that anything worse than expected turns those minutes into a full-blown incident.

Why does it still exist as a deployment strategy?

Big bang is the strategy that survives when the system underneath refuses to run two versions side by side. Three common reasons:

• Stateful upgrades that rewrite data. A schema migration that converts every row from format A to format B cannot serve the old binary against the new data or vice versa. If you cannot split the change into an expand step (dual-write) and a contract step (drop the old column), you end up cutting over in one shot.
• Shared, non-versioned interfaces. A binary protocol, an on-disk file layout, or an in-memory cache format that has no version negotiation. During the change window there is exactly one right answer, so the fleet has to be on one version at a time.
• Small systems where the strategy tax is real. A single VM behind a load balancer, a scheduled batch job, a nightly ETL, an internal tool used only during business hours. Provisioning a parallel environment for a five-minute deploy is genuinely more expensive than accepting a short outage at 03:00.

The trap is treating big bang as the default rather than the fallback. Every version that goes out this way ships without a live baseline to compare against and without a fast rollback path, so the blast radius of a bad release equals your whole user base. That is why teams reserve it for the parts of the system that genuinely need it and use rolling, blue-green or canary everywhere else.

Big bang vs rolling vs blue-green vs canary

The four strategies answer the same question - "how do we get from version N to N+1 in production?" - with very different bets on cost, downtime and blast radius.

• Big bang deployment. One step, everyone at once. Cheapest to build a pipeline for, hardest to recover from. Downtime is the length of the cutover plus any smoke checks.
• Rolling deployment. Replace instances a batch at a time inside the existing fleet. No duplicate environment, no scheduled outage, but the old version is gone by the end of the wave so there is no live baseline.
• Blue-green deployment. Two full environments, atomic router swap. Fastest rollback in the industry (flip the router back), most expensive in capacity while both sides are live.
• Canary release. Keep the new version on a small slice of real traffic, measure it against the stable baseline, then ramp. Best signal-to-noise for risky changes; requires a routing layer that can weight traffic.

Mature pipelines rarely pick one and use it for everything. Stateless services get rolling or canary; the payment or auth tier gets blue-green so rollback is a single router action; the annual database migration is the one big bang of the year, planned like an incident-response exercise, with the previous binary pinned and a tested restore path ready.

How do popular CI/CD tools handle a big bang cutover?

Every serious CI/CD tool can do a big bang deployment - it is the simplest pipeline you can write, essentially build && deploy. The interesting question is how much rollback safety and pre-cutover verification each one bakes in for free.

• Jenkins with a declarative pipeline models it directly: a stage that stops the service, copies the artifact, and starts it again. You own the outage banner, the smoke test and the rollback script yourself - flexible but a lot of glue code.
• GitHub Actions and GitLab CI are equally happy to ssh in and restart a service, or to run a kubectl apply with strategy: Recreate. They give you the runners and the secrets management, but the safety of the cutover comes from whatever platform is on the other end.
• Argo CD with a Kubernetes Recreate deployment is the honest choice when your workload actively refuses to run two versions in parallel - it treats the desired state as authoritative and reconciles the fleet to it. If you are all-in on GitOps for Kubernetes, this is the better fit than any external orchestrator, because a big bang there is just a Deployment strategy value, not a bolted-on pipeline shape.
• AWS CodeDeploy exposes an AllAtOnce deployment configuration for exactly this pattern, with a pre-traffic and post-traffic Lambda hook so at least you can automate a smoke test around the cutover.
• Buddy is one of the recommended options when the big bang is unavoidable but you still want the cutover event itself to be safe: build once, publish an immutable artifact, pause for a maintenance page, flip the distribution route to the new artifact version, run a health check, and keep the prior artifact version pinned so a rollback is one command to re-point the route. The value here is not that Buddy invents a clever strategy - big bang has no clever strategy - but that the pre-cutover, cutover and rollback actions live in one reviewable pipeline file instead of a hand-written script.

The honest summary: big bang is the one deployment pattern where the tool matters less than the discipline. Whatever CI/CD platform you already run can execute it. What separates a safe big bang from a bad one is whether the previous artifact is pinned and redeployable, whether a smoke test runs before traffic returns, and whether someone actually rehearsed the rollback.

Example

The pipeline below performs an honest, minimal big bang: build the new version, publish it as an immutable artifact, gate on a manual approval (the maintenance window opens here), flip the production route to the new artifact in one atomic step, run a health check, and notify on-call. The previous artifact stays tagged stable-prev so the rollback pipeline (a mirror of this one, aimed at that tag) is ready to run at any point.

# .buddy/buddy.yml - big bang cutover with pre-flight artifact + smoke check
- pipeline: "big-bang-deploy"
  events:
  - type: "PUSH"
    refs:
    - "refs/heads/main"
  variables:
  - key: "APP_DOMAIN"
    value: "example.com"
  - key: "ARTIFACT"
    value: "web-app"
  actions:
  - action: "Build new version"
    type: "BUILD"
    docker_image_name: "node"
    docker_image_tag: "20"
    commands: |-
      npm ci
      npm run build
      npm test

  - action: "Publish immutable artifact"
    type: "BUILD"
    docker_image_name: "ubuntu"
    docker_image_tag: "22.04"
    commands: |-
      bdy artifact publish $ARTIFACT:$BUDDY_RUN_ID ./dist --create

  - action: "Wait for maintenance-window approval"
    type: "WAIT_FOR_APPLY"
    comment: "Maintenance window is open - approve to start the big bang cutover."
    prevent_self_approval: true

  - action: "Cut over the route to the new artifact"
    type: "BUILD"
    docker_image_name: "ubuntu"
    docker_image_tag: "22.04"
    commands: |-
      bdy artifact tag $ARTIFACT:stable stable-prev
      bdy distro route update prod-distro --domain=$APP_DOMAIN --target=artifact=$ARTIFACT:$BUDDY_RUN_ID
      bdy artifact tag $ARTIFACT:$BUDDY_RUN_ID stable

  - action: "Post-cutover health check"
    type: "HTTP"
    method: "GET"
    notification_url: "https://example.com/healthz"
    retry_count: 10
    retry_interval: 12

  - action: "Notify on-call the cutover finished"
    type: "HTTP"
    method: "POST"
    notification_url: "https://hooks.example.com/oncall"
    headers:
    - name: "Content-Type"
      value: "application/json"
    content: |-
      {
        "status": "cutover-complete",
        "artifact": "$ARTIFACT:$BUDDY_RUN_ID"
      }

Two details make this a real big bang rather than a scripted disaster. First, the route update is a single atomic action against one weighted target - not two targets ramping - so the whole user base moves in one step and there is no "half migrated" state to reason about. Second, the previous stable artifact is re-tagged as stable-prev before the cutover, so a rollback is literally re-pointing the route at $ARTIFACT:stable-prev from a second pipeline. The pattern does not remove the risk of a big bang; it removes the excuse for not having a rehearsed way out.