jamsocket

plane

Rust2022–2026

jamsocket / plane

plane

A distributed system for running WebSocket services at scale.

Explore on GitHub Read Hacker News discussions

6Distinct people

17Mentions

1Explicit recommenders

2KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

A distributed system for running WebSocket services at scale.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

Seems expensive no? To start a http container per request? But I suppose it does solve many server side persistence issues. And I love the power it affords you in creating…

ArtWomb used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year17 dated mentions

Observed mentions: 2022-02-28 18:10:42 UTC to 2026-08-07 05:19:39 UTC.

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	12	2	10
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	2	1	1
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	2	1	1
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	0	0	0
2026 (partial)	2026-01-01 00:00:00 UTC	2027-01-01 00:00:00 UTC	1	0	1

What Hacker News says

17 sources

crabmusket·Aug 7, 2026

I believe Restate has something which can work similarly: https://docs.restate.dev/foundations/services There was also Jamsocket and Plane, though it looks like they've shut down after acquisition: https://github.com/jamsocket/plane This seems to be the first one which is providing drop-in compatibility for Cloudflare's JS-side APIs, including JSRPC etc.

In Celld: Self-hosted, distributed Durable Objects

paulgb·Oct 14, 2024

> Aside from the data locality, I still find the programming model (a globally-unique and addressable single-threaded class instance) to be quite nice, and would want to emulate it even without the Cloudflare edge magic. You might be interested in Plane (https://plane.dev/ / https://github.com/jamsocket/plane), which we sometimes describe as a sort of Durable Object-like abstraction that can run anywhere containers can. (I'm also one of the articles you linked, thanks for the shoutout!)

In Zero-latency SQLite storage in every Durable Object

taylorwc·Mar 5, 2024Submission

Plane: A distributed system for running WebSocket services at scale

3 points · Open discussion

mooreds·Oct 21, 2023Submission

Session back end orchestrator for ambitious browser-based apps

2 points · Open discussion

ArtWomb·Feb 3, 2023Recommendation phrase

Seems expensive no? To start a http container per request? But I suppose it does solve many server side persistence issues. And I love the power it affords you in creating virtual worlds. Awesome stuff ;) https://github.com/drifting-in-space/plane

In Show HN: DriftDB – an open source WebSocket backend for real-time apps

paulgb·Oct 14, 2022

Re. handling failure, we leave that up to an application/framework layer decision. When the backend is used for program state, the common approach is an auto-save loop that persists state externally (asynchronously) on a loop. If the backend is only used in a read-only way, the approach is to just recreate it on failure with the same parameters. In general, Plane backends are meant to be used with thick clients, so there’s also the option to treat clients as nodes in a distributed system for the purpose of failure. If the server goes down and is replaced, when it comes back up, the nodes could buffer and replay any messages that may have been lost during the failure. Over time as we see patterns emerge, we may create frameworks from them (like aper.dev) to abstract the burden away from the application layer. Time series metrics are expose

Read the rest

d through Docker’s API, collectors for it already exist for various sinks. We will soon be sending some time series metrics over NATS to use internally for scheduling, but the Docker API will be better for external consumption because the collector ecosystem is already robust. Resource caps can be defined at “spawn time”. They are not expected to have similar consumption, but the scheduler is not yet very smart, our approach currently is admittedly to overprovision. The scheduler is a big Q4 priority for us. Draining currently involves terminating the “agent” process on the node, which stops the drone from advertising itself to the controller. Traffic still gets routed to backends running on that drone. We have an open issue[1] to implement a message to do this automatically. [1] https://github.com/drifting-in-space/plane/issues/129

In Plane: Per-user backends for web apps

paulgb·Oct 13, 2022

Hey HN! Plane came from our desire to build tools that have the low friction to use of running in the browser, but use more memory and compute than the browser will allocate. The basic idea is to run a remote background process, connect to it over WebSocket, and stream data. This ends up being a surprisingly useful primitive to have, and it's been used to: - Pixel-stream X11 applications to the browser over WebRTC[1] - Run IDEs and notebooks - Power Figma-style realtime collaboration backends (including https://rayon.design). Here's a direct link to our repo: https://github.com/drifting-in-space/plane and docs: https://plane.dev/ [1] https://twitter.com/drifting_corp/status/1552773567649091584

In Plane: Per-user backends for web apps

paulgb·Oct 13, 2022

Thanks for taking the time to look through the architecture. There are definitely some choices that would have seemed weird to me when we set out to build this, but that we did not make lightly. We actually initially built this on Kubernetes, twice. The MVP was Kubernetes + nginx where we created pods through the API and used the built-in DNS resolver. The post-MVP attempt fully embraced k8s, with our own CRD and operator pattern. It still exists in another branch of the repo[1]. Our decision to move off came because we realized we cared about a different set of things than Kubernetes did. For example, cold start time generally doesn’t matter that much to a stateless server architecture (k8s’ typical use), but is vital for us because a user is actively waiting on each cold start. Moving away from k8s let us own the scheduling process, whi

Read the rest

ch helped us reduce cold start times significantly. There are other things we gain from it, some of which I’ve talked about in this comment tree[2]. I will say, it seemed like a crazy decision when I proposed it, but I have no regrets about it. The point of sqlite was to allow the “drone” version to be updated in place without killing running backends. It also allows (but does not require) the components of the drone to run as separate containers. I originally wanted to use LMDB, but landed on sqlite. It’s a pretty lightweight dependency, it provides another point of introspection for a running system (the sqlite cli), and it’s not something people otherwise have to interact with. I wrote up my thought process for it at the time in this design doc[3]. You’re right about shared backends among multiple users being supported by Plane. I use per-user to convey that we treat container creation as so cheap and ephemeral you could give one to every user, but users can certainly share one and we’ve done that for exactly the data sync use case you describe. [1] https://github.com/drifting-in-space/plane/tree/original-kub... [2] https://news.ycombinator.com/item?id=32305234 [3] https://docs.google.com/document/d/1CSoF5Fgge_t1vY0rKQX--dWu...

In Plane: Per-user backends for web apps

paulgb·Oct 9, 2022

The closest thing I’ve seen to a comprehensive write-up is this: https://medium.com/@mreichelt/how-to-show-x11-windows-within... (medium, unfortunately) We’ve been using it experimentally to run an ephemeral instance of Firefox that we can programmatically inject DNS and CA certs into, for localhost HTTPS development. It’s not documented yet, but the config is here: https://github.com/drifting-in-space/plane/pull/201

In Running GUI Linux in a virtual machine on a Mac

paulgb·Oct 6, 2022Submission

Show HN: Plane – spawn and connect to a remote process from your web app

10 points · Open discussion

paulgb·Oct 2, 2022

I haven't used Kafka in production, but we use NATS in Spawner[1] and I find it quite pleasant to work with. It gives you some basic but powerful messaging constructs (request/reply, queue groups, temporal decoupling via Jetstream) and then gets out of your way. [1] https://github.com/drifting-in-space/spawner

In Capsule: the nano (WASM) functions runner

paulgb·Sep 17, 2022

> How does webassembly <> backend communication work? I imagine it's somehow websockets. How do you proxy websocket connections to the appropriate backend? I don't think there's much public info about this, besides what you can infer from looking at what goes over the wire (zstd-encoded binary messages). But to your question about routing wss connections to the appropriate backend, we've been working on a proxy/DNS server that does just that (by giving each backend its own ephemeral hostname). We've talked to some Figma engineers and at least on a conceptual level they do something similar (although their routing is path-based rather than DNS-based). Our source is here if you're interested: https://github.com/drifting-in-space/spawner

In Why Figma Is Special

paulgb·Sep 10, 2022

For the “jhub but for any container that speaks HTTP” use case, you might find our Spawner project interesting: https://github.com/drifting-in-space/spawner We don’t have support for volumes yet, but I’m open to ideas.

In ContainerSSH: Launch containers on demand

paulgb·Aug 1, 2022

We did. Our use case is spinning up containers on demand to user actions, giving them ephemeral, internet-routable hostnames, and shutting them down when all inbound connections have dropped. Because users are waiting to interact with these containers, we found the start times with Kubernetes too slow and its architecture to be a bad fit. We ended up writing our own control plane that uses NATS as a message bus. We are in the process of open sourcing it here: https://github.com/drifting-in-space/spawner

In Ask HN: Have You Left Kubernetes?

paulgb·Jun 15, 2022

Is the appeal of isolates in this case the cold start time or the isolation? We're working on some open source infrastructure for running sandboxed (gVisor) containers on the fly from web services[1], and one of the use cases people have is serving Jupyter notebooks which seems like it might resemble your use case? [1] https://github.com/drifting-in-space/spawner/

In Ask HN: Pros and cons of V8 isolates?

Showing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.