rivet-dev · NathanFlurry · Aug 11, 2026 · Aug 11, 2026
diff --git a/vendor/actors/docs/CLAUDE.md b/vendor/actors/docs/CLAUDE.md
@@ -77,7 +77,7 @@ the website's icon package.
 
 - **Marketing pages.** They live in the website repo.
 - **Deploy and self-hosting guides.** They are written once in the website repo
-  and templated across all four products. Do not write a per-product copy.
+  and templated across every product. Do not write a per-product copy.
 - **Website components.** Do not import from the website by relative path or
   alias; a page must render from the components the site already provides.
 

diff --git a/vendor/actors/docs/content/docs/actions.mdx b/vendor/actors/docs/content/docs/actions.mdx
@@ -133,11 +133,3 @@ See [types](/actors/docs/types) for more details on using `ActionContextOf` and
 - `GET /inspector/rpcs` lists all available actions on an actor.
 - `POST /inspector/action/:name` executes an action with JSON args and returns output.
 - In non-dev mode, inspector endpoints require authorization.
-
-## API Reference
-
-- [`Actions`](/typedoc/interfaces/rivetkit.mod.Actions.html) - Interface for defining actions
-- [`ActionContext`](/typedoc/interfaces/rivetkit.mod.ActionContext.html) - Context available in action handlers
-- [`ActorDefinition`](/typedoc/interfaces/rivetkit.mod.ActorDefinition.html) - Interface for defining actors with actions
-- [`ActorHandle`](/typedoc/types/rivetkit.client_mod.ActorHandle.html) - Handle for calling actions from client
-- [`ActorActionFunction`](/typedoc/types/rivetkit.client_mod.ActorActionFunction.html) - Type for action functions
diff --git a/vendor/actors/docs/content/docs/authentication.mdx b/vendor/actors/docs/content/docs/authentication.mdx
@@ -122,9 +122,3 @@ The limits in this example are [ephemeral](/actors/docs/state#ephemeral-variable
 Cache validated tokens in `c.vars` to avoid redundant validation on repeated connections. See [ephemeral variables](/actors/docs/state#ephemeral-variables) for more details.
 
 <CodeSnippet file="examples/docs/actors-authentication/caching-tokens.ts" />
-
-## API Reference
-
-- [`AuthIntent`](/typedoc/types/rivetkit.mod.AuthIntent.html) - Authentication intent type
-- [`OnBeforeConnectContext`](/typedoc/interfaces/rivetkit.mod.OnBeforeConnectContext.html) - Context for auth checks
-- [`OnConnectContext`](/typedoc/interfaces/rivetkit.mod.OnConnectContext.html) - Context after connection
diff --git a/vendor/actors/docs/content/docs/clients/javascript.mdx b/vendor/actors/docs/content/docs/clients/javascript.mdx
@@ -139,6 +139,3 @@ Requests can still return transient lifecycle or gateway errors. Retry once the
 **Package:** [rivetkit](https://www.npmjs.com/package/rivetkit)
 
 See the [RivetKit client overview](/actors/docs/clients).
-
-- [`createClient`](/typedoc/functions/rivetkit.client_mod.createClient.html) - Create a client
-- [`Client`](/typedoc/types/rivetkit.mod.Client.html) - Client type
diff --git a/vendor/actors/docs/content/docs/communicating-between-actors.mdx b/vendor/actors/docs/content/docs/communicating-between-actors.mdx
@@ -45,9 +45,3 @@ Use connections to listen for events from other actors:
 Process multiple items in parallel:
 
 <CodeSnippet file="examples/docs/actors-communicating-between-actors/batch-operations.ts" />
-
-## API Reference
-
-- [`ActorHandle`](/typedoc/types/rivetkit.client_mod.ActorHandle.html) - Handle for calling other actors
-- [`Client`](/typedoc/types/rivetkit.mod.Client.html) - Client type for actor communication
-- [`ActorAccessor`](/typedoc/interfaces/rivetkit.client_mod.ActorAccessor.html) - Accessor for getting actor handles
diff --git a/vendor/actors/docs/content/docs/connections.mdx b/vendor/actors/docs/content/docs/connections.mdx
@@ -58,8 +58,6 @@ Pending connections are not visible in `c.conns` while `onBeforeConnect` or `cre
 
 ### `createConnState` and `connState`
 
-[API Reference](/typedoc/interfaces/rivetkit.mod.CreateConnStateContext.html)
-
 There are two ways to define the initial state for connections:
 1. `connState`: Define a constant object that will be used as the initial state for all connections
 2. `createConnState`: A function that dynamically creates initial connection state based on connection parameters. Can be async.
@@ -68,8 +66,6 @@ Connections are not visible in `c.conns` until `createConnState` completes succe
 
 ### `onBeforeConnect`
 
-[API Reference](/typedoc/interfaces/rivetkit.mod.OnBeforeConnectContext.html)
-
 The `onBeforeConnect` hook is called whenever a new client connects to the actor. Can be async. Clients can pass parameters when connecting, accessible via `params`. This hook is used for connection validation and can throw errors to reject connections.
 
 The `onBeforeConnect` hook does NOT return connection state - it's used solely for validation.
@@ -82,8 +78,6 @@ Connections cannot interact with the actor until this method completes successfu
 
 ### `onConnect`
 
-[API Reference](/typedoc/interfaces/rivetkit.mod.OnConnectContext.html)
-
 Executed after the client has successfully connected. Can be async. Receives the connection object as a second parameter.
 
 By the time `onConnect` runs, the connection is visible in `c.conns`.
@@ -94,8 +88,6 @@ Messages will not be processed for this actor until this hook succeeds. Errors t
 
 ### `onDisconnect`
 
-[API Reference](/typedoc/interfaces/rivetkit.mod.ActorDefinition.html)
-
 Called when a client disconnects from the actor. Can be async. Receives the connection object as a second parameter. Use this to clean up any connection-specific resources.
 
 <CodeSnippet file="examples/docs/actors-connections/on-disconnect.ts" />
@@ -125,12 +117,3 @@ If you need to wait for the disconnection to complete, you can use `await`:
 <CodeSnippet file="examples/docs/actors-connections/disconnect-await.ts" />
 
 This ensures the underlying network connections close cleanly before continuing.
-
-## API Reference
-
-- [`Conn`](/typedoc/interfaces/rivetkit.mod.Conn.html) - Connection interface
-- [`ConnInitContext`](/typedoc/interfaces/rivetkit.mod.ConnInitContext.html) - Connection initialization context
-- [`CreateConnStateContext`](/typedoc/interfaces/rivetkit.mod.CreateConnStateContext.html) - Context for creating connection state
-- [`OnBeforeConnectContext`](/typedoc/interfaces/rivetkit.mod.OnBeforeConnectContext.html) - Pre-connection lifecycle hook context
-- [`OnConnectContext`](/typedoc/interfaces/rivetkit.mod.OnConnectContext.html) - Post-connection lifecycle hook context
-- [`ActorConn`](/typedoc/types/rivetkit.client_mod.ActorConn.html) - Typed connection from client side
diff --git a/vendor/actors/docs/content/docs/container-runner.mdx b/vendor/actors/docs/content/docs/container-runner.mdx
@@ -0,0 +1,100 @@
+---
+title: "Container Runner"
+description: "Run any containerized server as a Rivet Actor."
+skill: true
+---
+
+The container runner (`rivet-container-runner`) is an adapter for running arbitrary containers as Rivet Actors. Use it for non-RivetKit workloads such as Unity or Godot dedicated game servers and batch jobs like FFmpeg transcoding.
+
+## Steps
+
+<Steps>
+<Step title="Prerequisites">
+
+- A containerized server (a Unity or Godot dedicated server, a plain Node process, or any HTTP/WebSocket server)
+- Access to the [Rivet Cloud](https://dashboard.rivet.dev/) or a [self-hosted Rivet Engine](/actors/self-host)
+- Docker running locally
+
+</Step>
+<Step title="Install in Your Container">
+
+Download the static binary from Rivet's release artifacts in your Dockerfile and set it as the entrypoint, passing your server's launch command after `--`:
+
+```dockerfile @nocheck
+FROM debian:bookworm-slim
+RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates curl && rm -rf /var/lib/apt/lists/*
+
+# Install the Rivet container runner.
+RUN curl -fsSL https://releases.rivet.dev/rivet/latest/container-runner/rivet-container-runner-x86_64-unknown-linux-musl \
+        -o /usr/local/bin/rivet-container-runner \
+    && chmod +x /usr/local/bin/rivet-container-runner
+
+# Your server binary and assets.
+COPY build/ /game/
+WORKDIR /game
+
+ENTRYPOINT ["rivet-container-runner", "--", "./GameServer", "-batchmode", "-nographics", "-logFile", "-"]
+```
+
+Artifacts are published for `x86_64-unknown-linux-musl` and `aarch64-unknown-linux-musl`. The binaries are fully static, so they run in any Linux base image, including `scratch`. Pin a version by replacing `latest` with a release version, for example `https://releases.rivet.dev/rivet/2.3.3/container-runner/rivet-container-runner-x86_64-unknown-linux-musl`.
+
+</Step>
+<Step title="Deploy">
+
+Deploy the image to Rivet Compute with the CLI. For game servers, configure the pool with one actor per instance and keep running instances alive across version upgrades:
+
+```bash
+npx @rivetkit/cli deploy \
+	--token "$RIVET_CLOUD_TOKEN" \
+	--instance-request-concurrency 1 \
+	--drain-on-version-upgrade false \
+	--dockerfile Dockerfile
+```
+
+</Step>
+<Step title="Create Actors and Connect Clients">
+
+Create actors against the pool's runner (`default`) and connect clients through the gateway URL shown in the dashboard. WebSocket clients connect at the bare gateway URL with the `rivet` WebSocket subprotocol.
+
+</Step>
+</Steps>
+
+## How It Works
+
+1. The engine cold-starts your container and calls `POST /api/rivet/start` on the port it injects as `RIVET_PORT`.
+2. The runner spawns your server as a child process with `PORT` set to the child port, waits for the port to open, and reports the actor as running.
+3. Gateway traffic for the actor arrives over Rivet's tunnel and is proxied to `127.0.0.1:<child port>`. WebSocket clients connect at the bare gateway URL with the `rivet` WebSocket subprotocol. Raw HTTP reaches the child under the `/request/*` prefix on the actor surface (the prefix is stripped before proxying); other paths are reserved for the runtime's own endpoints.
+4. Child stdout and stderr are re-emitted with an `[actorId=... key=...]` prefix so actor logs are attributed in the dashboard.
+5. When an actor stops, the runner sends its child `SIGTERM`, escalates to `SIGKILL` after a grace period, and exits the process once no actors remain.
+
+## Configuration
+
+All flags can also be set through environment variables:
+
+| Flag | Environment variable | Default | Description |
+| --- | --- | --- | --- |
+| `--port` | `RIVET_PORT` / `PORT` | `8080` | Serverless front-door HTTP port. Rivet Compute injects `RIVET_PORT` automatically. |
+| `--child-port` | `CHILD_PORT` | `7770` | First local child port; each actor's child gets the next free port at or above this, exported to the child as `PORT`. |
+| `--actor-name` | `RIVET_ACTOR_NAME` | `game` | Actor name this runner serves. |
+| `--runner-version` | `RIVET_RUNNER_VERSION` | `1` | Version reported to the engine, used to drain old runners on deploy. |
+| `--base-path` | `RIVET_SERVERLESS_BASE_PATH` | `/api/rivet` | Base path the engine calls for serverless start. |
+| `--stop-grace-secs` | `RIVET_STOP_GRACE_SECS` | `25` | `SIGTERM` to `SIGKILL` grace period when stopping the child. Capped to a few seconds when the platform itself is reclaiming the instance, so shutdown fits inside the platform's own kill window. |
+| `--readiness-timeout-secs` | `RIVET_READINESS_TIMEOUT_SECS` | `30` | How long to wait for the child's port to open before failing the start. |
+
+### Per-Actor Input
+
+The actor's `input` payload can override the launch spec per actor. All fields are optional and fall back to the entrypoint command. RivetKit clients pass this object directly; when creating actors through the raw engine API, encode it as CBOR before base64-encoding the `input` field:
+
+```json
+{
+	"command": ["./GameServer", "-batchmode"],
+	"args": ["-extra-flag"],
+	"env": { "MATCH_MODE": "ranked" }
+}
+```
+
+`command` replaces the entrypoint command template, `args` are appended to it, and `env` adds environment variables for the child.
+
+## Source and Examples
+
+The runner and a full end-to-end example, including a Unity FishNet demo project and a local test harness, live in the Rivet repository under [`container-runner/`](https://github.com/rivet-dev/rivet/tree/main/container-runner).
diff --git a/vendor/actors/docs/content/docs/design-patterns.mdx b/vendor/actors/docs/content/docs/design-patterns.mdx
@@ -146,7 +146,6 @@ Use this when:
 </Tab>
 </Tabs>
 
-
 ### Syncing State Changes
 
 Use `onStateChange` to automatically sync actor state changes to external resources. This hook runs after state changes are flushed, which is coalesced to once per event loop tick rather than once per individual field mutation.
@@ -208,9 +207,3 @@ Actors are designed to maintain state across multiple requests. Creating a new a
 <CodeSnippet file="examples/docs/actors-design-patterns/actor-per-request.ts" />
 
 **Solution:** Use actors for entities that persist (users, sessions, documents), not for one-off operations. For stateless request handling, use regular functions.
-
-## API Reference
-
-- [`ActorDefinition`](/typedoc/interfaces/rivetkit.mod.ActorDefinition.html) - Interface for pattern examples
-- [`ActorContext`](/typedoc/interfaces/rivetkit.mod.ActorContext.html) - Context usage patterns
-- [`ActionContext`](/typedoc/interfaces/rivetkit.mod.ActionContext.html) - Action patterns
diff --git a/vendor/actors/docs/content/docs/destroy.mdx b/vendor/actors/docs/content/docs/destroy.mdx
@@ -68,8 +68,3 @@ Once destroyed, the `onDestroy` hook will be called. This can be used to clean u
 ## Accessing Actor After Destroy
 
 Once an actor is destroyed, any subsequent requests to it will fail with an `actor.not_found` error (`{ group: "actor", code: "not_found" }`). The actor's state is permanently deleted.
-
-## API Reference
-
-- [`ActorHandle`](/typedoc/types/rivetkit.client_mod.ActorHandle.html) - Has destroy methods
-- [`ActorContext`](/typedoc/interfaces/rivetkit.mod.ActorContext.html) - Context during destruction
diff --git a/vendor/actors/docs/content/docs/errors.mdx b/vendor/actors/docs/content/docs/errors.mdx
@@ -121,9 +121,3 @@ For faster debugging during development, you can expose internal error details t
 With error exposure enabled, clients will see the full error message instead of the generic "Internal error" response:
 
 <CodeSnippet file="examples/docs/actors-errors/expose-errors.ts" />
-
-## API Reference
-
-- [`UserError`](/typedoc/classes/rivetkit.actor_errors.UserError.html) - User-facing error class
-- [`ActorError`](/typedoc/classes/rivetkit.client_mod.ActorError.html) - Errors received by the client
-
diff --git a/vendor/actors/docs/content/docs/events.mdx b/vendor/actors/docs/content/docs/events.mdx
@@ -152,13 +152,3 @@ function ConditionalListener() {
 ## More About Connections
 
 For more details on actor connections, including connection lifecycle, authentication, and advanced connection patterns, see the [Connections documentation](/actors/docs/connections).
-
-## API Reference
-
-- [`RivetEvent`](/typedoc/interfaces/rivetkit.mod.RivetEvent.html) - Base event interface
-- [`RivetMessageEvent`](/typedoc/interfaces/rivetkit.mod.RivetMessageEvent.html) - Message event type
-- [`RivetCloseEvent`](/typedoc/interfaces/rivetkit.mod.RivetCloseEvent.html) - Close event type
-- [`UniversalEvent`](/typedoc/interfaces/rivetkit.mod.UniversalEvent.html) - Universal event type
-- [`UniversalMessageEvent`](/typedoc/interfaces/rivetkit.mod.UniversalMessageEvent.html) - Universal message event
-- [`UniversalErrorEvent`](/typedoc/interfaces/rivetkit.mod.UniversalErrorEvent.html) - Universal error event
-- [`EventUnsubscribe`](/typedoc/types/rivetkit.client_mod.EventUnsubscribe.html) - Unsubscribe function type
diff --git a/vendor/actors/docs/content/docs/general/docs-for-llms.mdx b/vendor/actors/docs/content/docs/general/docs-for-llms.mdx
diff --git a/vendor/actors/docs/content/docs/general/edge.mdx b/vendor/actors/docs/content/docs/general/edge.mdx
@@ -1,26 +1,37 @@
 ---
-title: "Edge Networking"
-description: "Actors automatically run near your users on your provider's global network."
+title: "Regions & Multi-Region"
+description: "Actors run near your users, in a region you can choose."
 skill: true
 ---
 
-<Note>
-	At the moment, edge networking is only supported on Rivet Cloud & Cloudflare Workers. More self-hosted platforms are on the roadmap.
-</Note>
+An actor lives in one region. Which region it lands in, and how a client reaches it, is the same model whether you run on Rivet Cloud or your own multi-region deployment.
 
 ## Region selection
 
-### Automatic region selection
-
-By default, actors will choose the nearest region based on the client's location.
+### Automatic
 
-Under the hood, Rivet and Cloudflare use [Anycast routing](https://en.wikipedia.org/wiki/Anycast) to automatically find the best location for the client to connect to without relying on a slow manual pinging process.
+By default, an actor is created in the region nearest the client. Rivet uses [Anycast routing](https://en.wikipedia.org/wiki/Anycast) to find the closest point of presence without a slow manual pinging round.
 
-### Manual region selection
+### Manual
 
-The region an actor is created in can be overridden using region options:
+Override the region with region options at create time:
 
 <CodeSnippet file="examples/docs/general-edge/client.ts" title="client.ts" />
 
-See [Create  Manage Actors](/actors/docs/communicating-between-actors) for more information.
+See [Actor-Actor Communication](/actors/docs/communicating-between-actors) for the full set of create options.
+
+## Where the actor stays
+
+An actor does not migrate between regions. It is created in one region and stays there for its lifetime, so its state is always local to the compute running it. That locality is the point: reads and writes never cross a region boundary.
+
+Communication between actors in different regions goes over the network, so treat a cross-region actor call the same way you would treat any other remote call.
+
+## Multi-region when self-hosting
+
+<Note>
+Edge networking with automatic region selection is available on Rivet Cloud and Cloudflare Workers. Self-hosted deployments can run multiple regions, but you configure the topology and hostnames yourself.
+</Note>
+
+A self-hosted multi-region deployment runs a control plane in each region, all sharing one database and pub/sub layer, with each region reachable at its own hostname. See [Multi-Region](/actors/self-host/control-plane/multi-region) in the self-host docs for the topology configuration.
 
+The rule that matters most: each region needs its **own** hostname. Pointing a shared, load-balanced origin at several regions makes it impossible to address a specific one.
diff --git a/vendor/actors/docs/content/docs/input.mdx b/vendor/actors/docs/content/docs/input.mdx
@@ -52,9 +52,3 @@ Define input types to ensure type safety:
 Input is only available in `createState` and `onCreate` lifecycle hooks. If you need to access input data later (in actions, timers, or other hooks), store it in the actor's state during creation. This is the recommended pattern because input shapes can evolve over time, and persisting input in state ensures you always have access to the values the actor was created with:
 
 <CodeSnippet file="examples/docs/actors-input/store-input-in-state.ts" />
-
-## API Reference
-
-- [`CreateOptions`](/typedoc/interfaces/rivetkit.client_mod.CreateOptions.html) - Options for creating actors
-- [`CreateRequest`](/typedoc/types/rivetkit.client_mod.CreateRequest.html) - Request type for creation
-- [`ActorDefinition`](/typedoc/classes/rivetkit.mod.ActorDefinition.html) - Actor definition returned by `actor()`
diff --git a/vendor/actors/docs/content/docs/keys.mdx b/vendor/actors/docs/content/docs/keys.mdx
@@ -67,11 +67,3 @@ Use keys to provide basic actor configuration:
 For more complex configuration, use [input parameters](/actors/docs/input):
 
 <CodeSnippet file="examples/docs/actors-keys/complex-config.ts" title="client.ts" />
-
-## API Reference
-
-- [`ActorKey`](/typedoc/types/rivetkit.mod.ActorKey.html) - Key type for actors
-- [`ActorQuery`](/typedoc/types/rivetkit.mod.ActorQuery.html) - Query type using keys
-- [`GetOptions`](/typedoc/interfaces/rivetkit.client_mod.GetOptions.html) - Options for getting by key
-- [`QueryOptions`](/typedoc/interfaces/rivetkit.client_mod.QueryOptions.html) - Options for querying
-