Rollback & redeploy
Undo a bad deploy in seconds, re-run one from scratch, and keep an old version safe forever — from the dashboard or the terminal.
Every project keeps a history of its deploys — like the version history in a document. If a new deploy turns out broken, you don't have to panic or dig through code: you can flip the project back to a version that worked. And when you just want to run the same thing again — after a fix, or to pick up the latest commit — you redeploy. This guide covers both, plus how to "pin" a good version so it's always there to fall back to.
What you need first
- A project in Alaf Server that has been deployed at least once.
- Nothing else — rollback and redeploy both work on deploys you already have.
Find the deploy history
Open your project and click the Deployments tab. You'll see two things:
- At the top, a Deploy Latest Changes card with a Redeploy Project button — that's for shipping again.
- Below it, the history: every deploy this project has had, newest first, each on its own row.
Each row shows the version (like v3), a status, the commit message, and small labels that tell you the
state of that version:
- Active — the version currently live and serving your site.
- Snapshotted — Alaf Server still has this version's finished build saved, so you can roll back to it fast, without a rebuild.
- Pinned — this version is kept safe forever and will never be cleaned up (more on this below).
Screenshot
Roll back to a version that worked
Open the version you want to return to
In the history, find the last row that was healthy. It should show the Snapshotted label — that's your signal Alaf Server still has its build ready to restore. (A Pinned row works too: pinning keeps that saved build around, so pinned versions stay rollback-ready as well.)
Click the ⋮ (three-dots) menu on that row.
Choose "Rollback to this version"
Press Rollback to this version. Alaf Server asks you to confirm, and reminds you what rollback does:
This restores the application code only. Database and volume data are unchanged.
Confirm, and Alaf Server switches the live site back to that version.
Screenshot
Why rollback is quick — and safe for your data
Rolling back does not rebuild anything. Alaf Server kept a copy of that version's finished build, so it simply switches back to it. Two things follow from that:
- It's fast, with no long outage. There's no waiting for a fresh build — Alaf Server restarts the saved version, so your site is back in seconds instead of the minutes a full build takes.
- Only your code changes. Your database and any saved files (volumes) are left exactly as they are. Rollback rewinds the app, not your data.
The rollback option is greyed out
Rollback needs the saved build (the Snapshotted label). Alaf Server only keeps a limited number of old builds per project, so very old versions get cleaned up over time. When that happens, the menu offers Redeploy this commit instead — it rebuilds that exact commit from your source code. It's slower than a rollback (a full build runs again), but it gets you to the same place. To stop a version from ever being cleaned up, pin it — see below.
Redeploy (run it again)
Redeploying builds and ships your project again. Reach for it after you push a fix, or when you want the live site to pick up the newest commit.
On the Deployments tab, press Redeploy Project. Alaf Server pulls the latest commit on your deploy branch, reuses your project's current settings and environment variables, and creates a new version. There's no setup screen — it just goes, and drops you on the build screen to watch.
The small caret (⌄) next to the button opens a couple of extra choices:
- Refresh env — redeploy so the app picks up environment-variable changes you just made.
- Rebuild all — rebuild every service instead of only the ones whose files changed. This choice appears only for multi-service projects (a single-app project always rebuilds the whole app anyway).
Rebuild one specific old commit
Want to rebuild one particular past deploy from source rather than shipping the latest? It depends on whether that row still has its saved build:
- Build still saved (Snapshotted or Pinned): the row's ⋮ menu shows Rollback to this version, not a rebuild option — use it, since a rollback gets you there instantly with no build.
- Build cleaned up: the same menu now offers Redeploy this commit, which rebuilds that exact commit from source and adds it as a new version.
To force a from-source rebuild of a specific commit from the terminal at any time — saved build or not — use
alaf server deployment redeploy <id> --use-existing-commit (below).
Pin a version so it's always there
Alaf Server keeps only so many old builds around, then cleans up the oldest to save space. If there's a known-good version you always want to be able to snap back to, pin it.
In a deploy row's ⋮ menu, choose Pin. That version becomes exempt from cleanup and stays instantly rollback-restorable for as long as you keep it pinned. To lift it later, open the menu again and choose Unpin.
Good to know
You can pin up to 10 deploys per project. Pin your last reliable release before trying something risky — that way rollback is always one click away, no rebuild required.
Prefer the terminal?
Every action above works from the CLI. First list the deploys to get their IDs:
# List this project's deploys (newest first). The "active" column marks the live one.
# Run it inside your linked project folder, or target another with --project <project-id>.
alaf server deployment list
# Look at one in detail (status, commit, url, whether it's pinned)
alaf server deployment get <deployment-id>Then act on one by its ID:
# Roll back to a previous deploy (pass the ID of the one you want to return TO)
alaf server deployment rollback <deployment-id>
# Redeploy from an existing deploy — picks up the latest commit on its branch
alaf server deployment redeploy <deployment-id>
# ...or rebuild that deploy's exact commit instead of the latest
alaf server deployment redeploy <deployment-id> --use-existing-commit
# Pin a deploy so it's never cleaned up (add --off to unpin)
alaf server deployment pin <deployment-id>
alaf server deployment pin <deployment-id> --offTip
To simply ship the latest commit of the whole project (the terminal equivalent of Redeploy Project), run
alaf server deploy from the project folder. Use alaf server deployment redeploy when you want to re-run one
specific deploy from the history.
If something goes wrong
“This deployment is already active”
You're trying to roll back to the version that's already live. Pick a different row from the history — the one currently serving is marked Active and can't be rolled back to itself.
“Only successful deployments can be rolled back to”
You can only return to a version that finished healthy. A deploy that failed or was cancelled isn't a valid restore target — choose the last row that shows a ready/deployed status.
The site still looks wrong after rolling back
Remember rollback changes code only — it never touches your database or saved files. If the problem was a bad data change or a migration, rolling back the code won't undo it. You'll need to restore your data from a backup or fix it directly.
What next?
Auto-deploy on push
Make Alaf Server rebuild and ship your app automatically every time you push to GitHub — from the dashboard or the terminal.
Logs & monitoring
See what your app is doing — its runtime logs, its incoming web requests, and its traffic — and know exactly where to look when something breaks.