npx skills add ...
npx skills add rivet-dev/skills --skill rivetkit
npx skills add rivet-dev/skills --skill rivetkit
RivetKit backend and Rivet Actor runtime guidance. Use for building, modifying, debugging, or testing Rivet Actors, registries, serverless/runner modes, deployment, or actor-based workflows.
Build high-performance, long-lived, in-memory processes on Rivet's actor runtime. Use this skill whenever HTTP endpoints, databases, or queues no longer meet the requirements for AI agents, realtime collaboration, workflow orchestration, or geo-distributed data.
If something is not working as intended or you are stuck, prompt the user to join the Rivet Discord or file an issue on the Rivet GitHub to report an issue and get help.
Provide the user with a pre-generated report with:
Use the inspector HTTP API to examine running actors. These endpoints are accessible through the gateway at /gateway/{actor_id}/inspector/*. Key endpoints:
GET /inspector/summary - full actor snapshot (state, connections, RPCs, queue)GET /inspector/state / PATCH /inspector/state - read/write actor stateGET /inspector/connections - active connectionsGET /inspector/rpcs - available actionsPOST /inspector/action/{name} - execute an action with {"args": [...]}POST /inspector/database/execute - run SQL with {"sql": "...", "args": [...]} or {"sql": "...", "properties": {...}} for reads or mutationsGET /inspector/queue?limit=50 - queue statusGET /inspector/traces?startMs=0&endMs=...&limit=1000 - trace spans (OTLP JSON)GET /inspector/workflow-history - workflow history and status as JSON (nameRegistry, entries, entryMetadata)POST /inspector/workflow/replay - replay a workflow from a specific step or from the beginning; returns 409 actor/workflow_in_flight if the workflow is still runningGET /inspector/database/schema - SQLite tables and views exposed by c.dbGET /inspector/database/rows?table=...&limit=100&offset=0 - paged SQLite rows for a table or viewIn local dev, no auth token is needed. In production, pass Authorization: Bearer <inspector-token>, where the inspector token is the actor-specific token auto-generated on first start and persisted in the actor's internal KV at key 0x03. The Rivet dashboard retrieves this token automatically; for direct API access, fetch it through the management KV endpoint. See the debugging docs for details.
When providing information from Rivet documentation, cite the canonical URL so users can learn more. Each reference file includes its canonical URL in the header metadata.
How to cite:
Finding canonical URLs:
The Reference Map below links to reference files. Each file's header contains:
Use that canonical URL when citing, not the reference file path.
Examples:
https://rivet.dev/docs/actors/actionshttps://rivet.dev/docs/clients/reacthttps://rivet.dev/docs/self-hosting/kubernetesBefore starting any work, check if the user's project is on the latest version of RivetKit (latest: 2.3.7). Look at the rivetkit version in the user's package.json (check both dependencies and devDependencies). If the installed version is older than 2.3.7, inform the user and suggest upgrading:
If the user also uses @rivetkit/react, @rivetkit/next-js, or other @rivetkit/* client packages, suggest upgrading those too. Outdated versions may have known bugs or missing features that cause issues.
setup({ use: { /* actors */ } }).registry.start() to start the server. For custom HTTP server integration, use registry.handler() with a router like Hono. For serverless deployments, use registry.serve(). For runner-only mode, use registry.startEnvoy()./api/rivet/metadata returns 200 before deploying.For more information, read the quickstart guide relevant to the user's project.
Every RivetKit project should have a .gitignore. Include at minimum:
Every project with a Dockerfile should have a .dockerignore to keep the image small and avoid leaking secrets:
Use this as a base Dockerfile for deploying a RivetKit project. The RIVET_RUNNER_VERSION build arg is only needed when self-hosting or using a custom runner (not needed for Rivet Compute). It lets Rivet track which version of the actor is running and drain old actors on deploy. See https://rivet.dev/docs/actors/versions for details.
Build with:
Adjust the CMD to match the project's entry point. If the project uses a different output directory or start command, update accordingly.
try/catch unless it is required for a real recovery path, cleanup boundary, or to add actionable context.catch, you must handle the error explicitly, at minimum by logging it.c.vars is ephemeral. Data in c.vars is lost on every restart, crash, upgrade, or sleep/wake cycle. Only use c.vars for non-serializable objects (e.g., physics engines, WebSocket references, event emitters, caches) or truly transient runtime data (e.g., current input direction that doesn't matter after disconnect).
Persistent storage options. Any data that must survive restarts belongs in one of these, NOT in c.vars:
c.state — CBOR-serializable data for small, bounded datasets. Ideal for configuration, counters, small player lists, phase flags, etc. Keep under 128 KB. Do not store unbounded or growing data here (e.g., chat logs, event histories, spawned entity lists that grow without limit). State is read/written as a single blob on every persistence cycle.c.kv — Key-value store for unbounded data. This is what c.state uses under the hood. Supports binary values. Use for larger or variable-size data like user inventories, world chunks, file blobs, or any collection that may grow over time. Keys are scoped to the actor instance.c.db — SQLite database for structured or complex data. Use when you need queries, indexes, joins, aggregations, or relational modeling. Ideal for leaderboards, match histories, player pools, or any data that benefits from SQL.Common mistake: Storing meaningful game/application data in c.vars instead of persisting it. For example, if users can spawn objects in a physics simulation, the spawn definitions (position, size, type) must be persisted in c.state (or c.kv if unbounded), even though the physics engine handles (non-serializable) live in c.vars. On restart, run() should recreate the runtime objects from the persisted data.
Assume the user is deploying to Rivet Cloud, unless otherwise specified. If user is self-hosting, read the self-hosting guides below.
The RivetKit OpenAPI specification is available in the skill directory at openapi.json. This file documents all HTTP endpoints for managing actors.
c.client<typeof registry>().c.state becoming unknown, actor methods becoming possibly undefined, or TS2322 / TS2722 errors after the first cross-actor call.c.client<typeof registry>().unknown for the registry type and be explicit that this gives up type safety at that call site.index.ts
Use the client SDK that matches your app:
Persistent data that survives restarts, crashes, and deployments. State is persisted on Rivet Cloud or Rivet self-hosted, so it survives restarts if the current process crashes or exits.
Keys uniquely identify actor instances. Use compound keys (arrays) for hierarchical addressing:
Don't build keys with string interpolation like "org:${userId}" when userId contains user data. Use arrays instead to prevent key injection attacks.
Pass initialization data when creating actors. Input is only available in createState and onCreate, so store it in state if you need it later.
Temporary data that doesn't survive restarts. Use for non-serializable objects (event emitters, connections, etc).
Actions are the primary way clients and other actors communicate with an actor.
Actions can be nested to group related behavior. For example, handle.users.add("Ada") calls the low-level action name users.add.
Events enable real-time communication from actors to connected clients.
Access the current connection via c.conn or all connected clients via c.conns. Use c.conn.id or c.conn.state to securely identify who is calling an action. c.conn is only available for actions invoked through a connected client; stateless actor-handle calls run without a connection, so guard against that. Connection state is initialized via connState or createConnState, which receives parameters passed by the client on connect.
Use queues to process durable messages in order inside a run loop.
Use workflows when your run logic needs durable, replayable multi-step execution.
Actors can call other actors using c.client().
Run one-shot actions after a delay or at a specific time. Use named cron jobs for calendar schedules and fixed intervals. Both persist across sleep, restarts, upgrades, and crashes.
Permanently delete an actor and its state using c.destroy().
Actors support hooks for initialization, background processing, connections, networking, and state changes. Use run for long-lived background loops, and use c.aborted or c.abortSignal for graceful shutdown.
When writing helper functions outside the actor definition, use *ContextOf<typeof myActor> to extract the correct context type. Helpers like ActionContextOf, CreateContextOf, ConnContextOf, and ConnInitContextOf are exported from "rivetkit". Do not manually define your own context interface. Always derive it from the actor definition.
Use UserError to throw errors that are safely returned to clients. Pass metadata to include structured data. Other errors are converted to generic "internal error" for security.
For custom protocols or integrating libraries that need direct access to HTTP Request/Response or WebSocket connections, use onRequest and onWebSocket.
HTTP Handler Documentation · WebSocket Handler Documentation
Customize how actors appear in the UI with display names and icons. It's recommended to always provide a name and icon to actors in order to make them easier to distinguish in the dashboard.
Find the full client guides here:
Actors scale naturally through isolated state and message-passing. Structure your applications with these patterns:
Create one actor per user, document, or room. Use compound keys to scope entities:
Data actors handle core logic (chat rooms, game sessions, user data). Coordinator actors track and manage collections of data actors—think of them as an index.
Use a run loop for continuous background work inside an actor. Process queue messages in order, run logic on intervals, stream AI responses, or coordinate long-running tasks.
Use this pattern for long-lived, durable workflows that initialize resources, process commands in a loop, then clean up.
onBeforeConnect or createConnState and throw an error to reject unauthorized connections.c.conn.state to securely identify users in actions rather than trusting action parameters.onBeforeConnect.Authentication Documentation · CORS Documentation
When deploying new code, set a version number so Rivet can route new actors to the latest runner and optionally drain old ones. Use a build timestamp, git commit count, or CI build number as the version. It is very important to configure versioning before deploying to production. Without versioning, actors can regress by running on older runner versions, and existing actors will never be forced to migrate to new runners. They will continue running indefinitely on the old runners until they exit.
Do not put all your logic in a single actor. A god actor serializes every operation through one bottleneck, kills parallelism, and makes the entire system fail as a unit. Split into focused actors per entity.
Actors are long-lived and maintain state across requests. Creating a new actor for every incoming request throws away the core benefit of the model and wastes resources on actor creation and teardown. Use actors for persistent entities and regular functions for stateless work.