# Restore a previous deployment What's new in Tray Helix · 28 September 2026 · https://helix.tray.ai/whats-new/restore-a-previous-deployment/ Tray Helix can restore a previous deployment. In the project's Deployments tab, choose Restore this version on the deployment you want, and Helix rebuilds that deployment's stored source through the normal build pipeline and ships it as a new deployment. It takes as long as any deploy, never takes the app offline, and brings back code, not data. **Available in:** Helix Enterprise Edition, as part of Deployment Management. Restore puts an earlier deployment of a project back live. You pick it in the Deployments tab, and Helix rebuilds that deployment's stored source through the normal build pipeline and ships the result as a new deployment. Nothing is switched back to an old build, and the app doesn't go offline while it happens. ## An example A project's 17 September deploy, `7483f01c`, is live and has a bug. The last deployment that worked is `6c0282ce`, from 4 September. Here is what going back to it looks like. ### 1. Choose the deployment to go back to Every row in the Deployments tab has a menu. Choose **Restore this version** on the deployment you want. Each row also shows how long it can still be restored. [![The Deployments tab with a row's menu open, showing Restore this version, View build output and Download source.](https://helix.tray.ai/screenshots/whats-new/restore-step-1-menu.webp)](https://helix.tray.ai/screenshots/whats-new/restore-step-1-menu.webp) ### 2. Check what changes besides the code The dialog sets the live deployment beside the one you're restoring. As well as the version, it compares the Helix SDK, authentications and schedules recorded for each, because two deployments can differ in more than code. It also reminds you that your local source won't change, with a link to download the restored version's source. You confirm that the restore replaces the live build before it starts. The Restore dialog comparing the live deployment 7483f01c with 6c0282ce, with a confirmation checkbox. ### 3. The live version keeps serving The restore is a new deployment, `34c4329f`, and it builds like one, so it takes minutes. While it builds, its row shows that `7483f01c` is still serving. If the build fails, it stays that way: the app keeps running the version that was live when you started. [![The Deployments tab during a restore: the new deployment is Restoring, and 7483f01c is still serving.](https://helix.tray.ai/screenshots/whats-new/restore-step-3-restoring.webp)](https://helix.tray.ai/screenshots/whats-new/restore-step-3-restoring.webp) ### 4. The restored version is live When the build succeeds, `34c4329f` goes live, marked as a restore of `6c0282ce`. The deployment you went back from is still in the list, so if the problem turns out to be somewhere else, you can restore that one too. [![The Deployments tab after the restore: 34c4329f is live, marked as a restore of 6c0282ce.](https://helix.tray.ai/screenshots/whats-new/restore-step-4-restored.webp)](https://helix.tray.ai/screenshots/whats-new/restore-step-4-restored.webp) ## What follows from it being a rebuild - **It takes minutes, not seconds**, because it is a real deploy. - **It isn't guaranteed to be byte-identical** to what ran before. Dependencies resolve fresh against the same lockfile. - **It can fail, and failing is safe.** The live version keeps serving. - **It needs the same access as deploying.** Going back is governed exactly like going forward. ## What it doesn't bring back **Your data.** The key-value store, and anything your app wrote to a connected service, stay as the newer version left them. Restoring the code stops a bad release writing more bad data. Cleaning up what it already wrote is a separate job. **Your working copy.** Your next `helix deploy` ships whatever is in your local project. If the bug is still there, that deploy ships it again. Fix it locally first, or download the restored deployment's source and carry on from that. ## How far back you can go Helix keeps the live deployment, the one just before it for as long as it holds that spot, and every other deployment for 30 days. Restore and source download are dashboard actions; there is no CLI command for either. ## Links - Docs: [Restore a previous deployment](https://helix.tray.ai/documentation/guides/deployment/#restore-a-previous-deployment) - Docs: [How long previous deployments are kept](https://helix.tray.ai/documentation/guides/deployment/#how-long-previous-deployments-are-kept) - Docs: [Identity and roles](https://helix.tray.ai/documentation/guides/identity-and-roles/) ## Questions ### How far back can I restore? Helix keeps the live deployment, the one just before it for as long as it holds that spot, and every other deployment for 30 days. Anything in that window can be restored, and each row in the Deployments tab says how long it has left. ### Does restoring bring back my data? No. Restore brings back code only. The key-value store, and anything your app wrote to a connected third-party service, stay as the newer version left them. ### Can I restore from the CLI? No. Restoring and downloading a deployment's source are dashboard actions, and there is no CLI command for either. ### Who can restore a deployment? Anyone who can deploy the project. Restoring needs the same access as deploying.