You are on a laptop behind café Wi-Fi, your API is on localhost:3000, and a client wants to hit a webhook right now. You could open ngrok, fight account limits, or explain why their IP is not in your firewall. Sometimes you just need a TCP pipe from the internet to a port on your machine — nothing fancier.
bore (ekzhang/bore) is that pipe. ~12k GitHub stars, ~400 lines of async Rust, MIT licensed. One binary runs the server; another command forwards a local port through it. No dashboard, no analytics suite, no "platform." Eric Zhang built it as the unopinionated cousin of ngrok and localtunnel: install, tunnel, go home.
What it actually does
bore forwards TCP. You run bore local 8000 --to your-server.example.com on the machine that has the service. bore picks (or you choose) a public port on the remote bore server and bridges traffic to your local socket. Webhooks, raw TCP health checks, a dev Rails server, a temporary SSH jump — if it speaks TCP, bore can expose it.
Architecture in plain terms:
- A control connection on port 7835 negotiates which remote port to open.
- When someone connects to that public port, the server asks your client to accept via a UUID handshake.
- Traffic flows; bore does not add HTTP routing or host-based multiplexing like ngrok's edge.
Public demo server bore.pub exists for quick tests. Production use is bore server on a VPS you control, then point --to at that host. Optional --secret (or BORE_SECRET) locks the server so random strangers cannot use your tunnel endpoint as a free anonymizer.
Why self-host a tunnel server?
Stop renting tunnel SaaS for internal work. ngrok and friends are great until you need stable hostnames, higher connection limits, or compliance that says "no third-party relay." A bore server on your Canadian VPS is one small process and a port range.
Predictable for dev teams. Everyone points at tunnel.dev.yourcompany.ca with the shared secret in env vars. No per-developer auth tokens scattered in Slack.
Minimal attack surface to understand. bore is tiny source you can read in an afternoon. That does not make it "secure by default" — see below — but it beats opaque edge proxies when your security reviewer asks what runs on port 7835.
Not a VPN replacement. bore is for "expose this one port for a bit." Site-to-site private networks are Netmaker/WireGuard territory. Mixing them up leads to exposing databases you meant to keep internal.
What running it takes
Server side: install the binary (releases, Homebrew, cargo install bore-cli, or Docker ekzhang/bore), run bore server --secret '…', firewall 7835 for control and your chosen --min-port/--max-port range for tunnels. Bind addresses can split control plane and public tunnel IPs if you need that layout.
Client side: bore local <port> --to your.server --secret '…'. Use --local-host if the service is on another LAN host, not loopback.
Security reality check: after the secret handshake, traffic is not encrypted by bore itself. Treat public tunnels like public ports — TLS on the app, SSH only with keys, never expose raw Postgres to bore.pub for a "quick demo." Rotate secrets, narrow port ranges, and turn the server off when the demo ends.
Resource use is negligible (a few MB RAM). The VPS cost is the point; bore is the kind of tool you run on the same CloudBox that already hosts staging.
Who it's for (and who should skip it)
Good fit: developers testing webhooks, contractors showing a local build to a client for ten minutes, homelabbers punching one service through NAT without configuring full reverse proxy rules, teams that want a self-hosted ngrok-lite on a $20 VPS.
Maybe skip it: if you need HTTPS termination, OAuth, request inspection, and pretty URLs — use Caddy, nginx, or a full tunnel product. If you need encrypted transport end-to-end without thinking, WireGuard or SSH -R with proper keys may fit better. If you will leave tunnels running unattended on production databases, please do not — use a real ingress with auth.
Hosting it in Canada
We run small Canadian VPS instances as shared bore endpoints for client dev teams — secret auth, tight port ranges, firewall rules, and the server stopped when the project ships. Pair with your normal staging reverse proxy when the feature graduates from "temporary hole" to "actual site."
Ask if you want a dedicated tunnel host or help drawing the line between bore for demos and VPN for production admin access. The tool is simple; the policy around it is not.
