rustunnel CLI Client Guide — every flag, command, and config option
Complete reference for the rustunnel CLI client: installation, authentication, HTTP/TCP/UDP/P2P tunnel commands, region selection, config file format, and troubleshooting. The companion to the Quickstart and Self-Hosting guides.
This is the complete reference for the rustunnel CLI — every flag, command, and config option. New to rustunnel? Start with the Quickstart for a three-step walkthrough, or the self-hosting guide if you want to run your own server.
# 1. Get an auth token# → Sign up at https://rustunnel.com, then go to Dashboard → API Keys → Create token# 2. Create a config file interactivelyrustunnel setup# → prompts for region and auth token, writes ~/.rustunnel/config.yml# 3. Expose a local web server running on port 3000rustunnel http 3000# 4. Expose a raw TCP service (e.g. SSH on port 22)rustunnel tcp 22
After connecting, the terminal displays the public URL:
# Tunnel server address (required — choose a region)server: eu.edge.rustunnel.com:4040# Authentication token (required)auth_token: rt_live_abc123...# Skip TLS certificate verification — local dev ONLY, never use in productioninsecure: false# Region preference: auto (probe & pick nearest), or eu / us / ap.# Omit for self-hosted / single-server setups.region: auto# Named tunnel definitions used by `rustunnel start`tunnels: web: proto: http local_port: 3000 local_host: localhost # optional, defaults to localhost subdomain: myapp # optional, requests a specific subdomain api: proto: http local_port: 8080 subdomain: myapi database: proto: tcp local_port: 5432
Create (or overwrite) ~/.rustunnel/config.yml through a guided prompt sequence.
rustunnel setup
Prompts:
Prompt
Default
Description
Region
auto
auto (probe nearest), eu, us, ap, or self-hosted
Auth token
(blank)
Token issued by the server; leave empty to fill in later
Server address
(auto-resolved)
Only prompted when self-hosted is selected
Region behavior:
Choice
Server resolution
eu / us / ap
Auto-set to <region>.edge.rustunnel.com:4040
auto
Probes all regions, picks the nearest by latency
self-hosted
Prompts for your server address
Behaviour:
Creates ~/.rustunnel/ if the directory doesn’t exist.
If a config file already exists it is overwritten — a backup is not kept, so copy the old file first if you want to preserve it.
Writes a commented tunnels: block with HTTP and TCP examples so you can see the structure right away.
Prints Created: or Updated: with the full path when done.
Example session (auto region):
rustunnel setup — create ~/.rustunnel/config.ymlRegion [auto / eu / us / ap / self-hosted] (default: auto): Selecting nearest region… eu 12ms · us 143ms · ap 311ms · → eu (Helsinki, FI) 12ms Server set to: eu.edge.rustunnel.com:4040Auth token (leave blank to skip): rt_live_abc123xyzCreated: /Users/alice/.rustunnel/config.ymlRun `rustunnel start` to connect using this config.
Example session (self-hosted):
rustunnel setup — create ~/.rustunnel/config.ymlRegion [auto / eu / us / ap / self-hosted] (default: auto): self-hostedTunnel server address: tunnel.internal.corp:4040Auth token (leave blank to skip): my-tokenCreated: /Users/alice/.rustunnel/config.ymlRun `rustunnel start` to connect using this config.
After running setup, uncomment and fill in the tunnels: section then run rustunnel start, or use rustunnel http <port> / rustunnel tcp <port> directly.
Expose a local HTTP/HTTPS service through the tunnel server.
rustunnel http <port> [options]
Arguments:
Argument
Description
<port>
Local TCP port to forward (e.g. 3000)
Options:
Flag
Default
Description
--subdomain <name>
auto-assigned
Request a specific subdomain (e.g. myapp → myapp.eu.edge.rustunnel.com)
--server <host:port>
from config
Override the server address (bypasses region selection)
--token <token>
from config
Override the auth token
--local-host <host>
localhost
Local hostname to forward to
--region <id>
from config
Region to connect to: eu, us, ap, or auto. Ignored if --server is set.
--no-reconnect
off
Exit instead of reconnecting on failure
--insecure
off
Skip TLS verification (dev only)
Examples:
# Expose port 3000 — auto-selects the nearest regionrustunnel http 3000# Connect to a specific regionrustunnel http 3000 --region eu# Request a specific subdomainrustunnel http 3000 --subdomain myapp# Forward to a non-localhost servicerustunnel http 8080 --local-host 192.168.1.10# One-shot connection (exit on disconnect instead of reconnecting)rustunnel http 3000 --no-reconnect# Use an explicit server address (bypasses region selection)rustunnel http 3000 --server tunnel.example.com:9000 --token rt_live_abc123
Start all tunnels defined in a config file simultaneously.
rustunnel start [--config <path>]
Options:
Flag
Default
Description
-c, --config <path>
~/.rustunnel/config.yml
Path to a config file
Example:
# Use default config filerustunnel start# Use a custom config filerustunnel start --config /etc/rustunnel/production.yml
start always reconnects automatically (equivalent to running each tunnel without --no-reconnect). At least one tunnel must be defined in the config file or the command exits with an error.
When start is given two or more tunnels with the same (group, group_key), the server treats them as one logical pool — inbound traffic is dispatched to a healthy member at random. This is the path for running a hot-spare backend, scaling out a service horizontally behind a single subdomain, or doing zero-downtime rollouts.Add the load-balancing fields to each pool member’s tunnel definition:
server: tunnel.example.com:4040auth_token: "your-token"tunnels: a: proto: http local_port: 3000 subdomain: pool group: web group_key: shared-secret-for-this-pool health_check: type: tcp # Optional: when this group goes 0/N healthy, the server POSTs a # group_zero_healthy alert to this URL. Per-tenant — independent # of any operator-side webhook configured on the edge. alert_webhook: "https://hooks.slack.com/services/my-team/..."
Run a second client (on the same or a different host) with local_port: 3001, the same subdomain, and the same (group, group_key). Both clients register as members of the same pool; public connections to pool.tunnel.example.com are dispatched at random across them.
Load balancing requires [load_balancing] enabled = true in the server’s server.toml. When the flag is false (the default), the client’s group / group_key / health_check fields are accepted but ignored — both clients try to register as solo tunnels and the second one fails with subdomain '...' is already in use.
for i in $(seq 1 50); do curl -fsS https://lbtest.tunnel.example.com/ -o /dev/null -w "%{http_code}\n"done
Both backends should see roughly half of the requests.
6
Validate failover
Kill one of the local backends (Ctrl-C on its python3 process). The probe loop on that client marks it unhealthy after max_failed × interval_secs seconds; subsequent requests all land on the survivor. Restart the backend — the probe re-registers it as healthy and dispatch distributes again.
For the full reference (config field meanings, behaviour rules, observability series, limitations) see Load Balancing & Health Checks.
The region list is cached at ~/.rustunnel/regions.json for 24 hours. On expiry the client fetches a fresh list from GET https://<host>:8443/api/regions; if that fails it falls back to the hardcoded list compiled into the binary.