Check migrations between the current and rollback revisions before choosing the target.
Anything added in that range stays in the database after the rollback.
Deployment & release
¶ Rollback Guide
Every build pushes both :<git-sha> and :latest. To roll back, repoint the component image tag to a known-good SHA in the App Platform dashboard and redeploy.
Every commit is addressable by SHA
App Platform dashboard
Migrations never roll back
How it works
¶ Point the component back at an image it already ran
Because each build keeps its own :<git-sha> tag, any previously deployed commit is still in the registry. Rolling back swaps which image the component runs; nothing is rebuilt.
Repoint the component to
:<sha-1> and redeployRollback steps
¶ Check migrations first, then repoint
Repoint the component image tag to a known-good SHA in the App Platform dashboard.
Earlier releases and their image digests are recorded in the Shipped Log.
Redeploy.
Then confirm the deployment reaches ACTIVE and /healthz responds, as in the release checklist.
Cautions
¶ A rollback does not roll back migrations
The image goes back in time. The database does not.
schema v1schema v2schema v3
no path back
Forward onlyThe pre-deploy job only moves the database forward.
Old image, newer schemaOld images against newer additive schemas are often fine, but not guaranteed.
Choose the target carefullyCheck migrations between the current and rollback revisions before choosing the target.
Rolling back the connector restarts every WhatsApp session. The connector holds every socket, so any new image, including an older one, re-pairs every channel from the encrypted session blobs. See build-connector.