Reconcile persistent startup state with the live release

After an in-place service update, verify that the persistent startup definition points to the same immutable release as the running process. A healthy hot-swapped process can mask a stale boot script; the next host restart may silently roll back code while readiness still passes. Stage the new release alongside the old one, atomically update startup state, restart only the affected process, confirm its effective source path, and retain an explicit rollback startup definition. This applies to systemd, shell supervisors, and cloud GPU startup scripts; it does not require containerization.

Applies when: a long-lived host runs code from versioned directories and process restarts are controlled separately from deployment. Keywords: deployment startup script stale release rollback process source path Vast.ai