Versions & Upgrades

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

Example Scenario

When a new version is deployed, existing actors are gracefully stopped on the old runner and rescheduled onto the new version.

sequenceDiagram
    participant R1 as Runner v1
    participant R2 as Runner v2

    Note over R1: Currently running
    Note over R2: Deployed
	R2->>R1: Drain old actors
    R1->>R2: Reschedule actors
    Note over R1: Shut down when all actors stopped

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.

sequenceDiagram
    participant R1 as Runner v1
    participant R2 as Runner v2

    Note over R1: Currently running
    Note over R2: Deployed
	Note over R1: Actor 1 sleeps from inactivity
	Note over R2: Actor 1 wakes up when prompted

Configuration

Setting the Version

Configure the runner version using an environment variable or programmatically:

RIVET_ENVOY_VERSION=2

Example Configurations

We recommend injecting a build-time value that increments with every deployment. Here are concrete examples for common setups:

Generate the version at build time and bake it into the image as an environment variable:

docker build --build-arg RIVET_ENVOY_VERSION=$(date +%s) .

FROM node:20-slim
ARG RIVET_ENVOY_VERSION
ENV RIVET_ENVOY_VERSION=$RIVET_ENVOY_VERSION
WORKDIR /app
COPY . .
RUN npm install && npm run build
CMD ["node", "dist/server.js"]

All containers from this image will share the same version.

Set the version in next.config.ts. Next.js evaluates this file once at build time and inlines the value into the bundle:

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  env: {
    RIVET_ENVOY_VERSION: String(Math.floor(Date.now() / 1000)),
  },
};

export default nextConfig;

Use define in your Vite config. This is evaluated once at build time and inlined into the bundle:

import { defineConfig } from "vite";

export default defineConfig({
  define: {
    "process.env.RIVET_ENVOY_VERSION": JSON.stringify(
      String(Math.floor(Date.now() / 1000))
    ),
  },
});

Set the version from your CI pipeline:

# GitHub Actions
env:
  RIVET_ENVOY_VERSION: ${{ github.run_number }}

# Railway / Render / generic CI
export RIVET_ENVOY_VERSION=$(date +%s)

# Git commit count
export RIVET_ENVOY_VERSION=$(git rev-list --count HEAD)

Generate a version file during your build step and import it:

{
  "scripts": {
    "build": "echo \"export const BUILD_VERSION = $(date +%s);\" > src/build-version.ts && tsc"
  }
}

import { actor, setup } from "rivetkit";
import { BUILD_VERSION } from "./build-version";

const myActor = actor({ state: {}, actions: {} });

const registry = setup({
  use: { myActor },
  envoy: {
    version: BUILD_VERSION,
  },
});

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. See Pool Configuration for the full set of pool options, including how to rate-limit actor eviction during the drain.

Upgrading Actor State

When you deploy a new version, existing actors may need to handle schema changes in their persisted data.

SQLite (recommended for complex schemas)

Drizzle (recommended)

Use Drizzle for typed schemas with generated migrations. Drizzle generates versioned .sql migration files from your TypeScript schema and applies them in order automatically. This is the recommended approach when your schema evolves frequently.

Raw SQL

For actors using raw SQLite, migrations run automatically via the onMigrate hook on every actor start. RivetKit wraps the hook in a SQLite savepoint, so the migration is fully atomic. Use SQLite's user_version pragma to track which migrations have run:

In-memory state (c.state)

If you use c.state for persistence, you are responsible for handling schema changes yourself. If you add, remove, or rename fields between versions, your code must handle the old shape gracefully.

Manual defaults in onWake

Apply defaults for missing fields:

Zod schema coercion

Use Zod to parse persisted state on wake. Zod's .default() fills in missing fields automatically, so old actor state is coerced to the current schema:

For anything beyond simple defaults, consider moving to SQLite where you get proper migration tooling.

Advanced

How Version Upgrade Detection Works

When drainOnVersionUpgrade is enabled, Rivet uses two mechanisms to detect version changes:

• New runner connection: When a runner connects with a newer version number, the engine immediately drains all older runners with the same name. This is the primary mechanism for runner mode deployments.
• Metadata polling (serverless only): In serverless mode, runners periodically poll the engine to check for newer versions and self-drain if one is found. This ensures old runners drain even if no new requests trigger a runner connection.

SIGTERM Handling

When a runner process receives SIGTERM, it gracefully stops all actors before exiting:

• Each actor's onSleep hook is called, giving it time to save state
• Actors are rescheduled to other available runners
• The runner waits up to 30 minutes for all actors to finish stopping
• If the process is force-killed before actors finish (e.g. SIGKILL), actors are rescheduled with a crash backoff penalty instead of a clean handoff

Shutdown Timeouts

Several timeouts control how long each part of the shutdown process can take:

Rivet has a max shutdown grace period of 30 minutes that cannot be configured.

Related

• Runtime Modes: Serverless vs runner deployment modes
• Lifecycle: Actor lifecycle hooks including onSleep