Status
Active, superseded, failed, rolled back or expired. The live version is highlighted at the top of the list.
Deploys · rollback · zero downtime
Every deploy becomes a version. Going back takes one click.
Every code push, from GitHub, the CLI or the dashboard, lands in the app's history. If the new version misbehaves, you go back to the previous one without redoing anything. On higher plans, the platform goes back on its own or never takes the app offline.
vertracloud.app/dashboard/apps/shop-api/deploys
shop-api
4 versionsAutomatic rollback
Active41 s build
- View log
feat: first-purchase coupon
Failed7c4e2f1main38 s build
fix: checkout timeout
SupersededCLI12 s build
Sent from the dashboard
SupersededDashboard
≤ 30previous versions kept
≤ 30days of validity per version
60 sautomatic rollback window
Rollbacks tab
Your code's history, version by version.
Every code push becomes a complete version, wherever it comes from. The Rollbacks tab shows which one is live and what came before. Who did what stays in the Activities tab.
Commit and message
The short SHA and the commit message. A push without a message gets a label from its source, like “Sent from the CLI”.
Source
GitHub with the branch, CLI, dashboard or file editor. A rollback also enters the list, as a new version.
Build and log
How long the build took. When a version fails, “View log” opens the record of that crash.
On Economy, the tab shows the history without going back to versions. For apps that already existed, the history starts at the next code push.
Rollback · from Pro
The code goes back. The data stays.
Pick the version and confirm. The platform swaps the files and restarts the app in the same operation. The rollback enters the history as a new version, so you can undo it the same way.
The code goes back
Every code file goes back to how it was in that version. Files that arrived through commits after it are removed.
The data stays
What the app writes while running, like a SQLite database or uploads, is not part of any version and stays as it is. To go back on data, use Snapshots.
Variables, only if you check the box
By default, the current variables stay. Check the option to bring back the variables that version ran with. The dialog lists which ones would change, by name only, without showing values.
Go back to 3b9a0d4
“fix: checkout timeout” (yesterday, 6:04 PM)
Code files: always go back.
Bring back the environment variables from that deploy
Variables that change
- DISCORD_TOKENchanged
- NEW_FEATUREwill be removed
Data the app created while running does not go back. The app restarts when you confirm.
Automatic rollback · from Intermediary
If the new version crashes on startup, the previous one comes back on its own.
It's on by default on the plans that include it, and you can turn it off in the app's settings.
- 01
The deploy restarts the app
The new version starts with the code that just arrived.
- 02
It crashed in the first minute
If the app stops within the first 60 seconds, auto-restart doesn't keep retrying the new version: the platform goes back to the previous one, once.
- 03
You get told
A notification says the deploy crashed and which version the app went back to, with a link to the log of the failed version.
- Only the code files go back. The variables stay as they are.
- If the previous version also crashes, the app stays stopped and you're notified. There is no rollback loop.
- A crash after the first minute is handled as a normal crash, by auto-restart.
Zero-downtime deploys · Enterprise
The new version starts alongside. Traffic only moves when it responds.
For an app that receives web traffic, the deploy doesn't take the live version down: the new one starts next to it, passes the health check and only then takes over.
- 01
Starts alongside
The new version installs dependencies, builds and starts while the current one keeps serving.
- 02
Health check
The platform sends requests to the configured path (“/” by default) until it gets two good responses in a row. Any HTTP response counts, even a 404; a 5xx error or a refused connection doesn't.
- 03
Switch
Once healthy, the new version starts receiving traffic and the previous one is shut down.
- 04
Or discard
If the new version doesn't become healthy within about 2 minutes, it's discarded and the previous one stays live, without ever having stopped.
What to know before turning it on
The second copy doesn't count toward your plan's RAM during the switch. If the server has no free memory for it, the deploy stops the current version before starting the new one, with automatic rollback in effect.
- Both versions use the same folder and run together for up to about 2 minutes. A JSON file written by both at once can be corrupted; SQLite usually copes. A database migration run at startup runs while the previous version is still serving.
- An app that reads files on every request (PHP, static sites, a built Next.js or Nuxt app, late imports in Python) can serve a mix of old and new files while the deploy installs and builds. For those, use the Off mode.
- An app that only listens on 127.0.0.1 fails the health check. The log says why.
- During the build, the terminal shows the version that is live. The build appears in the install logs.
- Around the switch, both versions serve together for a few seconds.
Bots and workers
Why bots don't use zero-downtime deploys by default.
Two processes with the same token receive the same events. During the switch, a prefix command would be answered twice, a slash command would fail with an interaction-already-acknowledged error on one of the copies, and scheduled jobs would run twice. And a bot doesn't receive web traffic, so there's no traffic to move to the new version.
Three modes, in the app's settings
Auto
The default. Zero downtime only for apps that receive web traffic; bots and workers stop and start, with automatic rollback.
On
Forces zero-downtime deploys on any app, bots included. Without web traffic, the new version is healthy after running 30 seconds without crashing. During the switch, an event can be answered twice.
Off
The current version stops before the new one starts. Use it for apps that read files on every request; the app is offline for a few seconds.
Limits by plan
How many versions are kept, and for how long.
Versions are counted besides the one that is live. Validity starts when a version stops being the active one; the live version never expires. After its validity, a version stays in the history, but you can no longer go back to it.
| Plan | Previous versions | Validity | Automatic rollback | Zero downtime |
|---|---|---|---|---|
| Economy | Read-only | Not included | Not included | |
| Pro | 3 | 7 days | Not included | Not included |
| Scale | 5 | 14 days | Not included | Not included |
| Intermediary | 10 | 30 days | Included | Not included |
| Enterprise-4 · 6 · 8 | 15 | 30 days | Included | Included |
| Enterprise-12 · 14 · 16 | 20 | 30 days | Included | Included |
| Enterprise-18 · 20 · 22 · 24 | 25 | 30 days | Included | Included |
| Enterprise-26 · 28 · 30 · 32 | 30 | 30 days | Included | Included |
On Enterprise, the number of versions grows with the plan tier.
Compare plansFAQ
Before your next deploy
What happens to code, data and variables when you go back to a version.
Does a rollback erase my app's data?
No. A rollback only swaps the code. What the app writes while running, like a SQLite database or files uploaded by users, stays as it is. A file you committed yourself goes back like any other code file. To go back on data, use Snapshots.
Can I bring back the environment variables too?
Yes, if you check the option in the dialog. It brings back the variables that version ran with. Before you confirm, the dialog lists only the names of the variables that would change; values never appear.
Does it work with GitHub, the CLI and dashboard uploads?
Yes. Every code push becomes a complete version, wherever it comes from, and any of them can be a rollback target while it's within your plan's limit and validity.
My app already existed. Can I go back to old versions?
The history starts at the first code push after the feature launched. Earlier versions were not kept, so there's no way to go back to them.
What happens to versions if I change plans?
The new plan's version count and validity apply. On a downgrade, versions beyond the limit stop being available; on an upgrade, what was already deleted doesn't come back.
Can I turn off automatic rollback?
Yes, in the app's settings or through the API, at PATCH /v1/apps/:id/config. When it's off, a crash right after a deploy follows normal auto-restart.
From Pro
Deploy knowing you can go back.
Create your account, ship the app and the history starts at the first code push.