Neko

• In the Azure Portal, search the Marketplace for Neko on Ubuntu 24.04 LTS by SecureAnyCloud, and select Create.
• Choose your subscription, resource group and region.
• Set the VM size to Standard_D4s_v5 or larger (see the sizing table above).
• Provide an administrator username and SSH public key.
• On the Networking tab, allow inbound HTTP (80). The media ports are added in Step 2, because the portal's basic networking tab does not offer them.
• Select Review + create, then Create.

Run these commands on your own machine. Replace the resource group, name and region to suit.

az group create --name neko-rg --location eastus
az vm image terms accept --urn sac1647283583153:neko-ubuntu-24-04:default:latest
az vm create \
  --resource-group neko-rg \
  --name neko-vm \
  --image sac1647283583153:neko-ubuntu-24-04:default:latest \
  --size Standard_D4s_v5 \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Open the three ports Neko needs. This step makes the media stream work:

az vm open-port --resource-group neko-rg --name neko-vm --port 80 --priority 1001
az network nsg rule create \
  --resource-group neko-rg \
  --nsg-name neko-vmNSG \
  --name neko-webrtc-media \
  --priority 1002 \
  --direction Inbound --access Allow --protocol '*' \
  --destination-port-ranges 59000 \
  --description "Neko WebRTC media, UDP primary and TCP fallback"

To restrict access to your own network instead of the whole internet, add --source-address-prefixes <your.public.ip>/32 to both rules. This is strongly recommended on a shared-control remote browser.

Connect over SSH:

ssh azureuser@<vm-ip>

Check the systemd units:

systemctl is-active docker.service neko-firstboot.service neko.service neko-postboot.service nginx.service

Every line should read active. A compose healthcheck manages the Neko container itself:

sudo docker ps --format 'table {{.Image}}\t{{.Status}}'

You should see the pinned ghcr.io/m1k1o/neko/firefox:3.1.4 image reported as (healthy).

Two passwords were generated for this VM alone on its first boot: one for the user role and one for the admin role. They are stored in a root-only file.

sudo cat /root/neko-credentials.txt

The file records these values:

Key Meaning

NEKO_USERNAME The display name for the standard role, SecureAnyCloud

NEKO_USER_PASSWORD The per instance password for the user role

NEKO_ADMINNAME The display name for the admin role, admin

NEKO_ADMIN_PASSWORD The per instance password for the admin role

WEB_URL The address to open in your browser

PUBLIC_IP The address this VM advertises to WebRTC clients

The file is 0600 root:root, so only root can read it. To confirm:

sudo stat -c '%a %U:%G' /root/neko-credentials.txt

Upstream Neko ships with fixed default passwords baked into the container image: a user password of neko and an admin password of admin. This image never runs on them, and you can prove that yourself.

Test both upstream defaults. Both are rejected:

curl -s -o /dev/null -w 'upstream default user password: HTTP %{http_code}\n' \
  -X POST http://127.0.0.1/api/login \
  -H 'Content-Type: application/json' \
  -d '{"username":"neko","password":"neko"}'
curl -s -o /dev/null -w 'upstream default admin password: HTTP %{http_code}\n' \
  -X POST http://127.0.0.1/api/login \
  -H 'Content-Type: application/json' \
  -d '{"username":"admin","password":"admin"}'

Both return 401.

Next, send an unauthenticated request to a protected endpoint. It is also rejected:

curl -s -o /dev/null -w 'no token: HTTP %{http_code}\n' http://127.0.0.1/api/whoami

This returns 401.

Your per-instance password, by contrast, authenticates and returns a session token:

curl -s -X POST http://127.0.0.1/api/login \
  -H 'Content-Type: application/json' \
  -d '{"username":"<NEKO_USERNAME>","password":"<NEKO_USER_PASSWORD>"}' \
  | head -c 120

The image also holds the browser back until that rotation has happened. neko.service carries a ConditionPathExists on a bootstrap marker that only the first-boot script creates, after it has written the new passwords. If first boot were ever to fail, the browser would not start at all, rather than starting on the published defaults:

grep ConditionPathExists /etc/systemd/system/neko.service

Finally, Neko's Prometheus metrics endpoint is unauthenticated upstream, and its labels carry live session identifiers. This image blocks it at the front door and keeps it available on the loopback interface for your own monitoring:

curl -s -o /dev/null -w 'metrics from outside: HTTP %{http_code}\n' http://127.0.0.1/metrics

This returns 404.

The WebRTC media is multiplexed onto a single port for both protocols. Check that it is listening:

ss -lntu | grep 59000

The address the VM advertises to clients is resolved on each VM's own first boot and never baked into the image. To see the value in use, run:

grep PUBLIC_IP /root/neko-credentials.txt 2>/dev/null || sudo grep PUBLIC_IP /root/neko-credentials.txt

The image ships a self-test that exercises the whole path end to end, from authentication through to the capture pipeline and the media transport:

sudo /usr/local/sbin/neko-roundtrip.sh

Open http://<PUBLIC_IP>/ in your browser. You are asked for a display name and a password.

Enter any display name you like. The password determines your role:

• NEKO_USER_PASSWORD signs you in as a user, who can watch the browser and request control
• NEKO_ADMIN_PASSWORD signs you in as an admin, who can additionally lock the room, kick users and take control back

Once connected, the streamed browser appears. This is a real Firefox running on the VM, not a screenshot or a rendered page.

If the interface loads but the screen stays black, the signaling worked and the media did not. That is almost always the firewall. Check that 59000/udp and 59000/tcp are open inbound (see Step 2).

Control is explicit rather than automatic, so two people cannot fight over the mouse. Click the keyboard or mouse icon in the bottom control bar to request control. As an admin, you can take it outright.

Once you have control, the remote browser responds to your mouse and keyboard exactly as a local one would. Press Ctrl+L to focus the address bar, type a URL and press Enter to navigate.

Everything you do happens inside the container on the VM, not on your own machine. Downloads land in the container, and cookies belong to the container. Closing your tab leaves the browser running for anyone else in the session.

Anyone who can reach the VM and has a password can join the same session. The side panel shows a chat and the session events, so you can see who connected and who currently holds control.

Give collaborators the user password and keep the admin password to yourself. An admin can lock the room to stop new logins and can take control back from any participant.

The settings tab adjusts your own view and, for admins, the room itself.

An admin can change the desktop resolution here at runtime. Lowering it is the quickest way to improve smoothness on a smaller VM. Raising it costs CPU.

Check the service status:

sudo systemctl status neko.service --no-pager

Restart the browser session. This discards the running browser's state and starts a clean one:

sudo systemctl restart neko.service

View the server logs:

sudo docker logs --tail 40 neko-neko-1

The passwords live in a root-only environment file. To change one, edit the file and restart the service:

sudo sed -i 's/^NEKO_USER_PASSWORD=.*/NEKO_USER_PASSWORD=<new-password>/' /etc/neko/neko.env
sudo systemctl restart neko.service

Keep /root/neko-credentials.txt in step with any change you make, or treat the environment file as authoritative from then on.

For anything beyond a trial, put a real hostname and a certificate in front of the web interface. Install a certificate with Certbot against the nginx site this image already ships, then reload nginx.

Keep two things in mind:

• HTTPS covers port 80 traffic only. The WebRTC media on port 59000 is not HTTP and is not proxied. It continues to flow directly to the VM, so leave those rules in place.
• Browsers require a secure context for some features, so serve the interface over HTTPS for any real deployment.

• Restrict the source addresses on both network security group rules to your own network. This is a browser other people can drive, so do not leave it open to the internet.
• Treat the admin password as privileged. An admin can take control at any time and can see everything on the shared screen.
• Remember the session is shared. Anything you type into the remote browser, including passwords you enter on websites, is visible to everyone watching. Do not sign in to personal accounts in a shared session.
• Rotate the passwords if someone leaves the group, using Step 13.
• Keep the OS patched. Unattended security upgrades are enabled on this image by default.

Neko is free and open-source software under the Apache-2.0 license. The streamed browser is Mozilla Firefox under the MPL-2.0 license. The container also includes standard Debian encoding components, libx264 and the GStreamer "ugly" plugin set. These are licensed under the GPL-2.0-or-later and are used unmodified as distributed by Debian.

This image is produced by SecureAnyCloud and is not affiliated with, endorsed by, or sponsored by the Neko project or the Mozilla Foundation. The Neko and Firefox names are used only to identify the software included.

For help with the image, contact SecureAnyCloud support, which is available 24/7. For questions about Neko itself, see the upstream project at github.com/m1k1o/neko.

Deploy on Azure

Launch Neko on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com