Skip to main content
​
October 12, 2026

​
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 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 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 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. Changing it does not restart the application.
Get Application 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 of the variable changes and a 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 returns the versions of an application, and release 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, SDKs, MCP and the rollback and zero-downtime guide.