Health-checked deployments

What you get

• Each new version started beside the running one
• Traffic switched only after a health check passes
• No downtime during a deploy
• A database restore point before each migration
• A failed deploy leaves the live version running
• Rollback from the dashboard or the CLI
• A notification when a deploy fails

How it works

Each deploy is built with BuildKit and started in a new container while the current version keeps serving. Whisk calls the app's health route until it answers 200. Only then does Caddy, the open-source web server in front of every app, send traffic to the new version.

The old version gets time to finish the requests it is handling before it stops. If the build, a migration or the health check fails, the live version keeps running unchanged. The error names the cause, includes the app's last log lines and says whether the fault was in the app or on Whisk's side.

When whisk.yaml has a migrate command, Whisk takes a database restore point first, and a failed migration puts the database back to it. Any earlier deploy can be made live again from the deploys page or with whisk rollback, without rebuilding.

Example

A building supplier deploys a change to its trade account app in the middle of a working day. The new version fails its health check because a library fails to start, so counter staff keep using the previous version without noticing. The developer reads the log lines in the error, fixes the dependency and deploys again.

For your coding agent

health: { path: /health, timeout: 60 }
migrate: "node dist/migrate.js"

whisk rollback puts the previous deploy back, and whisk deploys list shows the earlier ones. The health check and shutdown rules are in the app rules, and a change can be tried first in a preview.