Runewarp is an ingress tunneling platform for securely exposing local services over outbound QUIC connections. Publish them without opening inbound ports at the Client or exposing its public IP, while preserving end-to-end TLS by default in passthrough mode.

CLI from crates.io:

cargo install runewarp

Container image from Docker Hub:

docker pull runewarp/runewarp

Choose the path that matches what you want to do:

• Evaluate locally: follow the tested Docker example
• Operate a self-hosted deployment: use the operator guide, then the configuration reference
• Understand the design: start with architecture and security

• TLS passthrough ingress tunneling — Server routes traffic by SNI without terminating TLS
• Privacy-respecting by design — Server never sees HTTP headers or application plaintext
• Traverse NAT and firewalls — Client uses outbound QUIC, so no port forwarding or public IP is required
• Self-hostable and operator-controlled — single Rust binary for both Client and Server
• Remain operationally simple — TOML config, a handful of CLI commands, and no companion daemon or database

• Server TLS termination — Server never decrypts or re-encrypts Visitor traffic
• HTTP-layer routing — no path-based routing, header inspection, or Layer 7 awareness of any kind

Runewarp is pre-1.0. Patch releases aim to stay low-risk, but minor releases may include breaking CLI or configuration changes.

flowchart TD
    V[Visitor]
    C["Client instance"]
    B["Local backend"]

    subgraph S["Server"]
        direction TB
        P["Public listener<br/>TCP 443 by default / Visitor TLS"]
        R["SNI router<br/>select Tunnel by Public hostname"]
        U["Tunnel listener<br/>UDP 443 by default / QUIC/TLS"]
        T["Active Tunnel connection"]

        P -->|"read ClientHello + SNI"| R
        U -->|"accept and authenticate"| T
        R -->|"open stream"| T
    end

    V -->|"Visitor TLS for a Public hostname"| P
    C -->|"establish QUIC/TLS"| U
    T -->|"deliver encrypted stream"| C
    C -->|"select Service and proxy"| B

Visitors connect to the public server over TLS, and each client instance keeps one or more long-lived QUIC tunnel connections back to one or more configured server addresses. The server routes by SNI and forwards the encrypted stream to the selected client, which then proxies it to the local backend. A service can opt into terminate mode when the client, not the backend, should terminate TLS. See docs/architecture.md for the detailed transport view.

How Runewarp compares to other tunnel tools:

A managed gateway focused on developer workflows, edge routing, and traffic policy.

• Runewarp Server only operates on TLS: no edge traffic policy, header inspection, or request transformation on the public Server.
• ngrok edge-side workflows: managed policy, routing, and developer ergonomics are part of the platform.

A managed connector into Cloudflare's edge, with routing and platform features built around that edge.

• Runewarp is fully operator-run: open source on both the Client and Server, self-hosted public ingress.
• Cloudflare fits managed-edge workflows: CDN, WAF, Access, DDoS protection, and other platform features come with the service.

A tailnet-based way to publish a local service publicly without exposing the device IP.

• Runewarp works with custom domains: explicit Server-side hostname ownership and no dependency on a tailnet, the Tailscale daemon, or *.ts.net names.
• Funnel for existing Tailscale users: the relay stays out of plaintext and the workflow is convenient when you already use that ecosystem.

A simple, open-source client/server tunneling tool whose config model and simple client/server architecture helped inspire Runewarp.

• Runewarp keeps routing explicit: one QUIC/TLS Tunnel connection per effective Server address and Server-authoritative routing by Public hostname. Configuration may be static or delivered over a separate Managed session to Control; Visitor traffic never shares that session.
• rathole supports more protocols today: service tokens, UDP forwarding, and more transport options.

• Docker example — verify the complete topology locally
• Operator guide — install, configure, start, verify, and troubleshoot

• Configuration reference — config shapes, keys, defaults, and validation
• Architecture — system structure, data paths, and current limits
• Security — trust boundaries, visibility, certificates, and deployment trade-offs

• Tunnel protocol — Tunnel wire behavior and runtime invariants
• Managed-session protocol — normative Control contract and interoperability checklist

• Contributing — development checks and documentation expectations
• Release guide — human release and recovery runbook
• Release automation — CI, publication gates, and artifact lineage

• Roadmap — forward-looking themes and live work

Licensed under Apache License, Version 2.0 (LICENSE).