Admin panel
The admin panel is the web interface on your server's base domain (https://tunnels.example.com). It manages everything: tunnels, their tokens and sign-in rules, sign-in providers, visitor accounts, and security.
There is no separate login page in the panel itself — when the server asks for credentials you get the browser's login prompt (basic and htpasswd auth), a redirect to your identity provider (OIDC), or nothing at all (static auth). If a session expires while you are working, a red banner appears asking you to reload and sign in again.
The navigation bar
A single sidebar (a drawer behind the hamburger button on phones) lists:
- Agents — your tunnels
- OIDC — sign-in providers
- Users — built-in visitor accounts
- Groups — buckets of those accounts
- Security — currently blocked addresses
When you open a tunnel, its quick links (Overview, Connected, Tokens, Authentication) are pinned right under Agents until you navigate away.
Agents
The home page. It lists your tunnels with their sub-domain, a badge showing the sign-in rule (a green shield "OIDC" or "Local"; no badge means public), description, and last update time. The search box filters by sub-domain or description.
New agent asks only for a sub-domain — the lowercase name that becomes name.your-domain.com. As you type, the dialog shows the exact address the tunnel will be reachable at.
The edit dialog (⋯ → Edit) adds two advanced fields:
- Description — free-form note for yourself.
- Custom domain and Custom path — advanced rewrites: they change what the application behind the tunnel receives, not what visitors type. Custom domain replaces the
Hostheader your app sees (many apps check it and refuse to run under a foreign name); custom path puts a fixed prefix in front of every request path (for apps mounted under a sub-path). Neither changes the public address — visitors still come throughname.your-domain.com.
What your app receives when a visitor opens myapp.tunnels.example.com/photos:
| Custom domain | Custom path | Your app sees |
|---|---|---|
| (not set) | (not set) | Host myapp.tunnels.example.com, path /photos |
myhome.local:8080 |
(not set) | Host myhome.local:8080, path /photos |
| (not set) | /myapp |
Host myapp.tunnels.example.com, path /myapp/photos |
myhome.local:8080 |
/myapp |
Host myhome.local:8080, path /myapp/photos |
Deleting a tunnel removes its tokens and disconnects its agents — the confirmation dialog names them.
Inside a tunnel
Overview
Everything about the tunnel at a glance: its public address (copy or open it), custom domain/path if set, identifiers and dates, and the Stats section (speed in/out, ping, number of connected agents — switchable between the last hour, 24 hours, 7 days, and 30 days).
The Connect section builds the agent command for you: pick what you are sharing (a local port, a host and port, or a folder of static files) and copy either
- the one-line install command, or
- the plain connect command for an already-installed binary.
An "Upstream options" dialog explains all accepted forms in detail; the same information is in the agent guide.
Connected
Live connections, one row per connection: its number, the address it connected from, the token it used, open streams, latency, traffic, and how long it has been connected. Revoke on a token's row disconnects exactly the connections that used it — the confirmation names the addresses. To come back, just restart the agent with a valid token.
Tokens
Create a token for whatever should join this tunnel — one machine, or a whole fleet of identical agents sharing it. The panel shows the full token exactly once, in a dialog with a copy button and the one-line command pre-filled — after you confirm ("I've copied it") the full value is never shown again. Tokens can be renamed and deleted; deleting disconnects the machines using it.
Authentication
Chooses who may visit this tunnel: Public (anyone), OIDC (sign-in through one of your registered providers, optionally restricted to specific groups), or Internal (the built-in users and groups you manage in the panel). A "Forward authenticated user" switch controls whether signed-in visitors reach your app with their username in the X-User header. All the details — including the warnings about "nobody can sign in" setups — are in Authentication.
OIDC — sign-in providers
Register each identity provider once: label (e.g. "Google"), issuer URL, client ID, client secret (leave blank when editing to keep the current one), and scopes (default openid, profile, groups, email). The page shows two ready-to-copy redirect URIs to register at the provider: one with a * wildcard that covers all tunnels, and one for a specific tunnel. Pick the wildcard variant once and you never touch provider settings again when adding tunnels.
Users and Groups
These manage accounts for tunnels that use Internal sign-in.
- Users: login, password, display name. The detail page has the Activate/Deactivate toggle, membership management (quick add to a group, remove with one click), and the list of tunnels this account can reach. Deactivated users cannot sign in anywhere.
- Groups: named sets of users. The detail page manages members and shows the tunnels that grant access through this group. Adding someone to a group instantly grants them everything that group has — that is the point.
Security
Addresses that got temporarily blocked after repeated failed sign-in attempts on Internal-protected tunnels. Each row shows the address, when the block expires, and an Unblock button. An empty list means no one is currently locked out.