rivet

ntity gives you the same scalability without those tradeoffs [2]. How this compares: - Cloudflare Durable Objects & Agents: most similar to Rivet Actors with colocated SQLite and compute, but closed-source and vendor-locked - Turso Cloud: Great platform, but closed-source + diff use case. Clients query over the network, so reads are slow or stale. Rivet's single-writer actor model keeps reads local and fresh. - D1, Turso (the DB), Litestream, rqlite, LiteFS: great tools for running a single SQLite database with replication. Rivet is for running lots of isolated databases. Under the hood, SQLite runs in-process with each actor. A custom VFS persists writes to HA storage (FoundationDB or Postgres). Rivet Actors also provide realtime (WebSockets), React integration (useActor), horizontal scalability, and actors that sleep when idle. GitHub: https://github.com/rivet-dev/rivet Docs: https://www.rivet.dev/docs/actors/sqlite/ [1] https://news.ycombinator.com/item?id=42472519 [2] https://rivet.dev/blog/2025-02-16-sqlite-on-the-server-is-mi... [3] https://www.alexdebrie.com/posts/dynamodb-single-table/

ivet 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)

nt 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.

wever, their scope differs: Rivet Actors are broader and designed for anything stateful & realtime, while Durable Promises seem focused on workflows with complex control flow. Rivet Actors can (and likely will) support workflow-like applications in the future, since state management and rescheduling are already built-in. For a deeper dive, Temporal has a writeup comparing actors and workflows: https://temporal.io/blog/workflows-as-actors-is-it-really-po...

ad a well maintained SQL layer.) Here's where Rivet's architecture gets fun – we don't rely on a traditional orchestrator like Kubernetes or Nomad for our runtime. Instead, our orchestrator is powered by an in-house actor-like workflow engine – similar to how FoundationDB is powered by their own actor library (Flow [4]) internally. It lets us reliably & efficiently build complex logic – like our orchestrator – that would normally be incredibly difficult to build correctly. For example, here's the logic that powers Rivet Actors themselves with complex mechanisms like retry upgrades, retry backoffs, and draining [2]. One of the reasons we built Rivet Actors is because we tried to replace most of our Redis-based realtime infrastructure with Durable Objects. The architecture allowed us to build realtime features much faster & efficiently, but the platform & APIs were needlessly rigid and difficult to use. Our goal is to build an actor-like platform that includes the bells and whistles required for developers to benefit from the actor model without the learning curve of tools like Erlang/OTP, Akka, or Orleans. Rivet Actors provides a few key benefits in flexibility over Durable Objects: - Open-source (Apache 2.0) – built to be self-hosted and deployed on-prem - Provides observability out of the box, no Logpush required - Rivet Actors support the Deno runtime, so NPM & JSR just works - @rivet-gg/actor [5] framework provides RPC, state, and events out of the box for faster bootstrapping; you can modify and deploy it yourself - Supports both V8 isolates & Docker-compatible containers so you can run any software you'd like, like Godot/Unity servers or video transcoding - Also supports TCP & UDP (we run games!) - Provides vanilla HTTP API for easy use with existing apps - Full control over regions There's plenty more that I don't have space to talk about. Give our docs a read if you'd like to learn more [6] or read about internal design decisions [7]. I'll be in the comments answering questions! Cheers, Nathan [1] https://github.com/rivet-gg/rivet?tab=readme-ov-file#diagram [2] https://github.com/rivet-gg/rivet/blob/a3db31f3b5c351061d665... [3] https://www.youtube.com/watch?v=9g84y_60VGM [4] https://apple.github.io/foundationdb/flow.html [5] https://jsr.io/@rivet-gg/actor/doc [6] https://rivet.gg/docs [7] https://rivet.gg/docs/internals/design-decisions

for games," but I've found these to be pretty useless in practice. We can only measure traffic that reaches our game servers, so I have no way of knowing if they're actually helping at all. Your best bet is getting familiar with iptables and fine-tuning rules to match your game's traffic patterns. Thankfully, LLMs are pretty good at generating these rules for you nowadays if you're not already familiar with these tools. Make sure to set up something like node-exporter to be able to monitor attacks and understand where things go wrong. There have been a few other posts on HN in the past that go into more depth about game server DoS mitigation [2] [3]. I built something in the same vein for my startup (Apache 2.0 OSS, steal our code!) [4] that runs a series of load balancers in front of game servers in order to act like a mini-Cloudflare. In addition to the basics I already listed, we also have logic under the hood that (a) dynamically routes traffic to load balancers and (b) autoscales hardware based on traffic in order to absorb attacks. We're rolling out a dynamic bot attack & mitigation mechanism soon to handle more complex patterns. [1] https://www.cloudflare.com/application-services/products/arg... [2] https://news.ycombinator.com/item?id=35771466 [3] https://news.ycombinator.com/item?id=28675094 [4] https://github.com/rivet-gg/rivet

. We get the benefit of a dedicated IP + any port + no 3rd party vendors for $2.50/mo in your own cloud. All you need is a Linode access token, arguably faster and cheaper than any other reverse tunneling software. Source: https://github.com/rivet-gg/rivet/tree/main/infra/dev-tunnel Setup guide: https://github.com/rivet-gg/rivet/blob/main/docs/infrastruct...

nt toolchain for super configurable self-hosted Rivet clusters. It’s way over-engineered. - The entire repo is usable as a library. Our EE repo uses OSS as a submodule. - Traefik used as an edge proxy for low-latency UDP, TCP+TLS, & WSS traffic. - Apache Traffic Server is under-appreciated as a large file cache. Used as an edge Docker pull-through cache to improve cold starts & as a CDN cache to lower our S3 bill. - ClickHouse used for analytics & game server logs. It’s so simple, I have nothing more to say. - Serving Docker images with Apache TS is simpler & cheaper than running a Docker pull-through cache. - Nebula has been rock solid & easy to operate as our overlay network. - We use Redis Lua scripts for complex, atomic, in-memory operations. - Obviously, we love Nix. - We keep a rough SBOM [3]. - Licensed under Apache 2.0 (OSI-approved). We seriously want people to run & tinker with Rivet themselves. We get a lot of questions about this: [4] [5] Some HN-flavored FAQ: > Why not build on top of Agones or Kubernetes? Nomad is simpler & more flexible than Agones/Kubernetes out of the box, which let us get up and running faster. For example, Nomad natively supports multiple task drivers, edge workloads, and runs as a standalone binary. > [Fly.io](http://Fly.io) migrated off of Nomad, how will you scale? Nomad can support 2M containers [6]. Some quick math: avg 8 players per lobby * 2M lobbies * 8 regional clusters = ~128M CCU. That’s well above PUBG’s 3.2m CCU peak. Roblox’s game servers also run on top of Nomad [7]. We’re in good company. > Are you affected by the recent Nomad BSL relicensing [8]? Maybe, see [9]. > How do you compare to $X? Our core goal is to get developers up and running as fast as possible. We provide extra services like our matchmaker [10], CDN [11], and KV [12] to make shipping a fully-fledged multiplayer game require only a couple of lines of code. No other project provides a comparably accessible, OSS, and comprehensive game server manager. > Do you handle networking logic? No. We work with existing tools like FishNet, Mirror, NGO, Unreal & Godot replication, and anything else you can run in Docker. > Is anyone actually using this? Yes, we’ve been running in closed beta since Jan ‘22 and currently support millions of MAU across many titles. [1]: https://github.com/rivet-gg/microgravity.io [2]: https://github.com/rivet-gg/rivet/tree/main/docs/libraries/b... [3]: https://github.com/rivet-gg/rivet/blob/main/docs/infrastruct... [4]: https://github.com/rivet-gg/rivet/blob/main/docs/philosophy/... [5]: https://github.com/rivet-gg/rivet/blob/main/docs/philosophy/... [6]: https://www.hashicorp.com/c2m [7]: https://www.hashicorp.com/case-studies/roblox [8]: https://www.hashicorp.com/blog/hashicorp-adopts-business-sou... [9]: https://news.ycombinator.com/item?id=37084825 [10]: https://rivet.gg/docs/matchmaker [11]: https://rivet.gg/docs/cdn [12]: https://rivet.gg/docs/kv