Dashboard

The HLE dashboard is your central control panel for managing tunnels, API keys, access rules, and monitoring usage. Access it at hle.world/dashboard after signing in.

Overview

After logging in, the dashboard opens on Overview — a snapshot of your account: live usage counters, a 24-hour activity sparkline, a bandwidth ring, and the tunnels that are connected right now. Tunnels are managed under Connections and API keys under API Keys; neither list lives on this page.

Usage statistics

The top of the Overview displays live counters for the current billing period:

• Active Tunnels — connected ordinary tunnels, the same count as the Connections list (webhook receivers are counted separately)
• Requests this month — total HTTP and WebSocket requests
• Bandwidth this month — total data relayed through the server, in both directions
• Webhook Tunnels — connected webhook receivers

Your account tier is shown in the header bar (e.g. Free or Pay-as-you-go). All plan values (bandwidth, webhooks, log retention, share links) are configured on the server and displayed dynamically — see Pricing for the latest details.

Bandwidth counts the bytes the relay carries for you — uploads and downloads, HTTP and WebSocket. Traffic between devices on your own network never reaches the relay, so it never counts.

Free tier

• Unlimited tunnels and webhook tunnels
• 2 GB bandwidth/month (hard cap)
• 10 free webhook requests/minute
• 7-day access log retention
• Share links: 100 active, up to 7 days each

Pay-as-you-go (PAYG)

• Everything in Free
• 2 GB free/month, then credit-based bandwidth
• 10 webhook requests/minute free, then €0.50 per 1,000 requests from credits
• Up to 30-day access log retention

Share links are the same on both plans — they are not a paid feature.

Sign-up bonus

HLE runs a sign-up bonus from time to time. While it is running, the sign-up page, the pricing page and the landing page say so, with the amount. It is not always on, and the amount can change.

• Who gets it: each new account, once, after it verifies its email address. Accounts that existed before the bonus started do not get it, and a second account for the same person, or one made with a throwaway address, does not either.
• What it is: extra bandwidth, not credit. It does not change your plan, and it is not money — it cannot be used for webhook requests or withdrawn.
• When it is used: after your free 2 GB for the month, and before credits (Pay-as-you-go) or the hard cap (Free). On Pay-as-you-go, your credits are untouched until the bonus is gone.
• When it ends: when it is used up. It does not expire with the month; the Bandwidth card on the Overview and Billing pages shows how much is left. After that, your plan’s normal limits apply again.

API key management

API keys authenticate your tunnel clients (CLI or Home Assistant add-on) with the HLE relay server. Each key has its own tunnel limit and usage tracking.

Creating a key

Type a descriptive name (e.g. “Home Assistant”, “Dev Server”) and click Create Key. The raw key is shown only once — copy it immediately. The dialog also shows Quick Start commands to install the CLI and start a tunnel.

If you signed in a while ago, HLE first asks you to confirm it’s you — re-enter your password, or reconnect with your SSO provider. An API key outlives your session, so this keeps a stolen session from minting one.

Key table

All your keys are listed in a table showing the key prefix, active tunnel count, data in/out, and last-used timestamp. Click a row to expand key details.

Key details

Clicking a key row opens its detail panel with the key prefix, creation date, last-used time, active tunnel count, and Quick Start commands. You can delete the key from here — this revokes it immediately and disconnects any active tunnels using it.

Tunnel list

The Tunnels section shows every tunnel connected to your account:

• Subdomain — the public URL prefix (e.g. ha-sz9)
• Service — the proxied backend URL
• API Key — which key authenticated this tunnel
• Status — Active (green) or disconnected
• Latency — round-trip time to the relay server
• Requests — total requests handled by this tunnel
• Traffic — data in and out columns

Cleaning up inactive tunnels

Over time an account collects tunnels that were used once and never again. The Remove tunnels inactive for more than 7 days action (on the Connections page and the Tunnels page) clears those out in one step.

It first lists exactly which tunnels it would delete — offline tunnels whose last activity is older than seven days — and removes them only after you confirm. Tunnels that are currently connected are never touched, and neither are suspended ones, whose names stay reserved. The removal is recorded in your audit log.

Authentication

Sign in with GitHub, Google, or an email/password account. SSO providers link automatically — signing in with GitHub and then Google using the same email merges both into one account.

Per-tunnel access control

Each tunnel’s Access Control tab shows one ordered list of rules, in the order the relay evaluates them, with a sentence above it stating who can reach the endpoint right now. The first rule that matches decides.

• Sign-in: email + provider (any/github/google/hle) — the visitor signs in and is let through if their address matches
• PIN: a numeric code, no account needed
• Password: HTTP Basic Auth, checked before sign-in rules and the PIN, so setting one makes those unreachable
• Address: a visitor from an allow-listed address skips the gate — useful for a monitoring probe, which cannot sign in
• Share link: a temporary URL that lets anyone holding it in

Every rule can show the visits it was responsible for, and the last line — what happens to a visitor who matched nothing — has its own log of everyone turned away. Rules that are configured but can never be reached are shown greyed with the reason.

Defaults for every tunnel

These toggles are on the Tunnels page:

• Refuse unmatched visitors — on by default. A visitor matching no rule is turned away. With it off, a tunnel with no sign-in rule and no PIN is reachable by anyone with the address.
• Auto-protect new tunnels — on by default. The first time a service is exposed, a sign-in rule for your own address is added.

Webhook tunnels are exempt from refuse-by-default: they cannot use the sign-in gate, so refusing would leave them unreachable.

Admin panel

Admin users have access to additional management features:

• User management: View all registered users, delete users
• Audit logs: View all admin actions (logins, key creation/deletion, etc.)
• Registration toggle: Enable/disable new user registration globally
• Server settings: Manage system configuration
• Growth Offers: Manage the sign-up bonus (on or off, amount, optional expiry, daily ceiling) and discount coupons under Growth → Offers. Each coupon shows its discount, duration, how many times it has been redeemed and how many orders used its code, expiry and status.
• Growth campaigns: Create named campaigns under Growth → Campaigns, each with a channel, a destination path on hle.world, and optional utm_source, utm_medium and utm_campaign tags. Every campaign gets a short link at /go/<slug>; visiting it redirects to the destination with those tags appended, and the click is counted. The page also builds and copies the tagged destination URL and shows each link’s 30-day click count. Archiving a campaign makes its short link redirect to the homepage.

Growth Outreach

Growth → Outreach is a manual tracker for places worth asking for attention — repositories, awesome lists, threads, communities, creators, sponsorships and app stores. The Tracker tab groups targets by status (new, shortlisted, engaged, pr_opened, merged, listed, traffic, signups, declined, dismissed) and can filter them by kind, platform, status or a text search.

Each target has a stable external reference (owner/repo, a thread URL, a subreddit or a channel URL), an optional title, platform, fit score, next action date, notes and a link to a named campaign. Selecting a target opens a detail panel where its status can be moved in either direction, its campaign and next action changed, and events added to its log. A manual status move also writes a status_change event in the same transaction, so the target and its log cannot disagree. The Upcoming list shows targets with a next action, soonest first.

The Pipeline card at the top of the Tracker tab shows how many leads sit in each stage (new → shortlisted → engaged → pr_opened → merged/listed → traffic → signups) with the stage-to-stage conversion, plus the declined and dismissed side counts. Filter it by kind, platform or campaign; click a stage to filter the tracker list below it. Open on any row goes to that lead’s page at /admin/growth/outreach/<id>, which shows its full timeline of events — each badged auto or manual with its timestamp, note and link — and a manual move control that records a note with the move.

Leads move forward automatically. A background pass runs at the end of every discovery run and on demand from the tracker, and promotes a lead when its trigger is met:

• A pr_opened lead whose pull request is merged moves to merged; a PR closed without merging moves it to declined.
• A merged or listed lead whose campaign gets its first click moves to traffic.
• A traffic lead whose campaign gets its first attributed signup moves to signups.
• A lead at any earlier stage moves to listed when HLE is already named in the awesome list’s README.

Promotion only moves a lead forward and fires each trigger once: a lead an admin moves back by hand is not pushed forward again by the same signal, and every automatic move is written as an auto event (actor system). Manual moves in either direction stay available.

Contact details are deliberately limited to a published contact page URL. The API rejects an email address (including a mailto: link or an address inside a URL), so the tracker never stores personal contact data. Deleting a target removes its event log too. Untouched new and dismissed targets are purged after a year, along with their events; automated search-run records are purged after 90 days.

The Discover tab searches GitHub for new targets. Pick a query set — repositories by topic, issues asking for remote access, awesome lists, or all three — and Run discovery. The run happens in the background; results appear as targets with a 0–100 fit score, and Shortlist or Dismiss moves a target with one click. Each run is logged in the Recent runs table. Discovery only touches a fixed allowlist of public GitHub endpoints (repository and issue search, repository metadata and READMEs, and one discussion search); it never requests user profiles, commit history, issue authors, avatars or email addresses, and only a whitelist of response fields is stored. Set the GitHub token and the weekly toggle in the GitHub access card at the top of the Discover tab: a GitHub App installation token is recommended, and a fine-grained personal access token with public-repo read also works. The token is stored server-side and never shown again — the page reports only whether one is configured. Running discovery also happens automatically each week if the weekly toggle is on.

Growth Overview

Growth → Overview shows the attribution funnel over a date range (last 30 days by default), with source and campaign filters kept in the URL. The numbers come from an hourly rollup, not from live requests, so they can lag by up to an hour.

The funnel runs visit → register → verify → first tunnel → day-7 → paid. Each step is counted against the signups of its cohort:

• Visit — a click on a campaign’s /go/<slug> short link.
• Register — accounts created, grouped by the source and campaign recorded at signup. A signup with no attribution row is its own unknown bucket.
• Verify — of those, accounts whose email address was confirmed.
• First tunnel — of those, accounts that brought up a first tunnel or agent.
• Day-7 — of those, accounts with activity between 7 and 14 days after their first tunnel.
• Paid — of those, accounts with a paid credit purchase or a non-free subscription.

The flow chart draws each stage’s count as a band width, and clicking a source or campaign node sets that filter. Cells with fewer than three signups are withheld — a cohort that small is a person, not a statistic — and show as <3. The Deliverability card shows the Spamhaus ZEN/DBL status and the counts of hard bounces and spam complaints Postmark reported, with links to Reputation and Email for detail.

All admin actions are logged with timestamps and user info for auditability.