Nothing listens on the public internet.
Not on your laptop, not on your agent, not on your router. Both ends of every HLE connection dial out to the relay. There is no inbound port anywhere on your side, which means there is nothing to port-forward and nothing to firewall.
No inbound surface
Your agent holds an outbound WebSocket to the relay. Firepuncher clients do the same. An attacker scanning your IP finds nothing new open, because nothing new is open.
Auth enforced at the edge
The sign-in gate runs on the relay, before traffic is forwarded. Unauthorised requests never reach your network at all — they're rejected upstream of your services.
The agent decides, not the caller
Firepuncher targets are checked against a per-agent allowlist by the agent itself. Ask for something that isn't on the list and the agent refuses — the relay is not the thing being trusted.
Open-source client
The client and the shared library are MIT licensed. Read exactly what runs on your machine, build it from source, and verify what it does with your traffic.
Two kinds of secret, kept apart.
A person's API key and a machine's agent credential share the hle_ format but are deliberately different things with different scopes, so losing one doesn't imply the other.
| API key | Agent credential | |
|---|---|---|
| Prefix | hle_… | hle_… |
| Belongs to | You | One machine |
| Used by | hle tunnel create, hle firepuncher, hle tunnel | The agent service |
| Stored at | ~/.config/hle/config.toml | ~/.config/hle/agent.toml (mode 0600) |
| Shown | Once, at creation | Once, at creation |
| Revocable | Individually, from the dashboard | Per agent, from the dashboard |
Layers you can stack.
Every endpoint can be open, or gated by any combination of these.
SSO
Google or GitHub sign-in, built into the tunnel, alongside native HLE email and password. A rule can require one specific provider rather than accepting any of them.
Email allowlist
The addresses that are allowed through the gate, one rule per person. Optionally pinned to a provider, so google:you@acme.io only passes via Google.
PIN
A short numeric code for people you don't want to give an account to, checked after the sign-in gate. Useful for a one-off share with a neighbour.
HTTP Basic
A username and password enforced by the relay, for clients that can't do an interactive login — scripts, scrapers, an old TV app.
IP allowlist
Addresses or CIDR ranges that skip the gate entirely. Handy for your own home network or a fixed office egress.
Share links
Time-boxed, optionally use-capped URLs that expire on their own, so temporary access is actually temporary.
Transport
Everything rides one encrypted WebSocket to the relay, with automatic TLS on every public hostname. Certificates are issued and renewed for you.
Firepuncher does not terminate or inspect the stream it carries. SSH's own end-to-end encryption is unaffected — the relay moves bytes it cannot read.
What the relay retains
| Access logs | Who reached an endpoint and whether they got in: visitor IP, user agent, auth method, outcome. Kept for 7 days on the free tier and up to 30 on pay-as-you-go, and you can turn logging off entirely. |
| Traffic metrics | Bytes, request counts, and latency, aggregated per tunnel for your analytics. |
| Payload bodies | Not stored in normal operation. The one exception is a debug capture, which only you or an admin can start against a specific tunnel while investigating a fault. |
| TCP streams | Never inspected or stored. |
The full detail, including legal basis and retention periods, is in the privacy policy. Export or delete everything from Privacy & Data in the dashboard.
Reporting a vulnerability.
If you believe you've found a security issue in HLE — the relay, the dashboard, the client or the shared protocol library — email security@hle.world. Include enough to reproduce it: the affected component and version, the impact you believe it has, and any proof-of-concept or request/response pair.
| In scope | The relay and dashboard at hle.world, the MIT-licensed client and hle_common, tunnel access controls, and the tunnel transport. |
| Out of scope | Vulnerabilities in a service someone has chosen to publish through a tunnel, volumetric denial of service, and social engineering. |
| What happens next | We acknowledge your report, investigate, and keep you updated until the issue is resolved. |
| Safe harbour | Good-faith research under this policy is authorised. We will not pursue or support legal action against researchers who stay within it, and we will work with you on disclosure timing. |
Thanks to the people who told us.
Researchers who responsibly disclose an issue can be credited here, with their permission. The list is empty for now — being on it is opt-in, never automatic.
Read the client before you run it.
MIT licensed, on GitHub. Verify what touches your traffic rather than taking our word for it.