Orbien: a 5MB Rust NAT traversal tool with TCP, QUIC, KCP and WebSocket transports

What Orbien solves, and who ends up running it

Orbien is a reverse tunnel. A client process runs inside the private network next to the service you want to reach, dials out to a machine with a public address, and the server side accepts inbound connections that are forwarded back down that outbound connection. The README describes it as an "intranet penetration tool" and lists the proxy protocols it handles: TCP, UDP, HTTP, HTTPS and SOCKS5. The transport carrying the tunnel can be TCP, KCP, WebSocket or QUIC, with TCP multiplexing supported.

The audience is narrow and practical. You have a machine behind NAT or a firewall, you cannot or will not open a port, and you want that machine reachable from outside. The README's own first example is SSH: a tunnel named "ssh" exposing 127.0.0.1:22 on remote port 9000. That is the canonical use case, and it tells you the project is aimed at operators who already know what they want to expose and just need the plumbing.

The stated constraints are size and memory. The README puts the binary at around 5MB and says the project has "no GC pauses, and low memory usage". The workspace release profile backs the size claim up in a verifiable way: lto, codegen-units = 1, strip = true, panic = "abort", plus a separate release-size profile at opt-level = "z". Whether the resulting binary is exactly 5MB depends on your target triple, and the README does not break the number down per platform.

How the tunnel is actually put together

The workspace layout is the clearest description of the architecture available without reading source. Cargo.toml declares four members: core, client, server and desktop. There is also a server-ui directory, a client-java directory and a docker directory at the top level, none of which are workspace members.

core is the shared crate, and the workspace dependency list reads like a map of the data path. yamux 0.13 handles stream multiplexing over a single connection. quinn 0.11 provides QUIC, tokio-tungstenite 0.26 provides the WebSocket transport, and kcp-tokio 0.7 provides KCP. TLS comes from rustls 0.23 with the ring provider and tokio-rustls 0.26, with rcgen 0.13 available for certificate generation and tls-parser 0.12 for inspecting TLS handshakes. Authentication uses hmac 0.12 and sha2 0.10, which matches the README's "token-based tunnel authentication".

server is an axum 0.8 application, and rust-embed 8 is in the dependency list, which is how the web admin UI gets into the server binary rather than being served from a directory. server-ui is a separate front end built with npm, and the Makefile wires the two together: the web target runs npm install and npm run build inside server-ui, then prints "dashboard assets → server/assets". So the dashboard is compiled first and embedded second.

desktop is the Slint-based GUI client, and the Makefile has dedicated targets for it, including desktop-font-subset, which runs a Python script to trim fonts. That is a size-conscious choice consistent with the rest of the project.

The data flow, then: client dials the server over one of the four transports, authenticates with a token, multiplexes tunnel streams over that connection with yamux, and the server maps each incoming public port to a stream. The README does not document the reconnection strategy or what happens to in-flight streams when the underlying connection drops.

Installing Orbien and exposing an SSH port

The README does not give a package manager command. The Quick Start says to download the binary archive for your platform from the tags page and extract it. There is no cargo install line, no apt repository and no Homebrew formula in the README, so treat the prebuilt archive as the supported path.

The server side needs one setting. The README's example config is a file named orbien-server.toml containing a single listen key:

# orbien-server.toml
listen = "0.0.0.0:9527"

Start it with the -c flag pointing at that file:

./orbien-server -c orbien-server.toml

On the private machine, the client config names the server, then declares one or more tunnels. The README's example forwards local SSH to port 9000 on the server:

# orbien.toml
server = "127.0.0.1:9527"

[[tunnels]]
name = "ssh"
protocol = "tcp"
service = "127.0.0.1:22"
remotePort = 9000

Run it the same way:

./orbien -c orbien.toml

After both processes are up, connecting to port 9000 on the server host should land you on port 22 of the client host. Note the camelCase remotePort key: TOML keys here are not snake_case, and getting that wrong is a silent misconfiguration rather than a parse error if you add keys the loader ignores. The README does not state whether unknown keys are rejected.

If you would rather not touch TOML, the README points at Orbien-Desktop, a native GUI client, and the release page hosts it alongside the CLI binaries. The desktop build is a separate workspace member, so it is a distinct download, not a mode of the CLI.

Where Orbien is the wrong tool

The README is a feature list and a quick start. It is not an operations manual. Nothing in it describes high availability, leader election, or how two server instances would coordinate. If your requirement is that the tunnel survives the relay host dying, the README gives you nothing to plan against, and you should assume a single server process is the whole story until you find documentation saying otherwise.

The benchmark section deserves the same scepticism. It reports a macOS 26.2 arm64 environment on an Apple M2 with 16GB, links to a separate benchmarks repository, and states that the runs were on local loopback. The README says Orbien's "clearest advantage is lower and steadier memory usage under high concurrency" compared with frp. Loopback testing removes network variance, which is a reasonable methodology choice, but it also means the numbers say nothing about behaviour across a real WAN with packet loss. KCP and QUIC exist precisely because real networks are lossy, and the published charts do not cover that case.

There is also a scope question. The dependency list includes tls-parser and the README mentions "HTTPS supports transparent forwarding and client-side TLS termination". That is a meaningful capability, but the README does not explain how certificate selection works when you are terminating TLS on the client side, nor what happens with SNI-based routing. If your setup depends on that behaviour, the README will not answer your questions.

Finally, the client-java directory exists at the top level but is not a workspace member and is not mentioned in the README. Do not assume it is a supported, documented client.

Orbien against frp, and what the comparison really turns on

The README names frp directly in the benchmark section, so the comparison is fair game. The stated difference is memory behaviour under high concurrency, with the caveat about loopback testing above.

The architectural difference is more interesting than the memory chart. frp is written in Go, and Go's runtime carries a garbage collector. Orbien's README lists "no GC pauses" as a feature, which is a property of Rust rather than an Orbien-specific design decision, but it does change the shape of the binary: the workspace sets panic = "abort" and strips symbols, and the README puts the result at around 5MB. A Go binary of comparable feature scope will generally be larger, though the README does not give a frp binary size for comparison, so treat the size gap as directional rather than measured.

The transport story is where Orbien is more specific. It names four transports (TCP, KCP, WebSocket, QUIC) and the workspace dependencies confirm each one is a real crate dependency rather than a roadmap item. KCP over a multiplexed yamux session is an unusual combination and is aimed at links where TCP's congestion control behaves badly.

The honest counterpoint: frp has years of deployment write-ups, third-party guides and a broader ecosystem of configuration examples. Orbien's README does not link to a migration guide, a compatibility layer, or any comparison beyond the memory chart. Choosing Orbien means accepting a smaller body of operational knowledge in exchange for the smaller binary and the Rust runtime characteristics.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-15, two days before the date of this writing. Releases are frequent and versioned in lockstep: v3.4.0 on 2026-08-30, v3.5.0 on 2026-09-03, v3.6.0 on 2026-09-10. The workspace version in Cargo.toml is 3.6.0, matching the newest release, which suggests the version bump is part of the release process rather than an afterthought.

The upgrade cost is low if you use the TOML configuration shown in the README, because the surface is small: a listen address on the server, and server plus a list of tunnels on the client. The risk is that the configuration schema is not documented as stable. The README does not include a changelog, a deprecation policy, or a statement about backwards compatibility between minor versions, and VERSION.md at the repository root is not reproduced in the README. Read the release notes for each version before upgrading a production tunnel, and keep the previous binary around so you can roll back by swapping the file. The README does not document rollback, so that is a manual procedure you are inventing.

On licensing: the LICENSE file is Apache License 2.0, and the workspace manifest sets license = "Apache-2.0". Apache-2.0 includes an explicit patent grant and requires that you preserve notices and state changes. That matters if you plan to embed orbien-server in a product you distribute. It does not matter much if you are running it internally. This is a description of the licence text, not legal advice; if you are redistributing a modified build, have someone qualified read the NOTICE requirements.

Editorial conclusion

Orbien is worth a look if you run a small number of internal services and want a single small binary on both ends, with a TOML file you can keep in version control and a desktop client for people who will not edit TOML. It is the wrong pick if you need a documented HA control plane, a cluster of relay nodes, or a plugin system for custom protocol handling, because the README does not describe any of those. Before adopting it, verify three things yourself: that the released archive for your platform exists in the tags list, that the transport you intend to use (QUIC, KCP or WebSocket) is documented on the docs site rather than only named in the feature list, and that your token and TLS settings behave as expected when the server restarts. The licence question is settled: Apache-2.0 in both the LICENSE file and the workspace manifest.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. orbien-org/orbien on GitHub
3. Project website
4. README
5. Releases