Rift

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.

Rivet Actors

Youlaptop
work
api
billing
runs
.env
Rivet Cloud
It can read your files.

Each actor's state and database. You can host this part yourself. Rivet's agentOS adds a filesystem to an actor, which this page does not cover.

one actor
OpenClawOpenClawanother company's agent
holds a token your backend issued

Rift

Youlaptop
work
api
billing
runs
.env
Rift Cloud
It cannot read your files. It holds only ciphertext.
Fv+a8LdicjU6ce
efFPD/W3GEGTbB
FFu91EY6OfuOIc
j3iz+iV3W5kvab
1hZDb7nJAxjHmy
one folder, read
OpenClawOpenClawanother company's agent
holds its own key
apiread

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.

Rivet ActorsRift
IdentityRivet ActorsA token for one Rivet namespace, or a short-lived token your backend issues for one actor.RiftA key that each machine and agent makes for itself. No account.
Smallest shareRivet ActorsOne actor, through a token limited to it. What the caller may do inside the actor is decided by your code.RiftA folder, a subfolder or one file, as read or write.
Who checks accessRivet ActorsThe Rivet control plane checks the token. Your actor code checks the caller after that.RiftEach machine that receives a file checks the grant itself.
Who can read your filesRivet ActorsRivet, on Rivet Cloud, which stores actor state. You, when you host the control plane. We found no documented option for customer-held keys.RiftOnly the machines you shared with. Rift Cloud holds ciphertext.
When your machines are offRivet ActorsState stays in the control plane. Actors run only where a worker is up, which can be Rivet's own compute.RiftFiles stored in Rift Cloud stay available.
When a run endsRivet ActorsAn idle actor sleeps and wakes later with its state intact. Destroying it deletes the state.RiftFiles 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

Based on Rivet's documentation, pricing page and privacy policy, read in October 2026. Sources: Actors overview, architecture, state, authentication, tokens, permissions, destroying actors, pricing, privacy policy.

View as Markdown