Health Checks and Rollback¶
A Flask application with a togglable health endpoint. Use it to see what actually happens when a deploy goes bad — and how to put the previous version back.
There is no automatic rollback
AppMecca does not watch an app after a successful deploy and revert it on its own.
Despite this app's name, there is no auto_rollback: setting — the block this sample
used to carry was removed from its appmecca.yaml (BUGS #689) precisely because it did
nothing. The platform parsed the file, ignored that key, and nothing monitored for
failures afterwards.
This is worth internalising generally: any key AppMecca does not recognise is silently ignored. There is no error and no warning. A typo in a key name means the setting you thought you wrote simply does not exist.
What the platform does guarantee is stronger than it sounds, and it is covered below: a bad deploy never takes your running app down in the first place, and rolling back is one command.
Overview¶
| Repository | git@gitlab.com:appmecca-sample-apps/auto-rollback-demo.git |
| Tech Stack | Python / Flask |
| Services | web (container) |
| Demonstrates | Health-check tuning, blue/green safety, manual rollback |
What actually protects you¶
1. A failing deploy never replaces a working one¶
AppMecca deploys blue/green. The incoming container starts alongside the one currently serving, on a temporary port, and has to pass its health check before the load balancer is switched over to it. If it never becomes healthy:
- the switch never happens
- the old container keeps serving traffic, untouched
- the deploy is marked failed
A broken build is therefore a failed deploy, not an outage. This is automatic and needs no configuration.
2. Rolling back is a deploy of an older image¶
There is no rollback command, because a rollback is just a deploy of a tag you already
built. Find the tag, then redeploy it:
--no-build is the important half: it reuses an image that already exists in your private
image registry, so the rollback cannot be broken by whatever broke the build, and it goes
straight to the deploy.
appmecca.yaml¶
app_name: Auto Rollback Demo
containers:
- name: auto-rollback-demo
dockerfile: Dockerfile
context: .
deploy:
- name: web
primary: true
container: auto-rollback-demo
port: 5000
health_check:
path: /health
interval: 10
timeout: 3
healthy_threshold: 2
unhealthy_threshold: 3
The health check is what decides whether a deploy is allowed to take over. A shorter
interval makes a bad deploy fail faster; healthy_threshold: 2 means two consecutive
passes before the container is trusted with traffic.
2 is the floor, not 1
healthy_threshold and unhealthy_threshold both have a minimum of 2. Setting either
to 1 is rejected at validation time — you cannot make a deploy trust a single passing
probe.
See Health Checks for the full field reference.
API endpoints¶
| Method | Path | Description |
|---|---|---|
| GET | /health |
Health check (200 or 503) |
| POST | /toggle-health |
Toggle between healthy and unhealthy |
| POST | /fail |
Set health to unhealthy |
Try it¶
1. Register and deploy¶
2. Confirm it is healthy¶
3. Make the next deploy fail, and watch the app stay up¶
Set the app unhealthy, then deploy again. The new container will never pass its health check, so the deploy fails and the version already running carries on serving:
Watch the deploy fail, then confirm the app is still answering:
That is the guarantee — a bad deploy cannot break what is already running.
4. Put a known-good version back¶
What's Next¶
- Rolling Back — the rollback workflow in full
- Health Checks — every health-check field
- Hello Flask — the simplest Flask deployment