Linux · Rust · single binary deploy

Forward ports,
without giving up control.

Run lightweight clients on the hosts that own your public ports. Push TCP and UDP forwarding rules from one server. Get permissions, rate limits, metrics, and audit out of the box, without reading, modifying, or decrypting the bytes that flow through.

Read the docsPerformance report
Portunus / dashboardreal-time
rules
01TCP*:8443 → svc.io:443ACTIVE
02UDP*:53000 → 10.0.4.7:53000ACTIVE
03TCP*:9000-9009 → edge.lan:9000ACTIVE
throughput
rule #01
3.2 Gbit/s
rule #02
640 Mbit/s
rule #03
180 Mbit/s
100M – 10G
Hits the offered rate end-to-end. Indistinguishable from a direct iperf3 baseline.
12.5G – 20G
With the splice fast path, the proxied flow stays within iperf3 noise of direct loopback and iptables REDIRECT.
Rate-limited rules
Bandwidth-capped rules stay on the canonical userspace path — byte-identical metrics, counters, and audit.

Everything a team needs around the rule, not just the rule.

Rule push, permissions, rate limits, metrics, and audit are first-class on the server, so you do not stitch them together yourself.

Rules

Forward TCP or UDP, single ports or ranges, to IP or DNS targets. Route HTTPS by hostname without decrypting the connection.

Access

Each user can be limited to specific clients, protocols, and port ranges. Rules are owned, and ownership is enforced on the server.

Limits

Cap bandwidth, new connections per second, and concurrent connections per rule or per user, so one edge host can be shared safely.

Visibility

Prometheus metrics, structured logs, an audit trail, an embedded SQLite store, and built-in backup / restore.

One server. Many edge clients.

You talk to the server from CLI, API, or the Web UI. The server pushes signed rule bundles to the clients that own the public ports. Your traffic flows directly through the client, never through the server.

YouCLI · API · UIServerrules + accessEdge Clientedge-1Edge Clientedge-2Edge Clientedge-3TargetTargetTargetrulesyour traffic

Performance you can plan around.

On Linux, plain TCP rules with no bandwidth cap use a kernel splice fast path. On the bench host, single-flow throughput doubles from 9.9 Gbit/s to 21.9 Gbit/s, and the offered-load sweep tracks both direct iperf3 and iptables REDIRECT to 95-109 % through 20 Gbit/s — the v0.11 saturation point disappears for uncapped TCP.

Performance report
100M – 10G
Hits the offered rate end-to-end. Indistinguishable from a direct iperf3 baseline.
12.5G – 20G
With the splice fast path, the proxied flow stays within iperf3 noise of direct loopback and iptables REDIRECT.
Rate-limited rules
Bandwidth-capped rules stay on the canonical userspace path — byte-identical metrics, counters, and audit.

Four steps from install to live traffic.

  1. 01Generate a one-time client enrollment command from the server.
  2. 02Run the client on the host that owns your public ports.
  3. 03Add forwarding rules from the CLI, HTTP API, or Web UI.
  4. 04Watch traffic, quotas, and rejects in real time, without touching user data.

Read the docs. Run the benchmark. Decide.

The performance report ships with the exact commands, raw numbers, and caveats so you can compare against your own bandwidth target before adopting it.

Open documentation