Release commands and health checks
Run migrations before each new version takes traffic, and decide when a new version is ready.
A release command runs once for each deploy, before the new version takes traffic. A health check path tells Appentic when the new version is ready. Both are in the web service's Settings, under Build & Deploy, and apply from the next deploy. For a Feather app you can also set them on the create form.
Release command
Use a release command for work that has to happen exactly once per version, such as database migrations:
feather db upgradeOther frameworks have their own, for example python manage.py migrate, npx prisma migrate deploy or bundle exec rails db:migrate.
The command runs in the new version, with the service's environment variables, so it reaches the same databases and key value stores as the app.
- If it succeeds, the deploy carries on and the new version starts.
- If it fails (exits with a non-zero code), the deploy fails. The version that was live keeps serving, untouched. The Events page shows the failure with the last line of output.
- If it runs for more than 15 minutes, it's stopped and the deploy fails.
Its output is added to the deploy's build log, under a --- release: line.
For a Feather app with feather db upgrade, Appentic skips the command when the migrations and the database haven't changed since the last release. The Events page shows Release skipped.
Keep migrations compatible
Rollbacks and restarts don't run the release command. A rollback puts an earlier version back without undoing its migrations. Keep each migration compatible with the version before it. Add tables and columns first, and remove them in a later deploy.
The release command runs while the old version is still serving, so for a while the old version runs against the migrated database. That's another reason to keep migrations additive.
Health check path
Without a health check path, a new version takes traffic once it accepts connections on its port. With one, it takes traffic once that path answers with a success (any 2xx or 3xx status).
A path starts with / and has no spaces. For a Feather app, use /health/ready, which also checks the database. Many frameworks have a similar endpoint, or you can add one that returns 200 when the app can serve requests.
The check is sent with the service's own address as the host, so an app that only accepts known hosts still answers it.
| While | How often | What happens if it fails |
|---|---|---|
| A new version starts | Every 2 seconds, with a 5 second timeout | If it doesn't pass within 5 minutes, the deploy fails and the previous version keeps serving. |
| The service runs | Every 15 seconds, with a 5 second timeout | After 3 failures in a row, the service stops getting traffic until it answers again. Visitors see the back-soon page if it's on. |
A failing health check doesn't restart the service. Appentic restarts it only when it stops accepting connections on its port. If it then keeps stopping, its status becomes Crashing. See When the app keeps stopping.
Keep the endpoint cheap and exempt from rate limits. It's called about 240 times an hour.