Website: https://www.servbay.com Github: https://github.com/ServBay/ServBay Windows: https://github.com/ServBay/ServBay-Windows-Release
For years, I've wrestled with a persistent problem: reliably exposing local services to the public internet. We've all paid the "DIY tax" for this: fighting with NAT/CGNAT, configuring DDNS for a dynamic IP, and dealing with NET::ERR_CERT_INVALID warnings from self-signed certs, all just to test a Stripe webhook or show a demo.
Problem & Context
The core issue isn't a lack of tools, but their severe fragmentation. Each tool solves part of the problem but adds its own complexity:
Ngrok: The free tier's rotating URLs & rate limits break continuous testing. Advanced modes require digging into complex YAML.
frp: Powerful, but self-hosting frps is a project in itself (VPS, firewalls, daemons, SSL).
Cloudflared: Robust, but the setup is cumbersome, requiring Cloudflare auth, DNS management, and a steep learning curve.
This fragmentation means constant context switching and high cognitive overhead. We become part-time network admins instead of writing code.
Solution & Methodology
I built ServBay, a GUI app for macOS and Windows, to unify this chaos. It's not just a command-line wrapper, but a deep abstraction layer for these disparate protocols.
Unified Control Plane: ServBay provides a GUI to start, stop, and configure tunnels with a few clicks. It handles config parsing (YAML, TOML, CLI-args), process lifecycle (start, watch, graceful shutdown), and parses stdout/stderr to display status and public URLs. Intelligent frpc Client: For full control, we integrated frp. You still self-host frps, but ServBay acts as an intelligent client. Just fill in your server details in the GUI, and it manages the local frpc.toml for you.
Built-in PKI & Local HTTPS: To kill the local SSL headache, we built a PKI system. ServBay can generate a local Root CA and, with one click, install it into the system trust store (it handles the necessary privilege escalation). You can then issue browser-trusted SSL certs for any local project (e.g., my-app.dev). This is crucial for APIs requiring a Secure Context (like WebAuthn, Secure Cookies).
Trade-offs
Our main trade-off is Flexibility vs. Convenience. ServBay covers the 95% use case. If a tool releases a bleeding-edge feature, you'll get it faster via the native CLI than through our UI. We bet that for most developers, the productivity gain from avoiding config hell is worth that trade-off.
Results & Learnings
The biggest result is drastically reduced friction. What took minutes or hours of config & debugging now takes seconds.
A key technical lesson: cross-platform system-level interaction is hard. Reliably managing child processes, handling network configs, and securely modifying the OS certificate trust store is far more complex than it sounds. For instance, avoiding zombie processes on app exit required a deep understanding of each OS's process model and a lot of defensive programming.
If you've ever felt this pain, I built ServBay for us. The macOS version is out, and a Windows version is currently in beta. I'd love for you to give it a try. We're iterating quickly, and any feedback, especially from the HN community, would be invaluable.
I'm happy to discuss anything in the comments, from local dev environments and network tunneling tech to cross-platform GUI development.
Website: https://www.servbay.com Github: https://github.com/ServBay/ServBay Windows: https://github.com/ServBay/ServBay-Windows-Release
