HN user
Building open-source actor library, a serverless primitive for stateful workloads.
https://rivet.dev
WASM- & V8 isolate-based operating system that's (almost) POSIX-compliant, including its own network stack, VFS, process tree, etc.
Allows you to compile most C or Rust programs to run in it without modification. Also can run Claude Code, Codex, Pi, and OpenCode unmodified.
Working on polishing, security, and documentation so I can share an in-depth deep dive on HN.
Cheers!
Yep, everyone seems to reinventing the actor model from first principles right now.
We're taking a different approach of building the best actor primitive for mainstream languages and letting people build a thin AI layer on top. We did not set out out build for AI when we started it, it was a happy accident.
Thanks! Any questions in particular on the comparison?
Cheers!
Hey! This is a common question.
In our experience, most apps don't need cross-tenant queries outside of BI. For example, think about the apps you use on a daily basis: Linear, Slack, ChatGPT all fit well with an actor-per-workspace or actor-per-thread model.
To be clear, we're not trying to replace Postgres. We're focused on modern workloads like AI, realtime, and SaaS apps where per-tenant & per-agent databases are a natural fit.
Using SQLite for your per-tenant or per-agent databases has a lot of benefits:
- Compute + state: running the SQLite database embedded in the actor has performance benefits
- Security: solutions like RLS are a security nightmare, much easier to have peace of mind with full DB isolation per tenant
- Per-tenant isolation: important for SaaS platforms, better for security & performance
- Noisy neighbors: limits the blast radius of a noisy neighbor or bad query to a single tenant's database
- Enables different schemas for every tenant
- AI-generated backends: modern use cases often require AI-generated apps to have their own custom databases; this model makes that easy
A few other points of reference in the space:
- Cloudflare Durable Objects & Agents are built on this model, and much of Cloudflare's internal architecture is built on DO
- https://neon.com/use-cases/database-per-tenant
- https://turso.tech/multi-tenancy
- Val.town & Replit
Better usage of resources
I'd be curious to hear more about what you mean by this.
always allows a parent style agent do complex queries
Do you have a specific use case in mind where agents need to query other agents' data?
We built everything with this architecture internally already at Rivet. It's less common than you might expect to have to query cross-DB in practice.
However, we are planning on building a query engine that can operate over multiple databases. One option we're considering is exposing Rivet SQLite as a DuckDB datasource: https://duckdb.org/docs/stable/data/data_sources
What does this mean for Bun (recently acquired by Anthropic)?
OpenCode supports:
- TUI (I prefer this for most programming)
- Web UI (negligible difference than VS Code)
- Mobile support (via web UI)
- TypeScript SDK to automate
Been using it for a bit now, it's very convenient if I may say so myself. We're shipping a big stability update in a few minutes – would love feedback!
Thanks!
Yes. We want to support ACP. They have a spec for HTTP transport in the works, but there is nothing public on it. Trying to backchannel to the right folks.
Hit the nail on the head.
(Sprites.dev in the works already.)
Thank you!
Posted this morning an overview of the project: https://x.com/NathanFlurry/status/2018366627021291699
That's correct.
As you said – in terms of project goals, the biggest difference is:
- ACP seems to be focused on providing a universal API for the subset of features required for editors
- Sandbox Agent SDK is focused on automating agents, so aims to provide a much more comprehensive API coverage for niche agent-specific features
We maintain a feature coverage matrix (https://sandboxagent.dev/docs/session-transcript-schema#cove...) – it's early, much more coming soon.
Love it
Hacked together an SF parks ranking system based on current weather
We’re doing this on https://rivet.dev now. I did not realize how much context bloat we had since we were using Tailwind.
I’ve been building an open-source alternative at https://github.com/rivet-dev-engine
It’s the only bit of the Cloudflare stack (afaik) that did not have an open-source alternative for the JS ecosystem. I built heavily with DO on another OSS project, but realized it was incredibly problematic that our customers couldn’t truly self-host.
A 1 CPU + 2 GB of RAM + 50 GB ephemeral storage on Cloudflare Containers is $74.90.
The same on Fly Machines is $31.00 (performance-1x, varies by region). Fly Machines has the same sleeping functionality as Cloudflare.
Rivet Containers also has a similar price point of $29.40, but takes a different approach to sleeping (opts for optimizing coldstarts + autoscaling over snapshotting). (I work at Rivet)
They stated on the livestream they're considering TCP, but I suspect UDP is not coming soon since Workers themselves don't support UDP. All traffic going to Cloudflare Containers must be "proxied" through the Workers platform.
We published an in-depth comparison between Cloudflare Containers, Fly Machines, and Rivet Containers: https://rivet.gg/blog/2025-06-24-cloudflare-containers-vs-ri...
(I work at Rivet)
Our self-hosting docs are very rough right now – I'm fully aware of the irony given my comment. It's on our roadmap to get them up to snuff within the next few weeks.
If you're curious on the details, we've put a lot of work to make sure that there's as few moving parts as possible:
We have our own cloud VM-level autoscaler that's integrated with the core Rivet platofrm – no k8s or other orchestrators in between. You can see the meat of it here: https://github.com/rivet-gg/rivet/blob/335088d0e7b38be5d029d...
For example, Rivet has an API to dynamically spin up a cluster on demand: https://github.com/rivet-gg/rivet/blob/335088d0e7b38be5d029d...
Once you start the Rivet "seed" process with your API key, everything from there is automatic.
Therefore, self-hosted deployments usually look like one of:
- Plugging in your cloud API token in to Rivet for autoscaling (recommended)
- Fixed # of servers (hobbyist deployments that were manually set up, simple Terraform deployments, or bare metal)
- Running within Kubernetes (usually because it depends on existing services)
I hope this isn't the case here with Rivet. I genuinely believe that Kubernetes does a good job for what's on the tin (i.e. container orchestration at scale), but there's an evolution that needs to happen.
If you'll entertain my argument for a second:
The job of someone designing systems like this is to decide what are the correct primitives and invest in building a simple + flexible platform around those.
The original cloud primitives were VMs, block devices, LBs, and VPCs.
Kubernetes became popular because it standardized primitives (pods, PVCs, services, RBAC) that containerized applications needed.
Rivet's taking a different approach of investing in different three primitives based on how most organizations deploy their applications today:
- Stateless Functions (a la Fluid Compute)
- Stateful Workers (a la Cloudflare Durable Objects)
- Containers (a la Fly.io)
I fully expect to raise a few hackles claiming these are the "new primitives" for modern applications, but our experience shows it's solving real problems for real applications today.
Edit: Clarified "original cloud primitives"
The #1 problem with Kubernetes is it's not something that "Just Works." There's a very small subset of engineers who can stand up services on Kubernetes without having it fall over in production – not to mention actually running & maintaining a Kubernetes cluster on your own VMs.
In response, there's been a wave of "serverless" startups because the idea of running anything yourself has become understood as (a) a time sink, (b) incredibly error prone, and (c) very likely to fail in production.
I think a Kubernetes 2.0 should consider what it would look like to have a deployment platform that engineers can easily adopt and feel confident running themselves – while still maintaining itself as a small-ish core orchestrator with strong primitives.
I've been spending a lot of time building Rivet to itch my own itch of an orchestrator & deployment platform that I can self-host and scale trivially: https://github.com/rivet-gg/rivet
We currently advertise as the "open-source serverless platform," but I often think of the problem as "what does Kubernetes 2.0 look like." People are already adopting it to push the limits into things that Kubernetes would traditionally be good at. We've found the biggest strong point is that you're able to build roughly the equivalent of a Kubernetes controller trivially. This unlocks features more complex workload orchestration (game servers, per-tenant deploys), multitenancy (vibe coding per-tenant backends, LLM code interpreters), metered billing per-tenant, more powerful operators, etc.
This post did not mention the "external storage backend."
It's assumed that the "external storage backend" is Google Cloud Storage, since they also use it for Durable Objects storage: https://youtu.be/C5-741uQPVU?si=yOX-6gRzTbIhh34h&t=1725 (this video is worth the watch on their neat arch for Durable Objects SQLite)
Similarly, their data subprocessors lists Google for the developer platform platform: https://www.cloudflare.com/gdpr/subprocessors/cloudflare-ser...
And aligns with the Google Cloud Storage incident: https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1S...
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.
I've been enjoying watching you build this on X – nice work.
Can you elaborate on both of these issues?
Vanilla SQLite solved multiple writers a long time ago when they introduced WAL in 2010. Does Turso not support this?
Is the issue with foreign keys that they're not enabled by default?
Neat! How does this differ from KSQL?
Yep. Most designs I've seen put user profiles under a different table which requires a separate query.