2026.10.12
Neko: Share a Self-Hosted Virtual Browser over WebRTC
Neko streams a browser or Linux desktop application from a self-hosted environment using WebRTC. Review networking, authentication, permissions, and isolation before deployment.
What it is for
Neko is a self-hosted virtual browser that runs in Docker and streams its desktop through WebRTC. Instead of installing the same browser environment on every endpoint, users connect to a remote session through a web interface and interact with the application there. The repository metadata identifies Apache License 2.0, and the project is not marked as archived.
The project is aimed at shared sessions. Friends can join a watch party; teams can run interactive presentations, collaborative browsing, or remote teaching; and developers can use a browser-based environment for testing and debugging. The README also lists personal workspaces, persistent and throwaway browsers, session broadcasting and recording, and browser automation as possible uses. These documented use cases should not be read as a guarantee that every scenario is a complete production-ready solution.
Documented capabilities
Neko focuses on real-time video, audio, and interaction. Its README says that multiple users can access the same virtual environment and that participants can control the shared screen. This makes it more than a viewing-only screen-sharing tool. It is also not limited to one browser: the documentation says it can run other Linux applications, such as VLC, or a desktop environment such as XFCE or KDE.
The v3.1.6 release notes list multi-file selection, bulk deletion, and file deletion for file transfer, as well as a fix allowing non-admin uploads and downloads. The release also adds OIDC-only member authentication, OAuth login restriction by user email, a mouse-pointer visibility setting, and an arm64 Google Chrome image. Example Docker Compose configurations cover a simple browser, a TURN server, a GPU-accelerated browser, and OAuth.
Limits and deployment considerations
WebRTC does not remove the need for network planning. Multiple viewers, audio, and connections across network boundaries should be tested against the actual routing environment. The release includes a TURN example, indicating that some deployments may need relay infrastructure. The supplied sources do not state minimum CPU, memory, bandwidth, or concurrency requirements, so they should not be inferred from the project description.
Self-hosting and containerization should not be treated as a complete security guarantee. A shared session may reach third-party sites, files, or internal applications. Operators still need to decide how to configure authentication, room permissions, HTTPS, reverse-proxy behavior, network egress, and container privileges. The README mentions VPN, Tor Browser, and jump-host scenarios, but the available sources do not establish independent guarantees about anonymity, privacy, or security outcomes.
Before deployment, verify whether the chosen browser image, persistence policy, GPU path, arm64 architecture, and authentication method fit the target environment. Version 3.1.6 documents related features and examples, but it does not provide a universal compatibility promise. For multiple rooms, the README points to the separate neko-rooms project, so room management should be evaluated as an additional deployment component rather than assumed to be included in the core repository.
Who it suits
Neko is a reasonable candidate for people comfortable with Docker, reverse proxies, and WebRTC troubleshooting, as well as development teams, remote instructors, and small groups that need a shared browser session. If the requirement is only a single-user remote desktop, or if it demands explicit enterprise auditing, granular permissions, and published capacity targets, validate those requirements first. The project’s collaborative positioning alone is not enough to confirm that they are covered.
Sources
Sources checked: 2026-10-12