Show HN: ActorCore – Stateful serverless framework that runs anywhere
github.comHey HN! Today we're launching ActorCore (https://actorcore.org/), a stateful serverless framework that enables deploying Cloudflare Durable Object-like workloads to any cloud.
If you're unfamiliar with stateful serverless: it's like the actor model, where each actor maintains its own isolated, persistent state. (Think Lambda functions with local storage & runs indefinitely.) It enables easily building long-running, realtime, durable, or local-first backends with the flexibility of serverless infrastructure. The most widely used implementation is Cloudflare Durable Objects, powering products like Clerk, Tldraw, Liveblocks, and Playroom.
A few months ago we launched Rivet Actors (https://news.ycombinator.com/item?id=42472519) as an open-source alternative to Cloudflare Durable Objects. After that launch, we kept hearing three common concerns:
- Vendor lock-in: Developers are hesitant to adopt a new programming model if there's no clear off-ramp. While it's straightforward to migrate a Postgres database, stateful serverless platforms can feel locked-in due to lack of viable alternatives.
- Ecosystem: Choosing a well-known database like Postgres comes with a mature ecosystem. Adopting a new model means rebuilding tooling and patterns from scratch.
- Conceptual gap: Many developers have spent their entire careers designing systems with intentionally separated state and compute. A model that merges the two can feel backwards at first.
We realized the best solution was to build a stateful serverless framework that can (a) be portable across clouds and (b) be easily extended – similar to how Hono created a unified API for traditional serverless functions across different providers. Thus, ActorCore was born.
Today, ActorCore supports running stateful serverless on Rivet Actors, Cloudflare Durable Objects, Redis, and standalone Node.js/Bun. The most common use cases include applications using collaborative, AI agent, local-first, and per-tenant database features.
State in ActorCore is an in-memory JavaScript object, with SQLite support coming later this month. State is stored in memory near your users on the edge, removing database round trips and minimizing latency due to physical distance. Additionally, state writes have tunable consistency, which enables both fully durable compute workloads and high-frequency state updates.
You may have noticed that this still leaves concern #3: the conceptual gap. While this isn't something we can solve with a framework, I've been spending ~40% of my time working on docs, content, and examples to help resolve this. ActorCore is also turning out to be community-driven as hoped, which enables more people to try and share their experience with stateful serverless.
We'd love it if you'd give ActorCore a try, read the roadmap, and/or let us know where we can improve anything. If you're hesitant about trying stateful serverless, I'd love to learn more in the comments. Looking forward to feedback!
Hey Nathan, cool project and thanks for sharing.
I've tinkered with Actor Core a bit but need to play with it more.
How would you compare/sell it to someone who uses or is familiar with https://partykit.io/
Appreciate the kind words!
I see ActorCore as picking up on PartyKits vision where they left off after acquisition by Cloudflare. Here's a few of the few things we've added to ActorCore:
- Full TypeScript type safety for calling actions on actors – PartyKit provides raw WebSocket messages instead
- Streamlined state persistence – PartyKit requires using low-level storage calls for persistence
- Flexible scheduling API – PartyKit exposes the single alarm from Cloudflare instead
- Simpler "functional" API – you might prefer PartyKit if you prefer using ES6 classes
- Upcoming SQLite features & deep integrations for features like auth & local-first sync will make it easier to ship quickly
- Not vendor-locked to Cloudflare
PartyKit already has a few integrations that is on our roadmap, such as Yjs
Curious to hear your experience using both.
https://rivet.gg/docs/general
That link appears broken.
I don't quite get the concept yet. The details are kinda slim.
> I don't quite get the concept yet. The details are kinda slim.
Would be helpful to learn more. From looking at one of the examples, can you elaborate a bit on what doesn't make sense? Or is this more broadly how it works architecturally?
> That link appears broken.
Looks like we had a broken link in the mobile nav – is that where you found it?
Mobile, yes.
Perhaps a use case?
To say it's like another service requires me to know the alternative and now your completion is known as well.
I'm also curious how the service handles multiple requests to the same state.
Does this example list help? https://github.com/rivet-gg/actor-core?tab=readme-ov-file#ex...
> I'm also curious how the service handles multiple requests to the same state.
That's the key part of ActorCore – state is persisted across requests. It's like a Lambda function that can (a) run forever and (b) persist state.
Congrats on the launch! Glad someone is building this.
Thanks Paul
ActorCore is awesome. Stateful Serverless is the future!
Thank you!
I've wanted something like this for a long time, going to take it for a spin. Looks like there is a lot of help wanted on certain underlying implementations so that would be fun to help out with too.
I think there is tremendous value in having these functions that appear stateless and run in "stateless" environments like aws lambda, but on each invocation they are handed the previous state and are able to augment it and return (to persist) or do nothing.
Very erlang-y, which is rad.
Appreciate the kind words!
There’s definitely a lot of inspiration from Erlang. We’re far from the first actor-ish framework, but we’re hoping ActorCore sticks by working seamlessly with existing tools, instead of forcing people to learn a new paradigm.
We’re open to contributions – feel free to join our Discord if you have questions.
[dead]
[dead]
[dead]