> ## Documentation Index > Fetch the complete documentation index at: https://docs.vertracloud.app/llms.txt > Use this file to discover all available pages before exploring further. # v26.4.2 — October 12, 2026 > Released October 12, 2026: code history, manual and automatic rollback in the Rollbacks tab, zero-downtime deploys on Enterprise, a safety snapshot when deleting an application on Pro and above, auto-deploys that build the pushed commit, and releases, rollback and deploy settings in the CLI, SDKs and MCP ### Zero-downtime deploys on Enterprise On Enterprise, a deploy or a restart can now start the new version next to the running one, check that it is healthy, and only then switch over, so an application that receives web traffic stays reachable while it is updated. The old version receives a shutdown request as soon as the new one has taken over. * **Modes:** `off` (the default, including for applications created before this update) keeps stopping the running version first; `auto` uses zero downtime for applications that receive web traffic; `on` forces it, including for applications without web traffic. Bots and other applications without web traffic stay on stop-and-start in `auto`, because two copies of a bot would answer the same event twice. Turn it on in the application's settings, under **Deploy**; it applies from the next restart or deploy. * **Health check path:** set the path the platform calls on the new version, `/` by default, with the new `deploy.health_check_path` field of [Update Application Configuration](/api-reference/endpoint/apps/updateconfig) or in the application's settings. Any HTTP response counts as healthy, including `404`; a refused connection, a timeout or a `5xx` response does not. * **Discarded deploys:** if the new version does not become healthy within about 2 minutes, it is discarded, you get a notice with its log, and the previous version keeps running. The live log shows the same notice. * **Fallback:** if the second copy can't be started at that moment, the deploy falls back to stopping the running version first. Both versions share the application's folder for a short time, so read the [limitations](/guides/rollback-and-zero-downtime-deploys#known-limitations) before turning it on for an application that writes data files or reads its files on every request. The new [rollback and zero-downtime guide](/guides/rollback-and-zero-downtime-deploys) covers how releases, rollback and zero-downtime deploys work together. ### Automatic rollback when a new version fails to start On Intermediary and Enterprise, an application that stops within 60 seconds after a deploy now goes back to its previous version by itself, so a broken deploy no longer leaves the application down. * **When it acts:** only if the new version stops in the first 60 seconds after a deploy. A stop after that is treated as a normal crash and handled by auto-restart. * **Once only:** the platform goes back one time. If the previous version also stops, the application stays stopped and you are notified. * **What comes back:** the code files, not the environment variables. To bring variables back, use the manual rollback with the variables option. * **You are told:** you get a notification, the Rollbacks tab marks the failed version with its log, and the automatic rollback appears as a new version authored by Vertra Cloud. The application's live log shows the same notices. * **Setting:** it is off by default, including for applications created before this update. Turn it on in the application's settings, under **Deploy**, or with the new `deploy.auto_rollback` field of [Update Application Configuration](/api-reference/endpoint/apps/updateconfig). Changing it does not restart the application. [Get Application](/api-reference/endpoint/apps/get) now returns a `deploy` object with the saved deploy settings. After a downgrade the saved value stays, but it only acts on a plan that includes the feature. ### Safety snapshot when deleting an application On Pro and above, deleting an application now takes a safety snapshot of it first, as deleting a database already did. The snapshot is kept for 30 days in **Snapshots**, where you can download it. * **If the snapshot fails,** the application is not deleted and the request answers `SNAPSHOT_FAILED`; contact support. Too many safety snapshots in a short time answer `FORCED_SNAPSHOT_RATE_LIMIT`. * **On Free and Economy,** the application is deleted right away with no copy. The delete dialog says so and offers to download the project first. * **Plan expiry** still takes a snapshot of every project before removing it, on every plan. ### Roll back an application to an earlier version The **Rollbacks** tab now lets you go back to an earlier version of an application's code. Pick a version and confirm: the application returns to the code it had in that version and restarts. * **What comes back:** all the code of that version. Code files the version did not have are removed. * **What stays:** data the application created while running, such as a database file or uploads. To bring data back, use a snapshot. * **Environment variables (optional):** check the option to restore the variables saved with that version. The confirmation lists only the names of the variables that will be added, changed or removed. Values are never shown. * **Undo:** a rollback is a new version in the history, so you can roll back to the version you came from. Two rollbacks of the same application need 30 seconds between them. * **Limits by plan:** rollback starts on Pro. Pro keeps the 3 previous versions for 7 days, Scale 5 for 14 days, Intermediary 10 for 30 days, and Enterprise 15 to 30 by tier for 30 days. A version's time starts when it stops running; the running version never expires. Economy and Free show the history without the rollback option. The API has a [preview](/api-reference/endpoint/apps/releases/rollback-preview) of the variable changes and a [rollback](/api-reference/endpoint/apps/releases/rollback) endpoint. Rolling back needs the `apps:write` scope, plus `apps:envs` when restoring variables. ### Deploy history and commit messages for every application Each application now has a **Rollbacks** tab in the dashboard. It lists every version of the application's code, whatever its source: a push to GitHub, the CLI, an upload from the dashboard or the API, or an edit in the file manager. Each entry shows its status, message, author, date and build time. The tab is available on every plan. The history starts with the first code submission after this update. Applications created from a snapshot do not get an initial entry. Edits made in the file manager are grouped into the history at the next restart or code submission. Files sent without a restart show as **Awaiting restart** until the application restarts, because until then it keeps running the previous version. You can write a message for each version: * **Dashboard:** an optional message field in the upload dialog. * **API:** a `message` field on the file upload endpoint. * **CLI:** `vertra app commit -m "..."`. Without `-m`, inside a git repository, the CLI uses the subject of the latest commit. The API exposes the same history to your tools. [List releases](/api-reference/endpoint/apps/releases/list) returns the versions of an application, and [release log](/api-reference/endpoint/apps/releases/log) returns the log of one of them. Both require the `apps:read` scope. The Go SDK adds `Apps.Releases()` and a `Message` field on uploads. ### Auto-deploy from GitHub builds the commit you pushed Auto-deploy from GitHub now builds exactly the commit that was pushed. Before, the build took whatever was at the tip of the branch when the download started, so two pushes close together could show one commit in the deploy history while a newer one was running. Each deploy now matches the commit it lists. A push that deletes the `main` or `master` branch no longer starts a deploy. ### Releases, rollback and deploy settings from the CLI, SDKs and MCP The CLI, the JavaScript, Python and Go SDKs and the MCP server now cover releases, rollback and deploy settings, with the same plans and API key scopes as the dashboard and the API. * **CLI:** `vertra app releases` lists versions and `vertra app releases log` shows the log of a failed one. `vertra app rollback` shows what will happen and asks before it runs; with `--env` it lists only the names of the variables that change. Without a terminal it needs `--yes`. `vertra app config` accepts `--zero-downtime`, `--auto-rollback`, `--health-path` and `--clear-health-path`. * **SDKs:** `apps.releases` lists releases, reads a log, previews a rollback and runs it, in all three languages. Updating an application's configuration accepts the deploy settings, and uploads accept a message. * **MCP:** new tools `list_releases`, `get_release_log`, `preview_rollback` and `rollback_app`. `rollback_app` is marked destructive, so your client asks you to confirm. `update_app_config` accepts the deploy settings and `deploy_app` accepts a message. * **Scopes:** `apps:read` to list and read logs, `apps:envs` for the preview and to restore variables, `apps:write` to roll back. See [CLI](/cli#releases-and-rollback), [SDKs](/sdks#releases-and-rollback), [MCP](/mcp#releases-rollback-and-deploy-settings) and the [rollback and zero-downtime guide](/guides/rollback-and-zero-downtime-deploys). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.