Hopp: a Tauri and LiveKit pair programming app you can run on your own hardware
The best OSS remote pair programming app.
At a glance
- What is it?
- Hopp is an AGPL-3.0 desktop screen sharing tool for developers, with a Rust capture engine, a Go backend and a Docker Compose self-host stack. The managed cloud is the intended path; self-hosting is documented but expects you to own DNS, TLS and LiveKit.
- Who is it for?
- Adopt Hopp if your team already runs Docker and wants screen sharing that never leaves infrastructure you control, and if macOS is the client platform you actually use. Do not adopt it yet if you need Linux desktops, or if Windows is your primary environment, since the README labels Windows alpha and Linux planned.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Hopp targets: pairing without a link in the chat window
Remote pair programming usually means one person pastes a meeting URL into a chat client, the other clicks it, a browser tab opens, and both parties negotiate screen permissions inside a general purpose video tool that was designed for talking heads rather than for reading code. Hopp's README frames the alternative as one-click pairing: you click your teammate in the app and start pairing, with no link sharing and no setup. That is the product claim, and it is a workflow claim rather than a technical one. The audience is narrow and clearly stated. It is developers who pair or mob, teams that want screen sharing on their own infrastructure, and anyone currently paying for Tuple, Pop, Drovio or Coscreen who wants the source. The README positions Hopp directly as the OSS Tuple alternative. Mob sessions are capped at 10 participants, which tells you the design centre is a small team standing around one screen, not an all-hands broadcast.
What actually moves the pixels: Rust capture, Go signalling, LiveKit transport
The repository map is the clearest description of the architecture available. The tauri/ directory holds the desktop shell, Tauri plus React and TypeScript. The core/ directory holds the screen capture and WebRTC engine, written in Rust and exposed as a crate named hopp_core. The backend/ directory is an API server in Go backed by Postgres and Redis. The web-app/ directory is a React and Vite dashboard. Transport is LiveKit, and the README states that WebRTC was tuned for screen sharing with a sub-100ms latency target, linking to a blog post on latency exploration for the details. The data flow implied by that split is conventional and sensible: the Go API handles identity and room coordination against Postgres, Redis carries short-lived state, LiveKit brokers the media, and the Rust core does the capture and encode work on the client so the Tauri shell is not doing heavy lifting in JavaScript. Two consequences follow. First, the desktop app is not a thin wrapper around a web page, which is why the README claims low CPU overhead from native desktop rather than from a browser engine. Second, LiveKit is a hard dependency in both the managed and self-hosted paths, so your latency and your NAT traversal behaviour are LiveKit's, not Hopp's.
Self-hosting: four services, one Compose file, secrets you must supply
The self-host instructions in the README are four commands. Clone the repository, change into the selfhost directory, copy .env.example to .env and edit DOMAIN plus secrets, then run docker compose up -d. The stack includes Postgres, Redis, LiveKit and Caddy for automatic TLS. That service list is the honest scope of the work: you are operating a media server, a database, a cache and a reverse proxy, not a single binary. The README notes that localhost needs the fuller guide in selfhost/README.md, which implies the default configuration assumes a real domain with working DNS so Caddy can obtain a certificate. The sign-up flow is not needed on the self-hosted path, which is the main practical difference from the cloud plan. Everything else about running it, including upgrade procedure and backup expectations for the Postgres volume, is not described in the material available here, so treat the Compose file and the self-hosting documentation page as the source of truth rather than this summary.
Platform support is the constraint that decides most evaluations
macOS is labelled stable. Windows is labelled alpha. Linux is listed as planned in both the supported platforms line and the roadmap. If your team is mixed, that combination is the first thing to check against your reality, because a pairing tool only works when both people can join. The roadmap also lists dynamic codec selection with adaptive streaming resolution and key bindings as unfinished. Adaptive resolution matters more than it sounds for screen sharing: without it, a session on a poor uplink degrades in ways the user cannot tune, and key bindings are the difference between a tool that feels native and one that does not. None of these are reasons to reject Hopp, but they are the items that will show up in the first week of real use. The repository description calls Hopp the best OSS remote pair programming app, which is marketing language rather than a measurable claim, and the latency figure in the README is a target the project states it tuned toward, not a number verified here.
Where Hopp is the wrong tool
Hopp is not a general purpose video conferencing system. There is no mention of recording, transcription, calendar integration or dial-in, and pairing is organised around rooms of up to 10 rather than meetings with agendas. If your organisation needs one tool for standups, interviews and screen sharing, Hopp replaces only the last of those. It is also a poor fit for anyone unwilling to run infrastructure but uncomfortable with the managed plan, because the two supported paths are a subscription and a four-service Compose stack; there is no middle option described in the material. And if you need to modify and redistribute the desktop client under terms other than AGPL-3.0, the licence is a real constraint rather than a formality. The README does not discuss commercial licensing exceptions, so a team with that requirement should raise it with the maintainers before building on the code.
How it compares to the tools it names
The README names Tuple, Pop, Drovio and Coscreen as the alternatives Hopp is aimed at. The meaningful difference is not a feature list but the deployment model. Those products are hosted services: you install a client, authenticate against someone else's backend, and the media path runs through their infrastructure. Hopp's managed cloud works the same way, and the README is explicit that subscriptions fund development. The self-hosted path is the actual divergence. Running the backend, LiveKit, Postgres and Redis yourself means the signalling data and the media never leave your network, at the cost of operating four services and owning the TLS setup. That trade is the entire decision. A second difference is extensibility: with the source available you can read the Rust capture core and change it, which is not possible with the closed alternatives. That is a capability, not a promise of quality, and it only has value if someone on your team will actually open core/.
Maintenance, releases and what the licence implies
The release cadence visible in the material is rapid: v1.0.27, v1.0.28 and v1.0.29 landed within roughly two weeks of each other in August 2026, and the most recent push matches the latest release timestamp. Frequent releases are a signal that the project is moving, and they are also a signal that self-hosters should expect to pull new images regularly rather than deploy once. The material does not describe a migration process for the Postgres schema between versions, so anyone running the selfhost stack should confirm the upgrade path in the documentation before the first update rather than after. On licensing, Hopp ships under AGPL-3.0. The practical reading is that if you run a modified version as a network service for other people, the licence's source-availability obligations are likely to apply to your modifications. That is a summary of the licence family's intent, not legal advice, and any organisation planning to embed Hopp in a product should have its own counsel read LICENSE.md rather than rely on a review.
Editorial conclusion
Adopt Hopp if your team already runs Docker and wants screen sharing that never leaves infrastructure you control, and if macOS is the client platform you actually use. Do not adopt it yet if you need Linux desktops, or if Windows is your primary environment, since the README labels Windows alpha and Linux planned. Before committing, clone the repository, read selfhost/README.md in full, and confirm you can satisfy the DOMAIN and secret values that .env.example expects, because the Compose stack will not come up correctly without them.
Community notes