Rewind

Rewind takes your app back to a moment: the code that was live, the env vars and settings it ran with, and the data it used, together. You choose which parts come back, look at a preview of the result on its own URL, and only then make it live. The original databases and caches are never overwritten, so an applied rewind can be undone.

Rewind from the dashboard

Open the app and go to the Rewind tab.

  1. Pick a moment. Drag the slider, use a shortcut (10 minutes ago, an hour ago, yesterday) or type an exact time in your own time zone. The strip above the slider marks your deploys, your database's restore window and your snapshots.
  2. Pick the parts. Every part of the app has a switch: the code, the env vars and settings, each database, each cache, and the files on its volume. Next to each one you see exactly what it would come back as. Anything you switch off stays as it is now.
  3. Preview this rewind. velixir builds a copy of your app as it was, with its own copies of the data, on its own velixir.run address. This takes a few minutes, mostly while a database replays its history to the exact second. Nothing changes on the live app.
  4. Apply to the live app, from the preview's row under Previews and copies, once you've checked it.

How exact each part is

Part Comes back as
Code The release that was live at that moment
Env vars and settings The env vars, ports, health check and bindings that release was deployed with
Postgres databases Exactly that second, within your plan's backup window
Valkey caches The newest snapshot taken before that moment
Files on a volume The newest snapshot taken before that moment

A cache on a plan without snapshots starts empty, which most apps cope with, since a cache is rebuilt as it's used. A volume with no snapshot from before that moment can't be rewound; switch files off to rewind everything else.

Plan, size and replica counts aren't rewound: they're capacity, not state, and putting them back in the middle of a traffic spike would make things worse.

How far back

  • Code and config: 28 days. Releases deployed in that time are kept so they can always run again.
  • Databases: as far as the database plan keeps backups: 7 days on Starter, 14 on Standard, 28 on Pro and Scale. The earliest point is shown on the database's page and on the Rewind strip.
  • Caches: as far as their snapshots go. Snapshots are taken every 6 hours, kept for a day, then one a day for the plan's retention. The Starter cache plan has no snapshots.
  • Files: as far as the volume's snapshots go (daily or weekly, kept 7 to 90 days). See Volumes.

What applying does

  • The app is pointed at the preview's copies of the databases and caches in the rewind. The originals keep running, untouched, with everything written to them since that moment still in them.
  • The files on the volume are snapshotted as they are now, then restored from the snapshot in place (a volume can't be swapped like a database).
  • The release and config from then are deployed.
  • The preview's own app is deleted. Its database and cache copies now belong to your app.

Data written to the live app after that moment is set aside on the originals, not deleted. If you need some of it, it's there to copy across.

Billing: the originals keep running, and billing, until you delete them. Once you're sure you won't undo, delete them from the project.

Undo

Undo on an applied rewind puts the app back on its original databases and caches, deploys the release and config it had just before, and restores the files snapshot taken when you applied. The copies the rewind made stay until you Discard it.

Only one rewind can be applied to an app at a time.

What Rewind can't do

Rewind restores your app, not the outside world. An email already sent, a payment already taken or a webhook another service received stays that way.

Rolling back code only

For a quick rollback of just the code, use Rollback on the Deploys tab: it redeploys an earlier release without a rebuild and keeps your current env vars. + config next to it also brings back the env vars and settings that release last ran with.

From the CLI

velixir rewind plan --at "2h ago"                 # what each part would come back as
velixir rewind --at "2h ago" --no-databases       # preview: code, config, caches and files
velixir rewind apply <rewind-id>                  # asks first; --yes in scripts
velixir rewind undo <rewind-id>
velixir rewind list

--at takes 30m ago, 2h ago, 1d ago, now, a time in your local zone like 2026-10-16 09:41, or UTC like 2026-10-16T08:41:00Z. Leave parts out with --no-code, --no-config, --no-databases, --no-caches, --no-files, or --exclude <id> for one database or cache.

From the API or an agent

  • GET /api/v1/apps/{id}/timeline: deploys, config changes and restore points.
  • GET /api/v1/apps/{id}/rewind/plan?at=...: what a rewind would restore (add code=false, databases=false, exclude=<id> and so on).
  • POST /api/v1/apps/{id}/rewind with { "at": "...", "databases": true, ... }: start a preview.
  • POST /api/v1/forks/{id}/apply and /undo, GET /api/v1/forks/{id} for progress, DELETE /api/v1/forks/{id} to discard.

In the MCP server, the same steps are rewind_plan, rewind, fork_status, rewind_apply and rewind_undo. The tools tell an agent to ask you before applying.

Plans

A preview is an app on the same plan as yours. The Free plan includes one app, so move a Free app to a paid plan before rewinding it.