---
title: "Zero Downtime Deploys"
description: "Zero downtime deploys on Fly.io. New code only gets traffic once it passes a health check, and the old version keeps running if it fails."
---

# *Zero Downtime Deploys* on Fly.io

Deploying code shouldn't feel like defusing a bomb. Ship features during business hours without sweating through your shirt or sending "sorry for the downtime" emails. Your users won't even notice you deployed.

[Dive into the docs!](https://docs.fly.io/blueprints/seamless-deployments)

![Health Checks](https://fly.io/phx/ui/images/zdt_1-905783bb662b7fc05c47d2a69710eb3c.png?vsn=d)

## Health Checks: Don't Route Traffic to Broken Things

Here's the secret to zero downtime: we don't send users to your new code until it passes a health check. Configure an endpoint that says "yep, I'm good to go," and we'll ping it before routing traffic. If it fails, the old version keeps running. Some call it revolutionary.

- HTTP checks for web services (just return a 200)
- TCP checks for non-HTTP services
- Configurable intervals and timeouts

- Grace periods for slow startup
- Custom headers for auth or routing
- Smoke checks monitor for ~10s after boot

## Pick Your Deployment Strategy (Or Don't, We Have Defaults)

Different apps need different deploy strategies. Rolling updates work great for most things. Canary is perfect when you're nervous. Bluegreen is fast but needs more resources. Immediate is for "I know what I'm doing" emergencies. Choose based on your risk tolerance and coffee intake.

**Rolling (default):** Replace Machines one at a time. Safe, steady, works everywhere.

**Canary:** Boot one new Machine first. If it's healthy, proceed with rolling. Your guardrail.

**Bluegreen:** Boot all new Machines alongside old ones. Switch traffic when ready. Fast but uses 2x resources briefly.

**Immediate:** Replace everything now, no health checks. For emergencies or when you're feeling brave.

[Learn about different ways to deploy](https://docs.fly.io/model-context-protocol/deploy-with)

![Deployment Strategies](https://fly.io/phx/ui/images/zdt_2-f614048ff13229a6fe456d66979ff401.png?vsn=d)

## Release Commands: Run Migrations Before You Deploy

Database migrations, cache warming, asset precompilation, whatever needs to happen before your new code goes live. Define a `release_command` and we'll run it once before deploying. If it fails, the deploy stops. No "oops forgot to migrate" moments.

Runs once before deployment starts

Perfect for database migrations

Fails the deploy if the command fails

Configure in fly.toml with one line

## Read the Docs

- [Seamless Deployments Guide](https://docs.fly.io/blueprints/seamless-deployments): The complete guide to zero downtime deploys on Fly.io

- [Deploy Configuration](https://docs.fly.io/reference/configuration#the-deploy-section): Configure deployment strategies in fly.toml

- [Health Checks](https://docs.fly.io/reference/configuration#the-http_service-section): Set up HTTP and TCP health checks for your services

- [Release Commands](https://docs.fly.io/reference/configuration#run-one-off-commands-before-releasing-a-deployment): Run migrations and setup tasks before deployment

## Deploy Whenever You Want

![Deploy Anytime](https://fly.io/phx/ui/images/zdt_3-c92bfdf87b718baac3ddc8eb0d3798e3.png?vsn=d)

Remember when "deploy Friday" was a career-limiting move? With zero downtime deploys, you can ship code when it's ready. Health checks, rolling updates, and automatic rollbacks mean you can push at 3pm on a Friday and still sleep well. Live dangerously (but safely).

[Get Started](https://fly.io/app/sign-up)