Session backend orchestrator for ambitious browser-based apps. (by drifting-in-space)

Plane Alternatives

Similar projects and alternatives to plane

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better plane alternative or higher similarity.

plane reviews and mentions

Posts with mentions or reviews of plane. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-02-22.
  • Launch HN: Depot (YC W23) – Fast Docker Images in the Cloud
    6 projects | | 22 Feb 2023
    Congrats on the launch!

    We've been using Depot with Plane ( Prior to depot, I had to disable arm64 builds because they slowed the build down so much (30m+) on GitHub's machines. With Depot, we get arm64 and amd64 images in ~2m.

  • Show HN: DriftDB is an open source WebSocket back end for real-time apps
    15 projects | | 3 Feb 2023
    I see you also created Plane - what's the relationship between driftdb and plane? Can they be used together? Does one depend on another?
    15 projects | | 3 Feb 2023
    NATS is great, we use it in another project, Plane ( The reasons I didn’t use it instead of making DriftDB:

    - In NATS, unless you set up authentication, any user can subscribe to “>” and get a firehose of every message, even if they don’t know the room IDs.

    - NATS Jetstream supports rollups, but they roll up the entire stream, rather than up to a certain sequence number. This would break our ability to do leaderless compaction.

    15 projects | | 3 Feb 2023
    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 ;)

    15 projects | | 3 Feb 2023
    > What does "on the edge" mean in this context?

    DriftDB has a concept of “rooms”, which are essentially broadcast channels. By “on the edge”, what I mean is that the authoritative server for each room can be geographically located near the participants in that room. In practice, today that means that it can be compiled to WebAssembly and run as a Cloudflare Worker.

    > Can I just run the server part on my own infrastructure?

    Kinda. It includes a server that runs locally, but it’s only useful as a development server at this point. Your question about multiple pods is exactly the reason -- unless you have a routing layer that is aware of DriftDB’s “rooms”, it won’t work if you scale it up. We also make which provides the routing layer, but it might be overkill for a DriftDB use case.

  • Aper: a Rust library for data synchronization using state machines.
    2 projects | | 31 Jan 2023 is a lightweight orchestrator that routes traffic intended for the same document/game instance/chatroom etc. to the same server process. Each one gets an ephemeral hostname and the routing is done over DNS.
  • You might not need a CRDT
    9 projects | | 5 Dec 2022
    > I wonder what web development could learn from online game development when it comes to "multiplayer" apps - I mean it's right there in the name.

    100%. The architecture we used for takes a lot of inspiration from how game servers work, but using HTTP/WebSocket instead of UDP.

    A lot of state sharing techniques that people are now using on the web (like cursor position smoothing and optimistic updates) have decades of precedent in multiplayer games.

    We’ve also seen more apps start to use an approach to pixel streaming which more closely resembles stadia than traditional VNC.

  • Plane: Per-user back ends for ambitious web apps
    5 projects | | 13 Oct 2022
    Hey HN!

    Plane came from our desire to build tools that have the low friction to use of running in the browser, but can use more memory and compute than the browser will allocate. The 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

    Here's a direct link to our repo: and docs:


    5 projects | | 13 Oct 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 to abstract the burden away from the application layer.

    Time series metrics are exposed 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.


    5 projects | | 13 Oct 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, 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, which 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 LLVM, 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 per-user 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.




  • A note from our sponsor - InfluxDB | 28 Mar 2023
    Ingest, store, & analyze all types of time series data in a fully-managed, purpose-built database. Keep data forever with low-cost storage and superior data compression. Learn more →


Basic plane repo stats
15 days ago

drifting-in-space/plane is an open source project licensed under MIT License which is an OSI approved license.

Popular Comparisons

SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives