Versions & Upgrades
When you deploy new code, Rivet ensures actors are upgraded seamlessly without downtime.
How Versions Work
Each runner has a version number. When you deploy new code with a new version, Rivet handles the transition automatically:
- New actors go to the newest version: When allocating actors, Rivet always prefers runners with the highest version number
- Multiple versions can coexist: Old actors continue running on old versions while new actors are created on the new version
- Drain old actors: When enabled, a runner connecting with a newer version number will gracefully stop old actors to be rescheduled to the new version
Versions are not configured by default. See Registry Configuration to learn how to configure the runner version.
Example Scenario
When a new version is deployed, existing actors are immediately drained from the old runner and live migrated to the new version.
When a new version is deployed, both versions coexist. New actors are created on the new version while existing actors continue running on the old version until.
Configuration
Setting the Version
Configure the runner version using an environment variable or programmatically:
We recommend injecting a value at built time that increments every deployment, such as:
- Build timestamp
- Git commit number (
git rev-list --count HEAD) - CI build number (
github.run_number)
Drain on Version Upgrade
The drainOnVersionUpgrade option controls whether old actors are stopped when a new version is deployed. This is configured in the Rivet dashboard under your runner configuration.
| Value | Behavior |
|---|---|
false (default) | Old actors continue running. New actors go to new version. Versions coexist. |
true | Old actors receive stop signal and have 30s to finish gracefully. |
Related
- Runtime Modes: Serverless vs runner deployment modes
- Lifecycle: Actor lifecycle hooks including
onSleep