Rollbacks & Revisions

Manage app revisions, roll back to previous versions, and restart runners.

Every time you run fal deploy, a new revision is created. Your app’s alias (e.g., my-model) always points to one active revision. You can switch between revisions to roll back to a previous version instantly.

Viewing Revisions

CLI

fal apps list-rev my-model

This shows all revisions with their IDs, creation dates, machine types, and scaling configuration.

Dashboard

Navigate to Dashboard > Apps > [your-app] > Versions. The versions page shows:

• All revisions with creation timestamps
• Status badges: Deployed, Failed, Deploying, Suspended
• The current active revision marked with a Current badge

---

Rollouts

A rollout restarts all runners without changing the revision. Your app stays on the same code, but all runners are recycled.

CLI

# Graceful rollout (runners finish current requests before stopping)
fal apps rollout my-model

# Force rollout (runners are killed immediately)
fal apps rollout my-model --force

When to Use Rollouts

• After changing secrets — Runners need to restart to pick up new environment variable values
• Clearing bad state — A runner is stuck or has corrupted in-memory state
• Memory cleanup — Long-running runners have accumulated memory that won’t be freed
• After a config change — You changed scaling params via CLI and want runners to restart cleanly

A force rollout (--force) kills runners immediately, dropping any in-progress requests. Use graceful rollouts in production unless you need an emergency restart.

---

Rolling Back

Switch your app to a previous revision. The old code starts serving requests immediately — no rebuild needed.

CLI

# List revisions to find the ID you want
fal apps list-rev my-model

# Switch to a specific revision
fal apps set-rev my-model <revision_id>

Dashboard

1. Go to Dashboard > Apps > [your-app] > Versions
2. Find the revision you want to roll back to
3. Click Rollback
4. Confirm in the dialog

When you roll back, runtime-tunable scaling parameters (keep_alive, min_concurrency, etc.) are inherited from the currently active revision. Code-specific parameters (max_multiplexing, startup_timeout, machine_type) come from the target revision’s code.

Rollback Strategies

When you roll back with fal apps set-rev, you can also choose how fal rolls traffic to the target revision:

# Switch only after the target revision has a healthy runner
fal apps set-rev my-model <revision_id> --strategy rolling

# Switch immediately and let runners start on demand
fal apps set-rev my-model <revision_id> --strategy recreate

• Rolling starts a runner on the target revision first and waits for it to complete setup() and become healthy before switching the alias. Use this when you want the safest rollback with the least user-visible interruption.
• Recreate switches the alias to the target revision immediately. No runner is started proactively, so the next request may cold start the rolled-back revision. Use this when speed matters more than avoiding a brief interruption.

These strategies control how the rollback is applied. A rollback still switches your app to a different revision; a rollout still restarts runners without changing revisions.

When to Roll Back

• A new deploy introduced a bug
• Model performance regressed after an update
• You need to quickly revert while investigating an issue

---

Deleting Revisions

Clean up old revisions you no longer need.

CLI

fal apps delete-rev my-model <revision_id>

Dashboard

On the Versions page, use the delete option on any non-current revision.

You cannot delete the currently active revision. Switch to a different revision first if you need to delete it.

---

Rollback vs Rollout

	Rollback	Rollout
What changes	Switches to a different revision (different code)	Restarts runners on the same revision
Use case	Revert to a previous version	Refresh runner state
Rebuild needed	No (previous image already exists)	No
Downtime	Brief (new runners start on the old revision)	Brief (runners restart)
CLI	fal apps set-rev	fal apps rollout