n.eko: Ein Docker-Browser, der per WebRTC an mehrere Nutzer streamt
Ein selbst gehosteter virtueller Browser, der in Docker ausgeführt wird und WebRTC verwendet.
Auf einen Blick
- Was ist das?
- Ein in Go geschriebener, selbst gehosteter virtueller Browser: n.eko streamt einen Desktop aus einem Docker-Container über WebRTC an mehrere Teilnehmer gleichzeitig und eignet sich für Watch-Partys ebenso wie für Fernzugriff.
- Für wen ist es gedacht?
- n.eko passt zu Teams, die eine gemeinsame Browser-Sitzung betreiben wollen, etwa für Watch-Partys, Schulungen oder interaktive Demos, ohne sich auf einen Drittanbieter zu stützen. Wer nur gelegentlich allein auf eigene Lesezeichen und Passwörter von unterwegs zugreifen will, bekommt mit einem schlanken VPN-Host oft das einfachere Setup.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 5 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Vom Aus von Rabb.it zum Fork von n.eko
Die Entstehung von n.eko hängt direkt an der Schließung von Rabb.it. Der ursprüngliche Autor des Projekts wollte mit Freunden Anime schauen, aber seine Internetverbindung schaffte das Streaming nicht, und Discord brach zusammen, sobald ein Freund beitreten wollte. Er suchte nach Alternativen, fand ein paar ähnliche Projekte, aber keines bot einen virtuellen Browser im Container. Erst der Blick auf Turtus half ihm, den Rest selbst zu bauen.
m1k1o stieß später auf das Projekt nurdism/neko, mochte die Idee des kollaborativen Browsens und legte einen Fork an. Der Plan war, die eigenen Änderungen in das Upstream-Repository zurückzugeben. Der ursprüngliche Autor hatte dafür aber keine Zeit mehr, und das alte Repository wurde schließlich archiviert. Dieser Fork ist damit die de facto fortgeführte Version des Projekts, das heute unter m1k1o/neko gepflegt wird.
WebRTC als Unterschied zu Guacamole und noVNC
Der zentrale Mechanismus ist simpel beschrieben: n.eko streamt einen Desktop, der in einem Docker-Container läuft, per WebRTC an den Browser der Nutzer. Das README vergleicht das ausdrücklich mit clientlosen Remote-Desktop-Gateways wie Apache Guacamole oder einer Kombination aus websockify und noVNC. Diese Setups brauchen einen Remote-Desktop-Server zusammen mit dem gewünschten Programm, und sie übertragen Bildschirminhalte als Bilderströme über WebSockets.
Demgegenüber setzt n.eko auf WebRTC. Daraus ergeben sich nach Darstellung des README flüssigeres Video, eingebauter Ton und die Möglichkeit, dass mehrere Personen gleichzeitig steuern. Genau diese Mehrbenutzersteuerung fehlt Guacamole und noVNC nativ. Das README liefert keine Benchmarks oder Produktionsmessungen zu diesen Eigenschaften; die Vorteile werden als Designunterschied beschrieben, nicht als gemessene Zahl. Wer harte Latenzmessungen erwartet, findet sie in der Dokumentation nicht.
Nicht nur Browser, sondern ganze Desktops und Apps
Der Name des Projekts betont den Browser, aber die Grenze zieht das README anders: Es kann im Prinzip alles gestreamt werden, was unter Linux läuft. Ausdrücklich genannt sind VLC und vollständige Desktop-Umgebungen wie XFCE oder KDE. Auch der Betrieb außerhalb eines Containers ist laut README möglich: n.eko ließe sich auf einem Host installieren, mit dem lokalen X-Server verbinden und so eine gesamte VM steuern.
Theoretisch müsste es nicht einmal ein X-Server sein. Das README formuliert, dass alles, was sich steuern und periodisch als Bild abgreifen lässt, die Rolle übernehmen könnte. Als Zukunftsidee wird die Umsetzung von RDP- oder VNC-Protokollen genannt, bei denen n.eko nur noch als WebRTC-Relay dient. Das ist ausdrücklich als Ausblick markiert und nicht als verfügbares Feature.
Gemeinsame Sitzungen: Watch-Partys, Präsentationen, Schulung
Der primäre Anwendungsfall ist das gemeinsame Verbinden mehrerer Personen mit Echtzeitsynchronisierung und Interaktivität. Das README nennt Watch-Partys als offene Alternative zu giggl.app oder hyperbeam: Video zusammen ansehen und per Chat oder Emotes reagieren. Dazu kommen interaktive Präsentationen, bei denen Zuschauer nicht nur zuschauen, sondern den Bildschirm steuern können.
Weitere Szenarien sind kollaboratives Arbeiten wie Brainstorming oder gemeinsames Code-Debugging sowie Support- und Schulungssitzungen in einer kontrollierten Umgebung. Wer den virtuellen Browser in die eigene Web-App einbetten will, kann Räume über eine API anfordern; dafür gibt es das separate Projekt neko-rooms. Ein Drittanbieter nutzt n.eko sogar, um gemeinsam mit Freunden innerhalb von VR Chat einen entfernten Browser anzuschauen.
Einzelplatz-Fälle: persistenter Browser, Wegwerf-Browser, Broadcast
Neben den Mehrbenutzer-Szenarien dokumentiert das README auch Anwendungsfälle für einzelne Personen. Ein persönlicher Arbeitsbereich streamt containerisierte Apps an den eigenen Rechner, ähnlich wie Kasm. Ein persistenter Browser hält Cookies und Zustand serverseitig verfügbar, ohne nach dem Beenden der Verbindung Spuren im Host-Browser zu hinterlassen; übertragen wird nur Video, nicht die Cookie-Daten.
Für einen Wegwerf-Browser weist das README auf den Tor-Browser und ein eigenes VPN-Projekt namens neko-vpn hin, um zusätzliche Anonymität zu erreichen und den Browser im Container zu isolieren. Sitzungen lassen sich per RTMP an Plattformen wie Twitch oder YouTube broadcasten; die Aufzeichnung dieses Streams in eine Datei übernimmt etwa nginx-rtmp. Schließlich kann n.eko als Sprungbrett zu internen Anwendungen ohne VPN dienen, und als automatisierter Browser lassen sich Playwright oder Puppeteer installieren, während die Sitzung für Eingriffe offen bleibt.
Images, Raumverwaltung und Apache-2.0 in der Praxis
Vorgefertigte Images decken Firefox, Tor Browser, Waterfox, Chromium, Google Chrome, Ungoogled Chromium, Microsoft Edge, Brave, Vivaldi und Opera ab. Dazu gibt es Images für XFCE, KDE, Remmina und VLC; weitere Varianten führt das Repository m1k1o/neko-apps auf. Die genauen Tags und Pull-Befehle verlinkt das README in den Docker-Abschnitt der Dokumentation unter neko.m1k1o.net, deshalb stehen sie dort und nicht im README selbst.
Die Raumverwaltung liegt bei neko-rooms, einem separaten Projekt, das laut README auch eine konfigurationsarme Installation mit HTTPS anbietet. Die Dokumentation umfasst Migration von V2, erste Schritte, Beispiele, Konfiguration, FAQ und Fehlerbehebung. Das Projekt steht unter der Apache-2.0-Lizenz, die Vervielfältigung, abgeleitete Werke, öffentliche Aufführung und Weitergabe erlaubt. Auskunft über Sicherheitszertifizierung oder Support-Zusagen gibt weder der Lizenztext noch das README.
Redaktionelles Fazit
n.eko passt zu Teams, die eine gemeinsame Browser-Sitzung betreiben wollen, etwa für Watch-Partys, Schulungen oder interaktive Demos, ohne sich auf einen Drittanbieter zu stützen. Wer nur gelegentlich allein auf eigene Lesezeichen und Passwörter von unterwegs zugreifen will, bekommt mit einem schlanken VPN-Host oft das einfachere Setup. Vor der Nutzung lohnt es, die Einrichtung unter neko.m1k1o.net durchzugehen und zu prüfen, ob der eigene Provider die benötigten WebRTC-Ports oder STUN-Verbindungen nicht blockiert.
Community-Notizen