neko-rooms: a Docker-backed control plane for self-hosted n.eko browser rooms
Selfhosted collaborative browser - room management for n.eko
At a glance
- What is it?
- neko-rooms wraps the n.eko virtual browser in a room manager that starts and stops one container per room. It suits operators who already run Docker and want to give people a shared browser without hand-writing compose files. The design assumes a single Docker host, and the roadmap still lists upgrade, bearer-token and orchestration work as unfinished.
- Who is it for?
- Adopt neko-rooms if you already operate a Docker host and want each n.eko session to be its own container, and you accept that the project's own roadmap still lists an upgrade button, API bearer tokens and swarm or k8s support as open items. Do not adopt it if you need multi-host scheduling or a documented API authentication scheme today, since the README lists neither as finished.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 143 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap neko-rooms fills between n.eko and a running session
n.eko is the virtual browser itself. Running one is a per-instance job: an image, a set of environment variables, a port, and a reverse proxy entry if it should be reachable over HTTPS. That is fine for one session and tedious for several, because each additional browser means another container definition to write, start, label and eventually remove. neko-rooms is the layer that turns that repetition into a list. The README describes it as a simple room management system for n.eko and a self hosted rabb.it alternative, which sets the audience precisely: someone who wants to hand out browser sessions the way a chat server hands out channels. The project is written in Go and ships under Apache-2.0, with a web GUI visible in the screenshots under docs. The people who benefit are homelab and small-team operators who already understand Docker and want room creation to be a click rather than an edit to a compose file. The people who will not benefit are those who need one long-lived browser, since a single n.eko container plus a proxy is less machinery than a manager plus the container it starts.
One container per room, driven by the Docker daemon
The name is the architecture. A room is a container. When a room is created, neko-rooms asks the local Docker daemon to start an n.eko image, and the room list in the GUI is a view over those containers. The README's troubleshooting note confirms the coupling: if the image is not present locally, room creation fails with Error response from daemon: No such image. That error text comes from Docker, not from neko-rooms, which tells you the manager is issuing ordinary Docker API calls rather than running its own scheduler. Two configuration surfaces follow from this. The set of images a room may be built from is controlled by the NEKO_ROOMS_NEKO_IMAGES environment variable in docker-compose.yml, and per-room behaviour such as GPU use is set when the room is created, in what the README calls the expext settings. Storage is the third surface: mounting directories for persistent data is listed as a completed roadmap item, and the docs directory contains a storage tutorial. The roadmap also lists docker SSH / TCP support, docker swarm support and k8s support as unchecked. Read together, those entries say the current design assumes one Docker socket on one host. That is a real constraint, not a missing feature you can paper over with configuration.
Two installation paths: a scripted HTTPS stack or your own compose file
The README offers a guided path for people who do not want to assemble a reverse proxy. It assumes a VPS with a public IP running Ubuntu, a domain name pointed at that IP, and then a single downloaded script:
wget -O neko-rooms-traefik.sh https://raw.githubusercontent.com/m1k1o/neko-rooms/master/traefik/install sudo bash neko-rooms-traefik.sh
The script is described as securing the deployment with HTTPS through Let's Encrypt and Traefik or NGINX. The alternative path is manual: modify the variables in docker-compose.yml and run docker-compose up -d. There is also a community directory with installation guides for distributions such as Arch Linux and Fedora, which the README states are maintained by the community rather than the project. Whichever path you take, images must be pulled before rooms can be created:
docker pull ghcr.io/m1k1o/neko/firefox docker pull ghcr.io/m1k1o/neko/chromium
Updating the manager is docker-compose pull followed by docker-compose up -d. Updating the browsers is not the same operation. The README states that to update an n.eko image you must pull the new image and recreate every room that uses the old one, which means existing sessions do not silently move to the new build. For GPU rooms, NEKO_ROOMS_NEKO_IMAGES is reassigned to the nvidia-prefixed images, and nvidia-docker must be installed first; the README adds that GPU use is then selected per room in the room settings rather than globally.
Storage, GPU and the settings that are easy to miss
Two failure modes are documented rather than discovered. The first is the missing image error already quoted, which the README attributes to not pulling images in advance and links to issue #1. The fix is a pull, not a configuration change. The second is the message Mounts cannot be specified because storage is disabled or unavailable, which appears when storage has not been configured; the README points to a storage tutorial in docs. Both are the kind of error an operator meets once and then remembers, but they shape what you can promise users. Until storage is enabled, you should assume room data does not persist across container recreation, and the README does not claim otherwise. GPU is the third setting with a trap. Switching NEKO_ROOMS_NEKO_IMAGES to the nvidia images changes what is offered at creation time, but the README is explicit that you must then specify GPU use in the room's settings. An operator who changes the variable and expects hardware acceleration by default will not get it. None of this is hidden, but all of it lives in prose scattered across installation, storage and GPU notes rather than in a single configuration reference.
Where neko-rooms is the wrong tool
The roadmap is the most honest description of the project's boundaries, because it lists what is not done. An upgrade button is unchecked, so moving a room to a newer browser image is a manual pull-and-recreate cycle. Auto-pulling images that do not exist is unchecked, which is exactly the gap that produces the No such image error. Bearer token support for the API is unchecked, so the README does not describe an authentication scheme for programmatic access. Docker SSH / TCP, swarm and k8s support are all unchecked, which means the manager talks to a local Docker socket and does not schedule across machines. If your requirement is many rooms spread over a cluster, or an API you can call from CI with a scoped credential, this project does not currently offer either, and no amount of compose editing changes that. There is also a quieter limitation: because a room is a container, the resource cost of a room is the resource cost of a browser. Rooms are not lightweight multiplexed sessions sharing one process. On a small VPS, the number of concurrent rooms is bounded by memory and CPU long before it is bounded by anything neko-rooms does.
How this differs from running n.eko containers directly
The obvious alternative is to skip the manager and define n.eko services yourself in a compose file, one service block per browser, with your own reverse proxy labels. The difference is not capability but who holds the state. With hand-written compose, the set of rooms is a file you edit, and adding a room means editing that file and re-running compose. With neko-rooms, the set of rooms is whatever containers exist, and adding a room is an action taken through the GUI or the API, with the image list constrained by NEKO_ROOMS_NEKO_IMAGES. The trade is control for convenience. Hand-written compose lets you give each room bespoke volumes, networks, resource limits and proxy rules without fighting a manager's assumptions, and it does not add a component that itself needs updating. neko-rooms gives you a uniform creation flow and a single place to see what is running, at the cost of accepting its image list, its settings vocabulary and its single-host Docker assumption. If your rooms are few and dissimilar, compose is the smaller system. If they are many and similar, the manager earns its place.
Licence, maintenance and what an upgrade actually costs
The repository is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant, with the usual obligations around preserving notices and stating changes. That is a permissive licence and it is not a copyleft one, but this is a description of the licence text, not legal advice; if you redistribute a modified neko-rooms, read the licence yourself. On maintenance, the release history shows v1.6.5 in March 2026, v1.6.4 in September 2025 and v1.6.3 in April 2025, and the last push to master is dated April 2026. That cadence suggests a project that is maintained rather than dormant, but the README does not describe a support policy or a compatibility guarantee between neko-rooms versions and n.eko image tags. The practical upgrade cost sits with the rooms, not the manager. Updating neko-rooms is two compose commands. Updating the browsers inside existing rooms means pulling and recreating each room, and the README does not describe a migration path for room state during that recreation. Until storage is configured, assume there is nothing to migrate.
Editorial conclusion
Adopt neko-rooms if you already operate a Docker host and want each n.eko session to be its own container, and you accept that the project's own roadmap still lists an upgrade button, API bearer tokens and swarm or k8s support as open items. Do not adopt it if you need multi-host scheduling or a documented API authentication scheme today, since the README lists neither as finished. Verify first that the specific browser image you intend to use has been pulled locally, because the README records a No such image error when it has not, and confirm whether storage is enabled before you promise anyone persistent room data.
Community notes