FerroTunnel - High-performance embeddable reverse tunnel for Rust applications

announcements
1

Hi everyone! :waving_hand:

I'm excited to share FerroTunnel, a high-performance, embeddable reverse tunnel library for Rust applications.

What is it?

FerroTunnel lets you expose local services behind NAT/firewalls, similar to ngrok or Cloudflare Tunnel, but designed to be library-first and fully embeddable in your Rust applications.

Why another tunnel?

Most existing solutions are either:

  • SaaS-only with vendor lock-in
  • Standalone binaries that don't integrate into your app
  • Heavy on resources with Go/Node runtimes

FerroTunnel is:

  • Zero-copy where possible using Bytes and careful buffer management
  • Plugin-based - intercept and transform requests with custom middleware
  • Observable - built-in Prometheus metrics, OpenTelemetry, and a real-time dashboard
  • Embeddable - use as a library with Client::builder() / Server::builder() or as a CLI

Quick example:

use ferrotunnel::prelude::*;

#[tokio::main]
async fn main() -> Result<()> {
    // Server
    let server = Server::builder()
        .bind_addr("0.0.0.0:7835")
        .http_addr("0.0.0.0:8080")
        .build()?;
    
    tokio::spawn(async move { server.serve().await });

    // Client - expose local HTTP service
    let client = Client::builder()
        .server_addr("tunnel.example.com:7835")
        .subdomain("myapp")
        .upstream("http://localhost:3000")
        .build()?;
    
    client.connect().await?;
    Ok(())
}

Project status

Early but functional.

Looking for:

  • Feedback on API design
  • Performance testing on different workloads
  • Plugin authors (custom auth, logging, transformations)
  • Production deployment stories

Links

Roadmap

  • QUIC transport (UDP-based, better for mobile/unreliable networks)
  • WebSocket ingress
  • More builtin plugins (JWT auth, IP allowlisting)
  • Kubernetes operator

Would love to hear your thoughts, especially if you've built similar systems or have use cases I haven't considered!

4 Likes
2

Nice! I built one 10 years ago with C++ and Go for my IoT platform, with mobile clients for Android and iOS. Mine focuses on TCP long poll and message-based communication over TCP. It uses dual encryption keys for end-to-end message encryption.

My application can't use QUIC because maintaining self-signed TLS certificates isn't flexible, and UDP isn't power-efficient on mobile devices. While TCP keepalive can be implemented on network hardware (server NICs and Linux OS, smartphone wifi chips, and 5G modems), UDP can not.

1 Like
3

Glad to hear 10 Year ago, you must be so experienced, Currently i've only TCP but QUIC is in my roadmap. I suppose to work in Golang but curious to check rust performance and it out perform. ofcourse not C++ but yeah rust rid of many CVEs from C/C++.

4

My next version will be rewritten in Rust. It is time to switch.

5

I really appreciate your decision to rewrite the next version in Rust, that’s an exciting direction.

I’d love for you to take a look at Ferrotunnel and share your feedback. Please feel free to explore the project and contribute if you’re interested. It would be a pleasure to collaborate with you.