512 karma · joined September 16, 2016
https://rivet.dev
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.
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.
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?
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
- TUI (I prefer this for most programming)
- Web UI (negligible difference than VS Code)
- Mobile support (via web UI)
- TypeScript SDK to automate
(Sprites.dev in the works already.)
Posted this morning an overview of the project: https://x.com/NathanFlurry/status/2018366627021291699
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.
Hacked together an SF parks ranking system based on current weather
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.
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)
(I work at Rivet)
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)
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"
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.
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...
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.
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?