Deployment Strategies

Drift supports multiple deployment strategies to safely roll out updates to your applications.

Rolling Deployment (Default)#

The default strategy. Drift updates instances one at a time using a start-first approach — a new instance is started and health-checked before the old one is removed. This ensures zero downtime for multi-instance apps.

# Rolling update (default behavior)
drift push myapp --docker-image myregistry/myapp:v2

Canary Deployment#

Canary deployments roll out your new version to a single instance first. Drift validates the health of the canary before proceeding to update the remaining instances. If the canary fails, the deployment is automatically rolled back.

# Canary deployment — deploys 1 instance first, then rolls out
drift push myapp --docker-image myregistry/myapp:v2 --strategy canary

How canary works

  1. Drift deploys 1 instance with the new image
  2. Health checks run against the canary instance
  3. If healthy → remaining instances are updated (rolling)
  4. If unhealthy → automatic rollback, no traffic served from bad version

Monitoring Deployments#

# Check deployment status
drift deployment myapp

# Example output:
# App:        myapp
# Strategy:   canary
# Status:     in-progress
# Current:    myregistry/myapp:v1 (2 instances)
# Target:     myregistry/myapp:v2 (canary: 1/3 healthy)

Rollback#

If something goes wrong, roll back to the previous version immediately:

drift rollback myapp
# Rolled back myapp to previous version (myregistry/myapp:v1)

Automatic rollback

When using canary or rolling deployments with health checks configured, Drift automatically rolls back if the new instances fail their health checks. Manual rollback is a safety net for issues that health checks don't catch (e.g., business logic bugs).

Health Checks#

Health checks are essential for safe deployments. Drift supports three types:

TypeHow It WorksBest For
portChecks that the app port is accepting connectionsSimple services, workers
httpSends GET to a specified endpoint, expects 200Web apps, APIs
processChecks that the main process is runningBackground workers, cron jobs
# Set HTTP health check
drift set-health myapp --type http --endpoint /healthz

# Set port health check (default)
drift set-health myapp --type port

# Set process health check
drift set-health myapp --type process

Recommended setup

For production apps, always use HTTP health checks with a dedicated /healthz endpoint. This catches not just process crashes but also stuck threads, database connection issues, and other application-level problems.

Best Practices#

  • Always configure HTTP health checks before enabling canary deployments
  • Use at least 2 instances in production for zero-downtime rolling updates
  • Use canary for major version bumps or risky changes
  • Monitor drift logs myapp -f during deployments
  • Use drift deployment myapp to track progress
← PreviousFramework GuidesNext →API Reference