What Does Self-Hosting a Virtual Browser Actually Mean?
A self-hosted virtual browser runs on a server you control and streams the rendered screen to your device, so pages never load on your own machine. Neko is the most widely used open-source option: a Docker container that serves Firefox, Chromium-family browsers or Tor over WebRTC. Choosing a virtual browser self hosted setup means you own the server, the data and the bill — plus the patching, sizing and uptime that come with them.
📌 TL;DR Executive Summary
- Core Takeaway: Neko is the most widely used self-hosted virtual browser — Apache 2.0 licensed, Docker-based, streamed over WebRTC — and a modest Linux VPS (roughly 2 cores and 2 GB RAM per running session) is enough to start.
- Key Risk/Challenge: WebRTC needs a forwarded UDP port range and real HTTPS. Skip either and you get a black screen, or worse, a public URL that hands strangers a browser inside your network.
- Recommended Solution: Self-host when demand is steady and you have ops capacity. If what you need is many isolated profiles rather than one shared screen, a browser profile manager like Send.win fits better than a streamed desktop.
How a Self-Hosted Virtual Browser Works Under the Hood
A virtual browser splits the browser in two. The engine — rendering, JavaScript, cookies, network requests — runs on a remote server, while your device receives a video stream and sends keyboard and mouse events back. A VPN routes your traffic; a virtual machine runs a whole operating system; a virtual browser moves only the browser engine off your device. That distinction explains almost every limitation below.
The container layer
Neko ships as Docker images: Firefox, Chromium-family browsers and Tor Browser, plus XFCE and KDE desktop images and application images such as VLC or Remmina. The backend is Go, the front end TypeScript and Vue.js, and it can drive a whole VM if you point it at one. Check the code and tags yourself — they are public in Neko’s project repository. One warning before you build: the original upstream repository was archived, development moved, and a 2026 fork republishing the same README exists. Confirm which repository and which image tag you are pulling.
The streaming layer
Neko streams the desktop over WebRTC instead of VNC, which is why video stays smooth and audio works without extra plumbing. The trade-off is networking. WebRTC media travels over UDP on a port range you forward on both the Docker host and any router in front of it. Reference deployments use something like 52000–52100, kept near 100 ports, with the server’s public IP declared through NEKO_WEBRTC_NAT1TO1 so ICE negotiation advertises the right address. Outside that range, connections fail or negotiate a path that never carries media. None of that plumbing is optional for a virtual browser self hosted on your own hardware, and none of it is handled for you.
What one session costs the server
Neko captures the screen and software-encodes it as VP8 or H.264, so a running session costs roughly what a software video encoder costs. Operator-reported sizing puts 1920×1080 at 30 fps near two CPU cores and two gigabytes of RAM, with load dropping by about half at 1280×720. Every viewer then receives their own copy of the stream at three to five megabits per second. Your upload bandwidth, not the server’s CPU, decides how many people can watch at once.
NEKO_DESKTOP_SCREEN before you buy a bigger server. Dropping from 1080p roughly halves CPU use per session, which often turns a two-session box into a four-session box for free.
Virtual Browser, Headless Browser, VM and VPN: What’s the Difference?
These four terms get mixed up constantly, and the mix-up makes people buy the wrong thing. All headless browsers are virtual browsers, but the reverse is not true: a headless browser has no graphical interface at all and is driven by code, while an interactive virtual browser shows you a live screen and takes your input.
| Approach | What runs remotely | What you interact with | Typical fit |
|---|---|---|---|
| Interactive virtual browser (e.g. Neko) | Browser engine plus screen capture and streaming | A live desktop, mouse and keyboard | Shared sessions, demos, training, reaching a network your laptop cannot |
| Headless browser | Browser engine, no GUI | Nothing — output arrives through code | Screenshots, PDF rendering, scripted test runs |
| Virtual machine | An entire operating system | A full desktop | Legacy software, complete system isolation, per-user workspaces |
| VPN | Nothing — traffic is routed through a gateway | Your own browser | Changing the network path your traffic takes |
| Browser profile manager | Nothing on desktop, or one session on a managed cloud | Your own browser, one isolated profile at a time | Many accounts, each with its own cookies, storage and fingerprint |
Compared with clientless remote desktop gateways such as Apache Guacamole or noVNC, Neko adds smoother WebRTC video, built-in audio and multi-participant control: several people watch the same session and one at a time holds the controls. It also supports RTMP broadcasting and session recording through nginx-rtmp. For the wider map of isolation models, see our comparison of virtual browser vs browser isolation.
Who Self-Hosting Suits — and Who Should Skip It
Self-hosting browser infrastructure converts variable per-action SaaS fees into a fixed infrastructure bill. That trade rewards steady, predictable demand and punishes spiky usage. Published cost modelling for browser-agent workloads puts the break-even point between 200,000 and 500,000 actions per month, depending on what a fully loaded engineering hour costs you. Over three years, ten self-hosted agents are modelled at roughly $45,000–$85,000 against $180,000–$360,000 for the SaaS equivalent. That arithmetic assumes steady demand: a virtual browser self hosted for occasional bursts keeps the fixed bill and loses most of the saving.
The maintenance half of the equation
The same model puts maintenance near 20 hours a week for self-hosted infrastructure versus about 2 for a managed service, with time-to-first-agent at two to four weeks against 15 to 30 minutes. If you are weighing rented desktops rather than containers, the cost shape changes again — our breakdown of hosted Windows desktop cost works through those numbers.
Three questions before you commit
- Is your monthly volume near that break-even band, or far below it?
- Does someone on the team already run Docker, TLS certificates and a reverse proxy?
- Do you need one shared screen, or a separate browser per person?
Run Virtual Browser Self Hosted in the Cloud With Send.win
Send.win’s cloud browser runs isolated browser profiles on a server in the EU — open a clean session from any device without installing anything:
- Instant cloud sessions – launch an isolated browser in seconds, no local install
- Isolated profiles – separate cookies, storage and fingerprint settings per session
- Cloud sync & profile sharing – pick up the same profiles on the desktop app (Windows, macOS, Linux) or share them with your team
- Residential proxies included – on Pro and Team, with timezone and locale matched to the proxy
You can try it right now: the Send.win demo browser opens an isolated cloud session directly in this browser tab. Paid plans start at $19/month, with a 7-day money-back guarantee on your first card purchase — see pricing.
Two yeses make self-hosting defensible. One or none means you are buying maintenance you did not budget for.
Where Neko fits well
- Steady demand: you run the same workload every week, so fixed capacity beats metered usage.
- Existing ops skills: someone on the team already runs Docker and a reverse proxy.
- Data residency: the session and its cookies stay on a server you control, in a jurisdiction you choose.
- One shared screen: onboarding a hire, demoing a tool, or watching a stream together in one browser.
Where it stops fitting
Neko is one screen, not a workspace per person. Everyone connected shares the same cookies, the same signed-in state and the same tabs, and whoever holds control drives. Teams that need each person in their own isolated browser — different cookies, different sessions, different fingerprint settings — need a different class of tool. The same goes for anyone without the appetite to patch, monitor and scale a container; a managed option is often cheaper than the third afternoon you spend debugging media negotiation. That trade-off is the subject of our cloud browser vs virtual machine comparison.
Sizing Your Server: CPU, RAM and Upload Bandwidth
The figures below are typical expectations reported by operators running interactive sessions, not guarantees from the project’s documentation. Use them as a starting point and measure your own load at the resolution you plan to run.
| Resource | Typical figure | What it means in practice |
|---|---|---|
| CPU per session | ~2 cores at 1920×1080 @ 30 fps; roughly half at 1280×720 | Two concurrent sessions need a 4-core box before headroom |
| RAM per session | ~2 GB | A 4 GB VPS runs one session comfortably, not two |
| Bandwidth per viewer | 3–5 Mbps at 1080p | Each viewer gets their own copy of the stream |
| 20 Mbps home upload | About 5 simultaneous viewers | Upload caps viewers; CPU caps sessions |
| Headless instance (for contrast) | 300–500 MB RAM each | 10 concurrent headless requests need 3–5 GB minimum |
Two numbers decide whether your deployment feels fine or unusable: cores per session and megabits per viewer. Multiply them. A 4-core server with a 20 Mbps upload can host two smooth sessions that five people watch each, and no more. Doubling the CPU without touching bandwidth buys you nothing, because the bottleneck simply moves upstream. That is the shape of every virtual browser self hosted on a VPS: cores set how many sessions can run, upload sets how many people can watch them.
Deploying Neko: A Practical Checklist
Work in this order and you avoid most rework.
1. Pick a Linux host and install Docker and Compose
Any mainstream Linux VPS works. Size it from the table above, add the operating system’s overhead, and leave room for one extra session. Deploy with Docker Compose rather than hand-rolled commands so variables, volumes and port mappings live in one reviewable file. A published walkthrough from Vultr’s documentation covers the Compose file, Traefik with automatic Let’s Encrypt certificates and persistent volume mounts end to end.
2. Terminate TLS before you expose anything
Put Traefik or Caddy in front of the container and let it handle certificates. This is not cosmetic: browsers refuse microphone and clipboard access on plain-HTTP origins, so the features you want most quietly stop working without a valid certificate. It also keeps the session cookie out of plaintext.
3. Forward the WebRTC UDP range on the host and the router
Media travels on UDP across roughly 100 contiguous ports, and that range has to be open on Docker and on any router in front of it. Pair it with a public IP declaration so the server advertises the right address during ICE negotiation. Keep the range narrow — a thousand open ports is a security problem, not a convenience.
4. Pin your image tag and match the variable names to it
Version 3 releases use names such as NEKO_WEBRTC_EPR, NEKO_WEBRTC_NAT1TO1 and NEKO_DESKTOP_SCREEN. Older guides use NEKO_EPR and NEKO_NAT1TO1. Mixing the two sets produces a container that starts cleanly and streams nothing. Pin an exact tag and read that tag’s release notes: the one public advisory, CVE-2026-39386, was fixed in 3.0.11 and 3.1.2, so a tag copied from an old blog post may still carry it.
5. Configure authentication levels deliberately
Neko has two roles. Admins can take control, kick or ban users; regular users can view, request control and chat. Give admin credentials only to people who need to moderate, and never reuse a password from anywhere else.
6. Add TURN, or plan for guests who cannot connect
Viewers behind carrier-grade NAT will fail to establish a direct WebRTC path. A TURN server such as coturn, wired into the ICE settings, relays those connections. If everyone who needs access can join a private network instead, a mesh VPN such as Tailscale removes router-level UDP forwarding altogether and keeps the whole deployment off the public internet.
7. Decide what persists
Mounting the Firefox profile directory keeps cookies and logins across restarts; skipping it gives you a clean session every time. Both are valid, but choose on purpose, because changing it later means rebuilding the container. And when you need to sanity-check any hosted browser before trusting it with real work, run through our checks to trust a secure virtual browser.
Common Mistakes That Break a Self-Hosted Virtual Browser
- Upgrading the image without updating the variables. A jump to a new major version silently renames settings. Pin the tag, read the release notes, change both together.
- Opening the TCP port and stopping there. The web interface loads, the login succeeds, and the screen stays black because UDP media never gets through. Check the router, not just the firewall.
- Assuming one session per user — and expecting per-user isolation. Everyone sees the same screen and whoever holds control drives it. If someone types while someone else holds control, nothing happens; that is not a bug. Per-person isolation means a different tool, such as self-hosted Kasm Workspaces.
- Leaving a public URL with a weak password. That is a browser on your network anyone can drive. Bind it to a private network or put authentication in front of it.
- Sizing by CPU alone. A fast server with a slow upload hosts two sessions beautifully and makes the fifth viewer unwatchable.
- Expecting streaming services to play. The standard images ship without content-decryption modules, so DRM-protected video refuses to start. No configuration changes that.
- Deploying from the wrong repository. With archived upstreams and republished forks, the README you copied may not describe the image you pulled.
Where Send.win Fits
Self-hosting solves one problem well: putting a browser somewhere your device is not, under your own control. It does not solve the other problem — running many separate browser identities side by side, each with its own cookies, storage, sessions, fingerprint settings and proxy. You cannot fix that by running more Neko containers per person, because the cost of each session is measured in cores and megabits, not in profiles.
Send.win is built for that second problem. It is a browser profile manager: every profile is isolated and keeps its own cookies, storage, sessions and consistent browser fingerprint — the same privacy protection idea you find in Firefox or Brave, applied separately to each profile. It runs two ways. Sendwin Browser is a native desktop app for Windows 10/11 (64-bit), macOS 12+ and Linux, installed locally and built on Chromium. The cloud browser runs profiles on Send.win’s server in Helsinki, Finland, from any device with nothing to install.
On pricing, Pro is $19/mo or $83.88/yr billed annually ($6.99/mo) with 150 saved profiles, 5 GB of proxy bandwidth a month and 6 seats. Team is $49/mo or $251.88/yr ($20.99/mo) with 500 profiles, 20 GB, 16 seats and page blocking in shared sessions. Residential proxies are included on both plans, and you can bring your own HTTP or SOCKS5 proxy. Share a profile with a paid teammate and it opens already signed in, without anyone trading passwords. Every plan allows up to 50 profiles open at once.
Two honest boundaries. Send.win is a hands-on tool: every profile is opened and driven by hand, in the desktop app or in the cloud browser, and there is no other way to operate it on any plan. And use Send.win only with accounts you own or are authorised to manage, following each platform’s terms. Where a platform limits multiple accounts, use its official route: Amazon requires approval for an additional seller account, and agencies working on Meta properties do it through Business Manager roles. A restricted account is fixed through the platform’s own appeal or verification process, never around it.
🏆 Send.win Verdict
A virtual browser self hosted on Neko is the right answer when you want one shared screen on infrastructure you control and you are happy to own its uptime. It is the wrong answer when what you actually need is twenty separate browser identities that never bleed into each other — Neko gives every viewer the same cookies on the same screen. Send.win covers that gap with isolated profiles, per-profile fingerprint protection, included residential proxies and paid-to-paid sharing, in a desktop app or from the cloud browser. To see the mechanics before committing to anything, the free cloud demo gives you 10 minutes a day with no card.
See Send.win plans — Pro from $19/mo with 150 profiles and proxies included, backed by a 7-day money-back guarantee on your first card purchase, or start with the free cloud demo.
Frequently Asked Questions
What is a self-hosted virtual browser?
It is a browser whose engine runs on a server you control rather than on your own device. The server renders pages and streams the screen to you, usually over WebRTC, while your keyboard and mouse input travels back. Neko is the most widely used open-source implementation, packaged as Docker images for Firefox, Chromium-family browsers and Tor.
How do I install Neko with Docker?
Install Docker and Docker Compose on a Linux host, then run the Neko container alongside a reverse proxy such as Traefik or Caddy for certificates. Forward the WebRTC UDP port range on the host and the router, and declare the public IP. Vultr’s published guide walks through the Compose file, HTTPS and persistent volumes in sequence.
Is a virtual browser the same as a virtual machine?
No. A virtual machine runs an entire operating system, including its own kernel, drivers and desktop. A virtual browser moves only the browser engine off your device, which is far lighter per session but gives you nothing outside the browser. A VPN is different again — it routes your existing traffic without moving any software.
Can several people use one self-hosted virtual browser at once?
Yes, but they share one screen. Everyone connected to that virtual browser self hosted on your server sees the same page and the same signed-in state, and whoever holds control drives it while others watch or request control. Neko also supports RTMP broadcasting and session recording. It is not a workspace per user.
How much CPU and RAM does Neko need per session?
Operator-reported figures are about two CPU cores and two gigabytes of RAM for a 1920×1080 session at 30 fps, with CPU use roughly halving at 1280×720. Each viewer then needs three to five megabits per second of their own stream. Those are expectations reported by people running it, not guarantees from the project.
Why does my self-hosted virtual browser show a black screen?
Almost always because WebRTC media is not reaching the client. The UDP port range must be forwarded on both Docker and any router in front of it, and the server must advertise the correct public IP. A second common cause is a version mismatch: version 3 variable names differ from older NEKO_EPR and NEKO_NAT1TO1 guides, and mixing them silently breaks the stream.
Does Neko keep browser profiles across restarts?
Only if you mount the profile directory as a volume. Mounting the Firefox profile folder preserves cookies and logins between restarts; without it, every restart gives you a clean session. Decide which behaviour you want before you deploy, because changing it later means rebuilding the container.
When should you use a managed cloud browser instead of self-hosting?
When demand is spiky, when nobody wants to own patching and scaling, or when the requirement is many isolated profiles rather than one shared screen. Managed options absorb session isolation, browser version management and retries as platform features, and they usually reach a working session in minutes rather than weeks.