Ditching TCP - Subdomains, Modern UDP, and Developer Experience

Pivoting to a modern UDP architecture to fix Vite routing, hitting the wall with on-demand TLS, and why the ultimate DevTool feature is zero mental load.

Ditching TCP - Subdomains, Modern UDP, and Developer Experience

I have ditched TCP entirely and gone straight for the golden goose. TCP tunnels are proven to work, and I could have just aimed to offer a South Africa-first tunnel to fix the latency, but I want to fix the REAL problem.

The systemic issue isn’t just server location; it’s that no one has fundamentally changed the way tunneling is done at the L4 OSI layer for decades.

The Protocol Pivot

So, I built a Rust CLI and a Golang switchboard that speak modern UDP protocols instead. I also pivoted the switchboard to assign random subdomains, like big-red-duck.showcase.redduck.tech, instead of throwing random UUIDs after a forward slash. This is a much more scalable approach that entirely avoids the problem of interfering with client-side routing frameworks.

However, I got completely stuck on generating On-Demand TLS certificates for those subdomains and dealing with conflicting configurations on my VPS. I decided to take a healthy step back because burnout is real.

Instead of banging my head against the wall, I decided to get some dopamine hits by working on the UX of the website and making sure everyone can easily sign up for v1 via email when it’s ready.

Zero Mental Load

Taking that step back let me focus on the vision for the product as a whole.

I want to build a new generation of pipe that moves decades of edge cases, retry logic, and reconnection loops out of your applications, out of your mental load, and down into the L4 OSI layer where it belongs. This opens up a truly secure, safe, multiplexed channel for data transfer.

We use 100+ tools as developers. If you have to remember the 17 combinations of commands you need just so a tool doesn’t break, then it doesn’t deserve the space in your brain. I’m putting developer experience front and center. The best tools are so simple you don’t even have to think about them, and the best engineers use as many of those tools as possible.

Next week, we are moving into benchmarking this new UDP-based tunneling protocol using ToxiProxy 🚀

Oh, and today I launched the Showcase Development Blog! You’re reading it right now. Stay tuned…

Why TCP Tunnels Are Broken (And Building the First Prototype)

A look at the initial Showcase prototype, the limitations of legacy TCP connections, and the client-side routing bottlenecks that forced a total rethink of the transport layer.

Why TCP Tunnels Are Broken (And Building the First Prototype)

It started when I realized my SSH connection to a server was incredibly slow, kept disconnecting, and was still running on decades-old TCP connections.

I did some digging and found that while everyone in the industry has been entirely focused on AI, a bunch of massive announcements have been quietly made in the UDP protocol space.

These changes are paving the way for a fundamentally better way of connecting two machines across the internet, and I realized this was the exact wedge I needed to build a better tunnel.

The First Prototype

I got a VPS, set up auto-deployments, and built a Tauri application for Mac that sits quietly in your system tray at the top of your screen. You just select a port, click tunnel, and it does the rest.

Showcase Desktop Tauri App

Under the hood, it created a tunnel that was auto-upgraded to websockets to support Vite out of the box. I built this with a Rust CLI-first mindset, which talked to a Golang switchboard hosted on my VPS. At first, the switchboard just generated a random UUID for you, giving you a URL like redduck.tech/some-uuid.

Hitting the Edge Cases

But it didn’t take long to hit the reality of edge cases. That UUID path approach had massive issues, specifically messing with Vite client-side routing like Vue Router. It meant the whole architecture just wasn’t scalable for modern web apps.

On top of that, all the roundtrips to my overseas VPS on a shaky Wi-Fi connection meant Hot Module Replacement (HMR) was incredibly slow and frustrating.

I set up the most basic version of the showcase.redduck.tech website to get things moving, but I knew I had to go back to the drawing board on the transport layer.