rustunnel: Self-Hosted Secure Tunnel Server in Rust with Pay-as-You-Go Managed Option

What rustunnel Solves and the Two Deployment Models

Tunneling tools create a publicly accessible URL that forwards traffic to a service running on a local port. The standard use cases are webhook development, exposing a local API for external testing, and sharing a local web server temporarily. rustunnel competes in this space with a self-hostable, open-source server and an official managed option. Both use the same client binary.

The README frames the trade-off directly: "Don't pay for idle time." The managed service uses pay-as-you-go pricing rather than a flat monthly seat fee. The free plan allows up to three tunnels with TLS/HTTPS. The pay-as-you-go plan at $3/month minimum plus $0.10/GB adds unlimited tunnels and custom subdomains. Self-hosting is free and also allows unlimited tunnels and custom subdomains once the server is deployed.

The managed service operates edge servers in three regions: Helsinki (eu), Hillsboro OR (us), and Singapore (ap). The client selects the nearest region by default. The --region flag overrides this. The legacy address edge.rustunnel.com is a CNAME to eu.edge.rustunnel.com and continues to work for backward compatibility.

Architecture: yamux Multiplexing over TLS WebSocket

The README includes an architecture diagram showing how traffic flows through the server. The control-plane WebSocket on port 4040 carries the TLS-encrypted connection from the client. HTTPS traffic on port 443 goes through the HTTPS edge, which routes it to the correct yamux stream, which the client receives and forwards to the local service. HTTP on port 80 redirects to HTTPS. TCP tunnel ports start at 20000. The dashboard and REST API run on port 8443.

Yamux is a multiplexing protocol that runs multiple independent streams over a single TCP connection. This means the client maintains one WebSocket connection to the server and the server routes traffic to different local services through that single connection using yamux streams. A P2P tunnel connects two clients directly without routing through the server's edge, using a shared name and a pre-shared secret for authentication.

The server is compiled from four workspace crates: rustunnel-protocol, rustunnel-server, rustunnel-client, and rustunnel-mcp. The Cargo.toml workspace file shows the key dependencies include tokio for the async runtime, tokio-tungstenite for WebSocket, tokio-rustls and rustls for TLS, yamux for stream multiplexing, hyper for HTTP/1 and HTTP/2, axum for the dashboard API, and sqlx for the database backing the dashboard. The workspace resolver is set to version 2, requiring Rust 1.76 or later. The server handles TLS termination at the edge; the client-to-server channel is always encrypted regardless of whether the local service uses TLS itself.

Installing and Opening Your First Tunnel

Getting started with the hosted service requires creating a free account at rustunnel.com and generating an API token from the Dashboard, under API Keys. The setup wizard selects the nearest region automatically:

rustunnel setup

With the token configured, opening an HTTP tunnel on port 3000 is a single command:

rustunnel http 3000

The client prints the public URL as soon as the tunnel is established. For TCP tunnels, for example to expose a local database:

rustunnel tcp 5432

For UDP, such as a game server:

rustunnel udp 27015

P2P tunnels connect two rustunnel clients directly, using a shared name and secret:

rustunnel p2p 27015 --name my-game --secret "shared-secret"

Custom subdomains require the pay-as-you-go plan and use the --subdomain flag. The --region flag connects to a specific edge server rather than the auto-selected nearest one.

Self-Hosting: Build Requirements and Production Setup

Self-hosting the server requires Rust 1.76 or later, pkg-config, libssl-dev, and Node.js 18+ only if you want to rebuild the dashboard UI. In production, you also need a Linux server running Ubuntu 22.04 or later with systemd, a TLS certificate and private key in PEM format (Let's Encrypt is recommended), a public IP with wildcard DNS for *.tunnel.yourdomain.com, and open firewall ports.

The Makefile provides a dev-setup target that creates a self-signed certificate and configuration in /tmp/rustunnel-dev for local testing. The standard build command is:

cargo build --workspace

The production deployment guide in the README covers eight steps: installing dependencies, building release binaries, creating a system user, installing the server binary, writing the server config file, obtaining TLS certificates via Let's Encrypt and Cloudflare, setting up a systemd service, and opening firewall ports. A Docker deployment path is also documented in docs/docker-deployment.md.

The server configuration uses a TOML config file. The port reference in the README lists all ports the server uses: 80 for HTTP redirect, 443 for HTTPS, 4040 for the control-plane WebSocket, 8443 for the dashboard, 9090 for Prometheus metrics, and 20000+ for TCP tunnel ports.

MCP Server and AI Agent Integration

rustunnel ships a crate named rustunnel-mcp that implements an MCP (Model Context Protocol) server. The README states that one-click setup is available for Cursor and provides a direct install link. For Claude Code, Claude Desktop, Windsurf, and other agents, the README points to an agent integration guide at rustunnel.com/docs/guides/agent-integration and a plain-text agent manual at rustunnel.com/agents.md.

The repository also includes a .plugin/ directory, an AGENTS.md file, a CLAUDE.md file, and a skills/ directory, indicating that the repository itself is configured as an agent-aware project. The .mcp.json file at the root configures the MCP server for local use.

This integration means an AI agent running in a supported editor can manage tunnels directly through tool calls rather than switching to a terminal. A developer whose AI coding agent needs to expose a local server for webhook testing or external API access can open and close tunnels from inside the agent session without leaving the editor.

The MCP server binary is rustunnel-mcp and is one of the four workspace crates in the Cargo.toml. It uses the same token authentication as the CLI client, so the same Talos account credentials work for both. The README does not detail the full list of MCP tools exposed by rustunnel-mcp, but the documentation links above cover the full API.

Monitoring, Limitations, and License

The server exposes a Prometheus metrics endpoint on port 9090. The dashboard on port 8443 provides a REST API and a UI. The Makefile includes targets for building and running the server with Docker Compose for local development, as well as a test target that requires a PostgreSQL database running via docker compose.

The production deployment requires managing wildcard DNS, TLS certificates, and firewall rules. The README covers each step, but the operational burden is real for teams with no existing Linux server infrastructure. The managed service at rustunnel.com removes this complexity entirely; the trade-off is that data passes through Talos infrastructure instead of your own servers.

rustunnel is released under the AGPL-3.0 license. AGPL-3.0 is a copyleft license with a network use clause: if you modify rustunnel and offer it as a network service, you must make the source of your modifications available. Running an unmodified rustunnel server for your own use or for internal company use does not trigger this requirement. Teams that want to build a commercial tunneling product on top of rustunnel without open-sourcing modifications should evaluate this constraint before adopting it.

The closest alternative is ngrok, which offers a similar tunneling service with a proprietary server. ngrok's hosted service has a free tier and paid plans, but the server software is not open-source. Teams who need source access, audit rights, or the ability to modify the server must self-host, and for that use case rustunnel provides a complete open-source server. The last release, v0.8.5, was published on 2026-09-03.

Editorial conclusion

rustunnel fits teams who want ngrok-like tunneling without per-seat licensing, or who need to self-host for compliance and data sovereignty reasons. The AGPL-3.0 license requires that modified versions you distribute also carry the same license; teams running it only internally are unaffected. The self-host path requires Rust 1.76+, a TLS certificate, wildcard DNS, and a Linux server running Ubuntu 22.04 or later, with ports open for the control plane and tunnel traffic. The managed service at rustunnel.com removes those requirements for the cost of $0.10/GB of data. Version v0.8.5 released on 2026-09-03 is the current stable release; check the release notes before upgrading from earlier versions because the protocol is under active development.

Frequently asked questions

Official sources

1. joaoh82/rustunnel on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases