guides · how-to

The host admin panel

A tour of every page in the host UI — what each setting does, which ones the client can override, and which ones you should leave alone.

The host runs a small web UI on itself at https://127.0.0.1:48011/. It binds to loopback only — it is not reachable from your network, and no amount of port-forwarding will change that. An [admin] listen in host_config.toml can move it to another port, but not off this computer: any other address is replaced by 127.0.0.1. Open it from the Start Menu shortcut, or right-click the tray icon → Open Admin UI.

Your browser will warn about the certificate. That’s expected: the host generates a self-signed one on first run, because there is no certificate authority that will issue for 127.0.0.1. Click through.

The two passwords, which are not the same thing

This trips people up, so it’s worth being explicit. There are two, and they protect different things:

ProtectsSet at
Admin passwordThis web UISettings → Admin password
Connection passwordStarting a streamSettings → Connection password

The admin password stops someone at the keyboard from changing your host’s configuration. The connection password stops someone holding an already-paired laptop from opening a session. You set the admin one on first run; the connection one is optional and off until you set it.

A new admin password needs at least 12 characters. Signing in lasts 8 hours; changing the admin password signs out every other browser.

Setting the admin password for the first time takes a setup code: the first line of admin_setup_code.txt in the host’s data folder (C:\ProgramData\NearZero\ on Windows, which only administrators can read). Without it, whichever program on the computer reached this page first could have made itself the administrator. The first-run page names the file; the code changes each time the host starts and the file disappears once a password is set.

Dashboard

What’s happening right now: connected clients, which one is driving, session parameters actually in force, and whether a rendezvous is connected. Start here when something looks wrong — it shows what the host negotiated, which is often not what you asked for.

Pairing

Where you approve a client’s 6-digit PIN, and where you mint pairing tokens for remote setup. Tokens are listed with their ids so you can revoke one without touching the others.

Mint tokens last. A token embeds how to reach this host at the moment it was minted, so one generated before you enrolled a rendezvous bundle only works on your own network — see self-hosting the rendezvous. The page warns you when this applies; believe it.

Known clients

Every client whose key this host has pinned. A client whose public key isn’t on this list is refused at the Noise handshake — before it can say anything about itself.

Use Forget to revoke a device you no longer trust; that client has to pair again from scratch. This is the page to visit when you lose a laptop.

Identity

The X25519 keypair this host presents during the handshake, with its fingerprint. Paired clients have pinned this key, so rotating it forces every client to re-pair — there is no grace period. Read-only under normal use; treat it as a break-glass option.

Server settings

Listen address and pairing policy. Empty means “use the built-in default”, which is right for almost everyone. Change the listen address only if you need the host on a specific interface or a non-default port.

Capture settings

The capture backend, plus the geometry defaults. Worth understanding the split that runs through this page and the next: some knobs are host-only policy, and some are defaults the client overrides per session. Resolution and framerate live in the second group — the client asks for what it wants in its session request, and the host clamps it against the maximums here.

So if a client is streaming at a resolution you didn’t expect, this page isn’t where it was decided; the client asked and the host allowed it. Lower the maximum to actually constrain it.

Encoder settings

Encoder backend and its knobs, plus the bitrate cap and default.

The codec (H.264 or HEVC) is negotiated per session, not fixed here.

enable_aq, and the alarming graph it produces

Adaptive quantization spends bits where the eye looks, so detailed scenes hold up better at the same bitrate. It’s off by default — not because it’s expensive, but because of how it looks.

With it on, Task Manager’s GPU “3D” graph reads 50–100% for as long as you’re streaming. That is nearly all accounting rather than work: the driver runs the per-frame analysis as 3D-engine work, and Windows bills the time the context is resident rather than the time it is executing. Measured on one 1080p60 HEVC session, with the setting the only thing changed:

AQ offAQ on
Task Manager “3D”under 1%86%
Real GPU utilisation3%4%
Encoder load8%8%
Clocks / power1882 MHz, 42 W1882 MHz, 42 W

Same clocks, same power, same encoder load, same stream. If you’ve turned it on and come here alarmed by the graph, that’s the explanation — nothing is being wasted. Turn it off if you’d rather the graph stayed readable; leave it on if you want the quality and can ignore it.

Audio settings

Audio capture and Opus encode policy. Either way it streams what the host is playing, not what a microphone hears.

Changes apply on the next session reconnect; editing them mid-session does nothing until the client reconnects.

Transport settings

Wire-shape knobs. Leave these empty unless you know your path’s MTU is smaller than what QUIC negotiates — Wireguard, GRE, or IPv6 transition tunnels are the realistic cases. Guessing here produces problems that look like network faults.

Session settings

More than one client can hold this host at once. Exactly one drives the desktop; the rest receive video and audio, and everything that would change something — input, resolution, display selection, curtain, clipboard, file transfer — is refused on the host, not merely hidden in their UI.

One capture and one encoder feed everyone, so watchers inherit whatever the driver negotiated: a phone joining a 1440p60 session receives 1440p60.

This is not a permission system. Everyone who reaches this point already paired with this host. Watching is a role, not a security boundary — don’t hand a pairing token to someone you’d only want watching.

Privacy settings

Curtain mode blanks the host’s physical monitors for the length of a session while the connecting client keeps seeing the desktop, so you can work remotely without your screen being readable in the room.

allow_curtain gates whether clients may request it at all — the machine’s owner decides, not the remote user. See the curtain mode guide for what it does and doesn’t hide.

Files

Whose access file transfer uses. Only the client driving the session can transfer files; watchers are refused.

On a Mac the page offers only Off and On (the default). The host already runs as the user who started it, so there is no wider access to choose: On reaches the files that user can open.

In host_config.toml this is [files] access = "off" | "user" | "system"; a Mac’s On saves user, and system there acts the same. A file written by an older host may still say enabled = false (off) or enabled = true (signed-in user); saving this page replaces it. Changes apply from the next connection.

Rendezvous

Where you paste the nearzero-rdv2:… enrollment bundle so this host can be reached from outside your network. Covered end to end in self-host the rendezvous.

If you replace a bundle while the host is running, the page tells you the running host still holds the old one — re-paste to apply it live, or restart the host.

A note on empty fields

Across these pages, empty means “fall through to the default” rather than “zero” or “disabled”. If you want to change behaviour, set a value; if you want the built-in behaviour back, clear the field rather than hunting for the number that used to be there.