Neko

What It Is

Neko, from m1k1o on GitHub, is a self-hosted virtual browser. You
run it in a container. It runs Chromium or Firefox inside that
container, on a virtual display, and streams the display to anyone
who opens its URL through WebRTC. The latency is good enough
(under 300 ms) that the experience feels like using a normal
browser. The interesting part is that the actual browser is
running on your server, not on the device you are looking at.

Several people can connect to the same Neko session. One person
has control of the keyboard and mouse at any given time, and
control can be handed off explicitly. Everyone else sees what
the controller is doing. The whole thing runs as long as the
container is up, which means a session can persist across the
operator's reboots, network changes, or moving between devices.

The project ships with a small set of pre-built images (Chromium,
Firefox, Brave, Tor Browser, several others) plus a way to package
arbitrary applications, not just browsers. The architecture is
generic enough to stream any X11 application in the same way.

Why It Is Genuinely Useful

The reason I think Neko earns its place in a homelab is that the
"browser running in a container that you watch from your laptop"
pattern solves several distinct operational problems with one
deployment.

The first is throwaway browsing for sensitive or untrusted
sites. Every researcher, pentester, or privacy-conscious user
has wanted, at some point, a browser that cannot be fingerprinted
back to their main session, that does not share cookies with
anything else they have logged into, that lives in an isolated
environment, and that can be destroyed in one command after use.
A Neko container with the ephemeral flag does exactly this. The
session leaves no trace on the operator's laptop because the
browser was never on the laptop. Closing the container is the
equivalent of factory-resetting that browser.

The second is jump-host browsing for internal resources.
There are organizations where the right pattern for accessing
sensitive internal services is to do it through a controlled
intermediate host that can be audited rather than from every
developer's laptop. Neko, deployed inside the network perimeter
with the internal resources visible to it, becomes that
intermediate host. The user's laptop is just the display. The
actual session lives on the bastion. If the user's laptop is
compromised, the credentials and the session state are not on
the laptop to be stolen. The pattern is the same one VDI vendors
sell at enterprise prices, in twenty megabytes of Docker image.

The third is multi-user co-browsing for collaboration. Two
engineers debugging a web application together, a parent and a
remote relative watching a video on the same screen, a teacher
walking students through a website live, a designer reviewing
a prototype with a client. Each of these is a use case that
existing screen-sharing tools (Zoom, Meet, the various commercial
options) handle clumsily and that Neko handles natively. The
co-browsing case is the one that demonstrates why WebRTC was
the right choice for the transport: the latency is low enough
that handing control between participants feels immediate.

The fourth is the embed-anywhere case. A Neko instance can be
embedded as an iframe in a web application. The application's
users see and interact with the embedded browser without ever
having access to the underlying code or the network it can
reach. This is one of the cleanest available answers to "how do
I share a demo of my software without giving the viewer access
to it." The video stream is what they see. The actual software
is on your infrastructure, not theirs.

Why the WebRTC Choice Matters

The reason Neko works as well as it does, where similar
"browser-in-a-container, view-through-a-web-page" projects from
the last decade did not, is the choice of WebRTC as the transport.
WebRTC was designed for low-latency real-time communication. The
under-300-ms latency that Neko achieves means the experience does
not feel like a remote desktop. It feels like a slightly slow
local browser. The difference between 300 ms and 1500 ms is the
difference between a tool you use and a tool you tolerate.

The other transport-level benefit is that WebRTC video looks, to
anyone monitoring the network, like any other video call. The
operator is not running a VNC session that any deep-packet
inspection flags as remote desktop traffic. They are watching
something that looks like a video call, because mechanically it
is one. For an operator on a corporate network where remote
desktop is policy-blocked, this matters.

Honest Limits

Neko is not a complete replacement for a local browser. Three
limits are worth naming.

Performance is bounded by the server's CPU and the WebRTC
bitrate. The container is encoding video in real time. A 4K
monitor at 60 fps is achievable but expensive. Most users settle
for 1080p at 30 fps, which is comfortable for browsing and good
enough for video playback.

GPU-accelerated content (WebGL, complex CSS animations,
hardware-decoded video) works but is slower than on a local
browser. The encode-decode round trip adds overhead that a local
browser does not pay.

The audio and video stream consumes bandwidth in both directions
(low upstream from the viewer, moderate downstream to the
viewer). Operators on bandwidth-constrained connections will
notice. For most home and office connections, the bandwidth is
not a meaningful constraint.

Closing

The reason I am writing about Neko is that it is the kind of
small, focused, self-hostable project that the modern open-source
ecosystem produces well and that the commercial alternatives
either do not exist or cost ten times more than the engineering
effort justifies. m1k1o has been maintaining it for several
years. The codebase is small enough to read. The deployment is
one container. The use cases I described above are each
individually worth the setup cost, and the same container handles
all of them.

For the privacy-conscious operator who wants a throwaway browser,
for the security-conscious team that needs a jump host for
internal services, for the family that wants to watch movies
together across distances, for the engineer who wants to embed a
demo without exposing the underlying system, Neko is a genuinely
useful primitive. It is one of the projects I keep recommending
when people ask "what should I be self-hosting right now."

Run it once. Open the URL on your phone or another laptop. Watch
yourself use a browser on your own server, in real time, with
sub-second latency. The pattern becomes obvious within thirty
seconds of using it.