How the tunnel.to idea got stuck in my brain...
I run a DNS company, and a few weeks ago one of my nephews was showing me his home setup and asking about local tunnels.
He already knew about Cloudflare Tunnels. I mentioned ngrok, localtunnel, etc., and then I started thinking about what a super-lightweight tunneling client might look like if it were optimized for the emerging wave of local AI agents, MCP servers, dashboards, and random services people are increasingly running on home networks and Mac Minis.
Then I remembered I owned the tunnel.to domain name.
At that point the idea kind of lodged in my brain and refused to leave until I built the thing.
Current state:
lightweight relay-based tunnel service
CLI-first
public relay nodes in North America + Europe
TLS
no account required for basic usage
intended to be dead simple to expose localhost services
Right now it’s centralized and still early, but I’m exploring:
self-hosted relays
private relays
agent-oriented workflows
lightweight auth/access controls
better relay selection/failover
Happy to answer questions about architecture, abuse handling, NAT traversal, relay topology, or where I think local-first AI tooling is heading.
(And yes, I told my nephew about it after it was done. He said “cool.” Hasn’t used it yet.)
This is a sharp direction because the timing is right: local AI agents, MCP servers, dev dashboards, and home-network services are all increasing the need for simple, trusted local exposure.
The strongest positioning is not just “another tunnel.” It is lightweight local infrastructure for the agent/MCP era: expose a service quickly, keep the setup simple, and avoid the overhead of heavier developer platforms when someone just needs a clean path from localhost to the outside world.
One thing I’d pressure-test is the brand frame as the product expands. tunnel.to is excellent as a domain and instantly explains the action, but if this becomes more than basic tunneling — private relays, auth, failover, agent-oriented workflows, self-hosted relay networks — the product may start needing a stronger infrastructure brand around it.
Davoq.com would fit that harder systems direction well if you ever separate the broader platform from the tunnel.to entry point. The current name is great for the first use case, but a stronger infra brand could carry the bigger vision if this becomes the local-agent connectivity layer rather than just a simple tunnel utility.
This is worth thinking through early because infrastructure products get remembered by trust and reliability, not only by what the first command does.