Fork me on GitHub


expose local HTTP services online

Yet another solution to expose any HTTP server to the Internet through a tunnel. In many situations, tailscale or forwarding ports on your NAT box and Let’s Encrypt are better options.

Free & fully open source. Stable URLs derived from your SSH key. No accounts. Nothing to install outside Windows.

Got a server running on port 3000? Run ssh -R 1:localhost:3000 and it’ll respond with its public HTTPS URL(s), available until you close ssh with Ctrl-c or Ctrl-d, or get disconnected (see Staying up).

It fails with Permission denied (publickey).? You need an SSH key; use ssh-keygen -t ed25519. Another problem? Contact support.

If you forget the syntax, ssh prints an example.


Set up 2 tunnels, the first to localhost port 3000 and the second to port 80:

$ ssh -R 1:localhost:3000 -R 2:

Test the first tunnel with a single-request server:

$ printf 'HTTP/1.1 200 OK\r\n\r\nHello through!\n' | nc -l 3000 > /dev/null &
$ curl
Hello through!

GitHub & GitLab subdomains

If either GitHub or GitLab authorizes your SSH key for your login, we also expose your tunnels over correspondingly named URLs.

For example, for login jdoe:

(The discrepancy is due to insufficient constraints on GitLab usernames. We need to prevent collisions between users jdoe and eg jdoe--2, whereas GitHub does not allow repeating - in usernames.)

Note that this feature is optional and might not work out of the box:

Staying up

ssh eventually terminates when the connection is lost or the service restarted.

Load balancing

When there are multiple tunnels for a URL, client connections are spread between them randomly. We do not perform any health checks.


We do not record any of your traffic.

However, we log IPs & ports, SSH usernames & keys, connections, tunnels, and byte counts for up to 1 day.

Those logs never leave the server, and are only ever used for operational purposes and to troubleshoot reported issues.

We reserve the right to access your endpoint in the handling of abuse reports.


The Go backend runs on as a systemd service on a single instance and uses certificates provisioned by Let’s Encrypt using a systemd timer with a corresponding service where ExecStart=/snap/bin/certbot renew --agree-tos --manual --preferred-challenges=dns --post-hook /usr/local/bin/certbot-renewed --manual-auth-hook /usr/local/bin/certbot-auth (certbot-renewed restarts the backend and certbot-auth integrates with CloudFlare’s DNS API). I have plans to scale when it becomes necessary.

That’s it?

Non-HTTP protocols work too, as we only rely on the protocol to report errors.

The bandwidth used for your traffic is consumed twice. If sponsorships don’t cover operating costs and they increase significantly, heavy usage may require financial contribution to avoid throttling.

There are a lot of alternatives. As with, I hope you enjoy this simple take on a common problem. ❤️

That’s it.