Skip to main content
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

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

​
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

​
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:
  • 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

​
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