> Documentation index: https://rift.sh/llms.txt

# Rift vs Rivet Actors

A Rivet Actor is a long-lived process that keeps one agent's state, queue and connections. Rift syncs the files an agent writes to every machine that was given access.

### What Rivet Actors is

A Rivet Actor is a long-lived process with durable state, a message queue, realtime connections and scheduling, addressed by a key. The usual design is one actor per agent, session, user or chat room. An actor sleeps when idle and wakes on the next request with its state intact, and it can have its own SQLite database. Your code runs in worker processes that you operate or that Rivet runs for you, and a control plane schedules actors, routes requests to them and stores their state. The control plane is open source and can be self-hosted, and Rivet Cloud is the managed version.

### How they differ

An actor's state lives in the control plane's storage and is reached by calling the actor over HTTP or WebSocket, so nothing is copied to the caller's disk. On Rivet Cloud that storage is Rivet's. Rift keeps ordinary files on each machine's disk and shares a folder with a key that the other machine holds.

- Identity
  - Rivet Actors: A token for one Rivet namespace, or a short-lived token your backend issues for one actor.
  - Rift: A key that each machine and agent makes for itself. No account.

- Smallest share
  - Rivet Actors: One actor, through a token limited to it. What the caller may do inside the actor is decided by your code.
  - Rift: A folder, a subfolder or one file, as read or write.

- Who checks access
  - Rivet Actors: The Rivet control plane checks the token. Your actor code checks the caller after that.
  - Rift: Each machine that receives a file checks the grant itself.

- Who can read your files
  - Rivet Actors: Rivet, on Rivet Cloud, which stores actor state. You, when you host the control plane. We found no documented option for customer-held keys.
  - Rift: Only the machines you shared with. Rift Cloud holds ciphertext.

- When your machines are off
  - Rivet Actors: State stays in the control plane. Actors run only where a worker is up, which can be Rivet's own compute.
  - Rift: Files stored in Rift Cloud stay available.

- When a run ends
  - Rivet Actors: An idle actor sleeps and wakes later with its state intact. Destroying it deletes the state.
  - Rift: Files the run wrote to a Rift folder are already on your other machines.

### Which to choose

Choose Rivet Actors when

- Each agent, session or room needs its own live process with state that survives restarts.
- Clients need realtime events over WebSockets.
- You want the option to run the whole stack on your own servers.

Choose Rift when

- The state is files that people and other tools open directly.
- Another company's agent needs some of the files.
- A cloud should store the data and be unable to read it.

### Using them together

A Rivet Actor can hold an agent's session state and schedule, and a Rift folder can hold the files it writes, on a worker that runs as a long-lived process on a machine you operate.

[Use Rift with Rivet Actors](https://rift.sh/docs/use-with/rivet-actors.md)

Based on Rivet's documentation, pricing page and privacy policy, read in October 2026. Sources: [Actors overview](https://rivet.dev/actors/docs.md) , [architecture](https://rivet.dev/docs/architecture.md) , [state](https://rivet.dev/actors/docs/state.md) , [authentication](https://rivet.dev/docs/authentication.md) , [tokens](https://rivet.dev/docs/jwt.md) , [permissions](https://rivet.dev/actors/docs/permissions.md) , [destroying actors](https://rivet.dev/actors/docs/destroy.md) , [pricing](https://rivet.dev/pricing/) , [privacy policy](https://rivet.dev/privacy/).