When to Use
Use fal apps rollout when you need to restart all runners for an application without redeploying:
- Environment variable changes: Force runners to pick up updated secrets or environment variables
- Bad state recovery: Restart runners that may be in an unhealthy state
- Memory cleanup: Force garbage collection and memory cleanup across all runners
- Configuration updates: Apply changes that require a runner restart
Graceful vs Force Rollout
Graceful Rollout (Default)
Gracefully stops all active runners, allowing them to finish processing current requests before shutting down. This is the recommended approach for most situations.
How it works:
- Identifies all active runners for the application
- Sends a graceful stop signal to each runner
- Runners finish their current requests
- New runners are automatically started by the auto-scaling system as needed
Force Rollout
Immediately kills all active runners without waiting for current requests to complete. Use this when runners are unresponsive or when you need an immediate restart.
How it works:
- Identifies all active runners for the application
- Immediately terminates all runners
- New runners are automatically started by the auto-scaling system
Force rollout will terminate in-flight requests, potentially causing errors for active users. Use the graceful rollout (without --force) unless absolutely necessary.
Examples
Rollout after updating a secret
Rollout in a specific environment
Force rollout to recover from frozen runners
Difference from Redeployment
fal apps rollout is different from fal deploy:
fal apps rollout: Restarts existing runners without changing the application code or configuration. Useful for applying environment changes or recovering from bad states.
fal deploy: Creates a new revision of your application with updated code and configuration. Use this when you’ve made code changes.
See Also