I Got Frustrated with ngrok and Built My Own Self-Hosted Tunneling Tool
I've been running side projects and local dev environments for years. Every time I needed to expose a local service — test a webhook, share a WIP with a teammate, demo something to a client — I'd reach for ngrok. And every time, I'd hit the same walls.
The free tier gives you 1GB of bandwidth, one active tunnel, and a random subdomain that changes every session. Want a stable URL? That's $10/month. Want more than one tunnel? Pay more. Want to use your own domain? Enterprise tier. For something that's essentially forwarding TCP packets to my machine, it felt like I was renting someone else's infrastructure for a problem I could solve myself.
So I looked at alternatives.
The Alternatives Weren't Great Either
frp has over 100k GitHub stars, so I tried it first. Technically solid, but the TOML configuration is genuinely painful. I spent more time debugging my config file than actually tunneling. It works — but it doesn't respect your time.
Cloudflare Tunnel is free and powerful, but you're locked into Cloudflare's ecosystem. Their ToS restricts what traffic you can route, and when they had that 2.5-hour outage in June 2025, a lot of people (myself included) realized that depending on a single provider for access to your own services is a real risk.
bore and chisel are clean and minimal, but they're basic — no custom domains, no multi-tunnel management, no dashboard.
Pangolin (YC 2025) started promising but has scope-crept into a full zero-trust network access platform — WireGuard, OIDC, RBAC, multi-site management. Great if you're a sysadmin building enterprise infrastructure. Overkill if you just want to expose port 3000 on your domain.
What I wanted was simple: run one command, get a tunnel on my own domain, done.
So I Built Proxly
Proxly is a self-hosted tunneling tool that lets you expose local services through subdomains on your own VPS. Install it with npm and the interactive wizard walks you through everything:
npm install -g @a1tem/proxly
proxly
On first run, Proxly prompts you for your username, relay host, and secret token — then asks you to set up your first project and tunnels. Pick a name, point it at a port (or a full URL), and you're live at yourname-myapp.yourdomain.com.
Need to manage projects later? The CLI keeps it simple:
proxly add # create a new project
proxly delete # remove one
proxly reset # start fresh
Run proxly again and it auto-launches if you have one project, or gives you a picker if you have several.
The Architecture: Keep It Stupid Simple
The request flow is straightforward: Browser → Nginx (handles TLS on your VPS) → Relay server → WebSocket → Proxly CLI on your machine → your local dev server. The wire protocol uses JSON messages over WebSocket, supporting HTTP requests, WebSocket connections, and binary data.
You need three things on the server side: a VPS with a public IP, a domain with wildcard DNS pointed at it (so *.yourdomain.com resolves to your VPS), and Node.js 18+. On your local machine, you just need Node.js and the Proxly CLI.
Each tunnel maps a subdomain to a local port or target URL. Your config is personal and stays on your machine — set up once, and proxly just works every time you run it. If you're on a team, everyone gets their own username namespace, so multiple developers can tunnel the same project without stepping on each other.
What Makes It Different
I'm not trying to build a platform. Proxly is a tunneling tool. Here's where it stands compared to the alternatives:
vs. ngrok: Your domain, your infrastructure, no bandwidth caps, no session limits, no monthly fee. The tradeoff is you need a VPS (a $4/month Hetzner box works fine).
vs. frp: Same self-hosted approach, but Proxly aims for 60-second setup versus frp's multi-file TOML configuration. If frp's config has ever made you question your career choices, you'll appreciate the difference.
vs. Cloudflare Tunnel: No vendor lock-in, no ToS restrictions on traffic types, no dependency on a third-party's uptime for access to your own services.
vs. Pangolin: Proxly stays focused on developer DX — tunneling, done well. Pangolin is building toward enterprise infrastructure with VPN, identity management, and role-based access. Different tools for different users.
What's Next
Proxly is open-source and the self-hosted version will always be free. I'm working on a hosted tier for people who want tunneling without managing their own VPS — if that interests you, join the waitlist.
Right now I'm focused on nailing the developer experience: the install should be one command, the first tunnel should be live in under a minute, and the docs should answer your question before you have to ask it.
If you're tired of ngrok's limits, frp's config files, or depending on someone else's infrastructure for access to your own services — give Proxly a try and let me know what breaks.
GitHub: https://github.com/a1tem/proxly
I'd love feedback — especially if the install isn't as smooth as I think it is. The fastest way to help is to try the 60-second setup on a fresh VPS and tell me where you got stuck.
Top comments (1)
"I got frustrated and built my own" is one of the best origin stories for developer tools — you actually understand the problem space because you lived it.
The ngrok use case that pushed you over the edge is probably relatable to a lot of people: you're exposing a local LLM or Claude Code session to the internet and you don't want your traffic going through a third-party server you don't control.
Tangentially related: if you're using Claude Code or local LLMs via tunnels, the quality of the system prompts you send through matters a lot for what comes back. I've been building flompt (flompt.dev) — a visual prompt builder that structures prompts into semantic blocks and compiles to Claude-optimized XML. It also ships as an MCP server so Claude Code can call it without any tunneling needed:
claude mcp add flompt https://flompt.dev/mcp/Free and open-source.What's the GitHub repo for your tunneling tool? Would love to take a look at the implementation.