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
  React
  Node.js & Bun
  Rust
Start With Studio
  Open Studio
Start With Template
npx create-actor@latest  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.
| Example | Actor (JavaScript) | Actor (SQLite) | Frontend (React) |
|---|---|---|---|
| Chat Room | actor.ts | actor.ts | App.tsx |
| AI Agent | actor.ts | actor.ts | App.tsx |
| Local-First Sync | actor.ts | actor.ts | App.tsx |
| Per-Tenant SaaS | actor.ts | actor.ts | App.tsx |
| Per-User Databases | actor.ts | actor.ts | App.tsx |
| Yjs CRDT | actor.ts | actor.ts | App.tsx |
| Collaborative Document | actor.ts | actor.ts | App.tsx |
| Stream Processing | actor.ts | actor.ts | App.tsx |
| Multiplayer Game | actor.ts | actor.ts | App.tsx |
| Rate Limiter | actor.ts | actor.ts | App.tsx |
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.
  Rivet
  Cloudflare Workers
  Vercel (On The Roadmap)
  AWS Lambda (On The Roadmap)
  Supabase (Help Wanted)
  Bun
  Node.js
  Redis
  Postgres (Help Wanted)
  File System
  Memory
Seamlessly integrate ActorCore with your favorite frameworks, languages, and tools. Don't see what you need? Request an integration.
  TypeScript
  Python (Available In April)
  Hono
  Vitest
  Resend
  Better Auth (On The Roadmap)
  LiveStore (Available In May)
  ZeroSync (Help Wanted)
  TinyBase (Help Wanted)
  Yjs (Help Wanted)
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.
- SQLite Support
- SQLite in Studio
- Local-First Extensions
- Auth Extensions
- Workflows
- Queues
- MCP
- Actor-Actor Actions
- Cancellable Schedules
- Cron Jobs
- Drizzle Support
- Prisma v7 Support
- Read Replicas
- Middleware
- Schema Validation
- Vite Integration
- OpenTelemetry
- More Examples
- Studio
- File system driver
- Redis driver
- Bun support
- P2P topology
- React client
- Rust client
- Resend Integration
- Vitest Integration
- Non-serialized state
-
create-actor -
actor-core dev - Hono Integration
Apache 2.0
Scale without drama – only with ActorCore.