Hopp: an open source, self-hostable screen sharing app for pair programming

What Hopp replaces, and for whom

Remote pair programming usually means one developer sharing a screen through a general-purpose video call. That works, but the transport is tuned for faces and slides, not for text, cursors and scrolling source files. Hopp is a desktop app that does one job: show a teammate your screen at a latency the README describes as sub-100ms, then let them take over. The README positions it as an open source alternative to Tuple, and also names Pop, Drovio and Coscreen as the category it competes with.

The audience is narrow on purpose. The README lists macOS as stable and Windows as alpha, with Linux marked planned in both the platform list and the roadmap. A team that pairs daily on Macs is the target. A cross-platform team is not, yet. The other stated use case is mob programming: the README says a room supports up to 10 participants.

Two things distinguish it from a generic meeting tool. Pairing is one click from a list of your teammates, so the README's claim is that there is no link to paste into chat. And the whole stack is open source and self-hostable, which matters to teams that cannot route source code through an outside service.

The architecture: Tauri shell, Rust capture core, Go backend, LiveKit transport

The repository map in the README splits the system into five parts. `tauri/` is the desktop shell, a Tauri app with a React and TypeScript front end. `core/` is the Rust crate `hopp_core`, which the README describes as the screen capture and WebRTC engine. `backend/` is a Go API server backed by Postgres and Redis. `web-app/` is a React and Vite dashboard. `selfhost/` is a Docker Compose stack.

The media path does not go through the Go backend. The README states the WebRTC infrastructure is powered by LiveKit, and the self-host stack includes LiveKit alongside Postgres, Redis and Caddy for automatic TLS. So the Go server handles accounts, rooms and presence, while LiveKit carries the screen and audio. That split is why the desktop client can be a thin Rust capture layer: encoding and transport are delegated.

The front end and the desktop app both consume the same API contract. The root `package.json` defines two scripts, `generate-openapi-types:web-app` and `generate-openapi-types:tauri`, which run `openapi-typescript` against `./backend/api-files/openapi.yaml` and write `openapi.d.ts` into each workspace. The API surface is therefore versioned as an OpenAPI document in the backend repository and the TypeScript types are generated from it rather than hand-written.

Installing the desktop app and starting a first session

The README's try-it steps start with the desktop build. There is no package manager install documented, so you fetch the binary from the releases page.

# macOS (stable) or Windows (alpha)
# download from https://github.com/gethopp/hopp/releases/latest

After installing, you choose a backend. The managed cloud option is a sign-up at gethopp.app with a 14 day free trial. The self-host option needs no sign-up at all. If you take the self-host route, the README gives this sequence from the repository root.

git clone https://github.com/gethopp/hopp.git
cd hopp/selfhost
cp .env.example .env   # edit DOMAIN + secrets
docker compose up -d

Two things to note in that block. The comment says you must edit `DOMAIN` and the secrets in `.env` before starting, so the stack is not usable with the example file as-is. And the README warns that this command is aimed at a real domain: for `localhost` it points to the full guide in `selfhost/README.md`. The stack brings up Postgres, Redis, LiveKit and Caddy, and Caddy issues the TLS certificate for the domain you set.

Once a backend is configured, the README's third step is the actual product: click a teammate and start pairing. There is no room code or link to exchange, which is the behaviour the one-click pairing bullet describes.

Where Hopp is the wrong choice

Linux is the clearest gap. The README lists Linux as planned under supported platforms and repeats it as an unchecked roadmap item, so a Linux user has no supported client today. Windows is present but labelled alpha, which is a different risk profile from macOS stable.

Self-hosting has a cost the README does not quantify. You are running Postgres, Redis, LiveKit and Caddy, plus a Go API server. That is four stateful services before you count the backend, and Caddy needs a real domain with working DNS to issue certificates. The README acknowledges the friction by pointing localhost users at a separate guide. If your team has no one who wants to own that stack, the managed cloud is the intended path, and the README is explicit that the paid plan funds development of the open source app.

There is also a category mismatch worth naming. Hopp is not a general video conferencing tool. The README does not describe meeting scheduling, chat, recording or a web client for guests. If someone outside your team needs to watch a session from a browser, nothing in the README says that is supported.

Finally, the roadmap is open. Dynamic codec selection and adaptive streaming resolution are unchecked, as are key bindings. Those are the kinds of features that affect quality on bad networks, and they are not there yet.

How Hopp differs from a general-purpose meeting app

The obvious alternative is whatever video tool your team already pays for. The difference is in what each one optimises. A meeting app is built around a calendar, a roster of invited participants, and a UI that treats the screen share as one tile among many. Hopp inverts that: the screen is the product, the participant list is the entry point, and the README's claim is that you start a session by clicking a teammate rather than by distributing a link.

The transport choice follows from that. LiveKit is a WebRTC SFU, and the README links to a blog post about latency tuning for screen sharing. A meeting app can afford a second or two of buffering because a face on a call tolerates it. Reading code over a share does not, which is why the README leads with sub-100ms latency and why the capture path is a dedicated Rust crate instead of a browser API.

The second alternative is doing nothing and using an editor's built-in collaboration. That keeps everything inside the editor, but it only shares the file. Hopp shares the whole desktop, so a terminal, a browser, a profiler or a database client are all visible. The trade-off runs the other way too: a desktop share exposes everything on your screen, and the README does not document per-window scoping.

Licence, releases and what upgrades cost you

The licence is AGPL-3.0. The root `package.json` states it precisely as `AGPL-3.0-only`, and the README links to `LICENSE.md` at the repository root. For internal use this changes nothing. If you intend to offer a modified Hopp to others over a network, the AGPL's source-availability terms are the part to read carefully, and that is a question for your own counsel rather than something the README answers.

Release cadence is visible in the tags. v1.0.29 landed on 2026-08-23, v1.0.28 on 2026-08-09, and v1.0.27 on 2026-08-08. The last push to the repository was also on 2026-08-23, so the project is not archived and the most recent activity is roughly a month old. Note that the desktop app and the self-hosted backend version independently from your perspective: the app comes from GitHub releases, while the backend is whatever you pull from the repository and rebuild with Docker Compose.

That is the real upgrade cost. Cloud users get whatever the managed backend runs. Self-hosters own the drift between their deployed stack and the current `selfhost/` compose files, and the README gives no migration or rollback procedure for schema changes in Postgres. The repository does include `cliff.toml`, which is git-cliff configuration, so changelogs are generated rather than hand-written, and `Taskfile.yml` at the root is the task runner the project uses for its own workflows.

Editorial conclusion

Adopt Hopp if your team pairs on macOS and wants either the managed cloud or a self-hosted LiveKit stack under your own domain. Do not adopt it if anyone on the team is on Linux, since the README lists Linux as planned rather than supported, and Windows only as alpha. Before committing, verify the selfhost/.env.example values you must edit (DOMAIN and the secrets), and confirm that the AGPL-3.0-only licence in package.json is acceptable for how you intend to redistribute the desktop app.

Frequently asked questions

Official sources

1. gethopp/hopp on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases