The easiest way to build stateful, AI agent, collaborative, or local-first applications.
Deploy to Rivet, Cloudflare, Bun, Node.js, and more.
Documentation • Discord • X • Bluesky
Start By Framework
Start With Studio
Start With Template
Long-Lived, Stateful Compute
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.
Durable State Without a Database
Your code's state is saved automatically—no database, ORM, or config needed. Just use regular JavaScript objects or SQLite (available in April).
Blazing-Fast Reads & Writes
State is stored on the same machine as your compute, so reads and writes are ultra-fast. No database round trips, no latency spikes.
Realtime, Made Simple
Update state and broadcast changes in realtime. No external pub/sub systems, no polling – just built-in low-latency events.
Store Data Near Your Users
Your state lives close to your users on the edge – not in a faraway data center – so every interaction feels instant.
Serverless & Scalable
No servers to manage. Your code runs on-demand and scales automatically with usage.
Have more questions? Jump to our FAQ →
Browse snippets for how to use ActorCore with different use cases.
SQLite will be available in late April. We’re working on publishing full examples related to these snippets. If you find an error, please create an issue.
Deploy ActorCore anywhere - from serverless platforms to your own infrastructure. Don't see the runtime you want? Add your own.
Seamlessly integrate ActorCore with your favorite frameworks, languages, and tools. Don't see what you need? Request an integration.
Like Postman, but for all of your stateful serverless needs.
Help make ActorCore the universal way to build & scale stateful serverless applications.
How is ActorCore different than Rivet Actors?
ActorCore 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 ActorCore is to Rivet as Next.js is to Vercel.
While Rivet is the primary maintainer of ActorCore, 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 ActorCore 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.
Stateless serverless is standardized under WinterTC. Is there any intention to standardize stateful serverless?
Things are cooking! Check out our blog post about what a W3C standard for stateful serverless might look like and the awesome people who are collaborating on this.
Have more questions? Join our Discord or go to GitHub Discussions.
We ship fast, so we want to share what you can expect to see before the end of the year. Help shape our roadmap by creating issues and joining our Discord.
Apache 2.0
Scale without drama – only with ActorCore.