Releases and rollbacks

Every deploy makes a numbered release: an image plus the config it started with.

berth releases myapp

  REL  SHA      STATUS   TRIGGER  WHEN     MESSAGE
* v4   b3ab439  running  webhook  2m ago   Add pricing page
  v3   9f1c2de  stopped  config   1h ago   Fix login redirect
  v2   9f1c2de  failed   webhook  1h ago   health check / failed after 1m0s: HTTP 502
  v1   4e5a6b7  stopped  create   2d ago   First commit

Deploys have no downtime. The new release starts next to the old one, and Berth waits for it to answer on / (anything below a 500 counts) before moving traffic over. The old one gets 5 seconds to finish its requests, then stops. If the new release never gets healthy, the old one just keeps serving, and you get the new one's last 50 log lines so you can see why.

berth rollback myapp          # back to the previous good release, in about 2 seconds
berth rollback myapp 2        # back to v2
berth restart myapp           # fresh container, same release, no downtime
berth stop myapp              # the URL answers 503 until you start it
berth start myapp

A rollback brings back that release's code and its config, but not its data. If a migration changed the database, see rolling back data. Berth keeps images for the last 5 releases; older ones are cleaned up, and you can still redeploy them by commit with berth deploy myapp --ref <sha>.