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.
[dead]
[dead]
[dead]