Long-running functions with persistence, real-time communication, and hibernation
Actors are lightweight, stateful serverless functions that maintain persistent state and provide real-time communication. They’re the core building blocks of RivetKit applications.
Set up actors with Node.js, Bun, and web frameworks
Build real-time React applications with actors
Each unit of compute is like a tiny server that remembers things between requests – no need to reload data or worry about timeouts. Like AWS Lambda, but with memory and no timeouts.
State is stored on the same machine as your compute, so reads and writes are ultra-fast. No database round trips, no latency spikes.
Update state and broadcast changes in realtime with WebSockets or SSE. No external pub/sub systems, no polling – just built-in low-latency events.
Your state lives close to your users on the edge – not in a faraway data center – so every interaction feels instant.
Actors are perfect for applications that need persistent state and real-time updates:
Actors maintain persistent state that survives restarts, crashes, and deployments. State can be defined as a constant or created dynamically:
Learn more about state management.
Actions are the primary way to interact with actors. They’re type-safe functions that can modify state and communicate with clients:
Actions can be called from your backend, your clients, or other actors:
Learn more about actions and communicating with actors.
Actors support real-time bidirectional communication through WebSocket and SSE connections. Clients can establish persistent connections to receive live updates.
For example, to send events to all connected clients:
Clients connect and listen for real-time updates:
Learn more about events and client communication.
Actors support scheduled tasks and lifecycle management:
Learn more about actor lifecycle.
RivetKit provides end-to-end TypeScript safety between clients and actors:
How is RivetKit different than Rivet Actors?
RivetKit is a framework written in TypeScript that provides high-level functionality. Rivet is an open-source serverless platform written in Rust with features tailored for stateful serverless.
You can think of it as RivetKit is to Rivet as Next.js is to Vercel.
While Rivet is the primary maintainer of RivetKit, we intend for this to be community driven.
How does stateful serverless compare to the traditional actor model?
Stateful serverless is very similar to actors: it’s essentially actors with persistence, and usually doesn’t have as rigid constraints on message handling. This makes it more flexible while maintaining the core benefits of the actor model.
How do stateful and stateless serverless work together?
Stateless serverless works well when you have an external resource that maintains state. Stateful serverless, on the other hand, is almost like a mini-database.
Sometimes it makes sense to use stateless serverless to make requests to multiple stateful serverless instances, orchestrating complex operations across multiple state boundaries.
How does RivetKit achieve huge performance gains?
By storing state in memory and flushing to a persistence layer, we can serve requests instantly instead of waiting for a round trip to the database. There are additional optimizations that can be made around your state to tune the durability of it.
Additionally, data is stored near your users at the edge, ensuring round-trip times of less than 50ms when they request it. This edge-first approach eliminates the latency typically associated with centralized databases.
Isn't well-designed software supposed to separate compute and storage?
Some software makes sense to separate – e.g., for data lakes or highly relational data. But at the end of the day, data has to be partitioned somewhere at some point.
Usually “faster” databases like Cassandra, DynamoDB, or Vitess make consistency tradeoffs to get better performance. Stateful serverless forces you to think about how your data is sharded for better performance, better scalability, and less consistency footguns.
What is stateful serverless not good for?
OLAP, data lakes, graph databases, and highly relational data are currently not ideal use cases for stateful serverless, though it will get better at handling these use cases over time.
Can this create a single bottleneck?
Yes, but only as much as storing data in a single database row does. We’re working on building out read replicas to allow you to perform read-only actions on actors.