localhost.run

What is localhost.run?

localhost.run is a tunneling service that exposes a web application running on your own computer to the public internet. It works through the SSH client you already have installed, so there is nothing to download and no account to create before you start a tunnel.

What it does

• Forwards traffic from a public URL to a port on your local machine, so someone else can open your work in a browser.
• Generates TLS certificates automatically, so shared links use HTTPS.
• Encrypts the tunnel between the public endpoint and your app.
• Can pass through encrypted TLS connections and non-HTTP protocols, not just plain web traffic.

Who it is for

• Developers who want to show a client or teammate a site that only exists on their laptop.
• People testing a responsive layout by opening their local app on a phone or tablet.
• Hobbyists giving a Raspberry Pi or similar device a public address without configuring a router or firewall.

Free tier versus custom domains

The free tier is the sensible starting point for a demo or a short test. The paid option matters when the address needs to stay the same, because a changing URL breaks bookmarks, webhooks and anything you have already shared.

A practical next step

Run a local server, then start a tunnel with your existing SSH client and open the resulting URL on another device. If you find yourself sharing the same link repeatedly, or a third-party service needs a fixed callback address, that is the point to consider the custom domain subscription rather than working around a changing URL.

How do I set up a tunnel with localhost.run?

You set up a tunnel with localhost.run by running a single SSH command from the computer where your web app is already listening — no download or account required. The service uses the SSH client that is already installed on macOS, Linux and most Windows systems, so the setup is essentially "start your app, then connect."

Basic setup

1. Start your local web application and note the port it listens on (for example, 3000 or 8000).
2. Open a terminal and run an SSH command pointing at localhost.run, forwarding that local port.
3. The service responds with a public HTTPS URL that you can open in any browser or send to someone else.

The exact command syntax is shown on the localhost.run homepage, so copy it from there rather than guessing the host or port flags.

What you get and what changes with a subscription

The page states that free domains remain free permanently, which makes the free tier a reasonable default for demos and testing. The paid tier is about identity and stability: a URL that doesn't change between sessions and that carries your own brand.

Practical scenarios

• Showing work to a client or teammate: start your dev server, run the SSH command, and paste the resulting URL into a chat. They see your local app without you deploying anything.
• Testing on a phone or tablet: open the public URL on the mobile device to check responsive layout and touch behaviour against your real local build.
• Giving a Raspberry Pi a public home: the page explicitly mentions this use case, useful for small self-hosted services on a home network.
• Non-HTTP traffic: the service notes that tunnels can pass through encrypted TLS connections and carry non-HTTP protocols, so it isn't limited to web pages.

Trade-offs to weigh

A tunnel exposes a service running on your machine to the public internet. That is convenient but means anyone with the URL can reach it while the tunnel is open — keep the tunnel running only as long as you need it, and don't expose admin panels or databases without authentication. Also consider that an SSH-based tunnel dies when you close the terminal or your laptop sleeps, which is fine for demos but not for anything that needs to stay up.

A good decision rule: use the free tier when the URL is disposable and you just need to show something now; pay for a custom domain when the same address needs to keep working across sessions or appear in documentation, client materials or a device you check regularly.

How much does it cost to use a custom domain with localhost.run?

A custom domain on localhost.run costs $9 per month when billed annually, per the site's own pricing note. The free tier does not include custom domains: it uses shared lhr.rocks subdomains that are free forever. So the cost question really has two answers: $0 for a temporary free subdomain, or $9/month (annual billing) for attaching your own domain or a stable lhr.rocks name.

What the paid custom-domain option adds

• Your own domain name, or a stable lhr.rocks address, tied to a tunnel
• Automatically generated TLS certificates, so HTTPS works without manual setup
• A consistent URL you can bookmark, share, or configure in third-party services

When the free tier is enough

If you are showing a local web app to a client for ten minutes, testing a webhook from your phone, or giving a Raspberry Pi a temporary public address, the free shared subdomain does the job. The URL changes between sessions, which is fine for one-off demos but awkward for anything you hardcode into a config file.

When $9/month makes sense

Choose the custom domain when the URL must stay stable: a staging environment your team hits daily, a device you monitor remotely, or a demo link printed in a proposal. At $9/month billed annually, the break-even is roughly one avoided hour of reconfiguring links and certificates per year — easy to hit if the tunnel is part of a recurring workflow.

Decision criterion

Ask whether anyone or anything stores your tunnel URL. If yes, pay for the stable domain. If the URL only ever gets pasted into a chat window once, stay on the free tier.

For current plan details and any changes to the annual billing requirement, check localhost.run directly before subscribing.

Can I use localhost.run with my own domain name?

Yes. localhost.run supports attaching your own domain name to a tunnel through a custom domain subscription, priced at $9 per month when billed annually according to the site. It also offers stable lhr.rocks subdomains if you don't want to bring your own. TLS certificates are generated automatically so HTTPS works without manual setup, and the tunnel itself stays encrypted to your app.

If you don't need a branded address, the free tier gives you a random domain for quickly sharing something running locally. If you do need a persistent, recognizable URL — for a client demo, a staging preview, or a Raspberry Pi you want to reach from anywhere — the custom domain subscription is the relevant option.

A practical decision check: use the free tier when the URL is throwaway and changes each session are fine; pay for a custom domain when the address needs to be stable, memorable, or tied to infrastructure you already own. Before subscribing, confirm your DNS provider lets you add the required records for the domain you want to attach.

For alternatives with comparable custom-domain tunnel features, see ngrok and Cloudflare (Cloudflare Tunnel).

Is localhost.run secure for sharing web applications?

Yes, with the important caveat that localhost.run secures the connection between the visitor and your machine, but it does not secure your application itself. The tunnel is encrypted, and HTTPS certificates are generated automatically, so traffic passing through the tunnel is protected in transit.

What the security actually covers

• Encrypted tunnel: localhost.run states that tunnels are encrypted to your app, so data travelling between the public URL and your local process is not sent in plain text.
• Automatic TLS: Secure certificates are generated automatically, which means HTTPS works without you configuring certificates manually.
• No account required: You connect using the SSH client already on your computer. There is no signup or download step, which reduces the exposure of credentials and installers, though it also means fewer account-level controls over who can reach a tunnel.

Where the limits are

• The tunnel protects the path, not the destination. If your local app has weak passwords, debug endpoints, or no authentication, anyone with the URL can reach those weaknesses over a perfectly encrypted connection.
• Free tunnels use shared-style domains, so URLs are easy to guess or stumble upon. Treat a public tunnel URL as public.
• A stable custom domain requires a subscription, which the site describes as $9 per month billed annually. A predictable domain is easier to share with clients, but it is also easier for scanners to find repeatedly.

A practical scenario

Suppose you are testing a checkout flow on a laptop and want a colleague to try it from their phone. Running ssh -R 80:localhost:3000 [email protected] gives you a public HTTPS URL in seconds. That is a good fit. But if the app is a staging admin panel with a default password, the tunnel's encryption will happily deliver attackers straight to it.

Next step

Before sharing any tunnel URL, confirm the app requires authentication, disable debug or admin routes you do not need, and close the SSH session when you are done. If you need a persistent, named domain for client demos, weigh the custom domain subscription against alternatives such as ngrok or Cloudflare Tunnel, which offer their own access-control features.

What are some advanced use cases for localhost.run beyond web development?

localhost.run is not limited to previewing a local web app. Because it forwards a raw TCP port over SSH, it can expose non-HTTP services and pass through encrypted traffic, which opens up several practical uses.

Non-HTTP and TCP services

• Remote access to a home machine: SSH into a desktop or Raspberry Pi behind a home router without port forwarding. The tunnel carries the SSH protocol itself, so you can reach a shell from anywhere.
• Game or voice servers: Hosting a small Minecraft, Terraria, or Mumble server for friends works if the protocol is plain TCP. The tunnel doesn't inspect or rewrite the traffic.
• Databases for collaboration: Temporarily exposing a Postgres or MySQL port lets a teammate connect with their own client. This is convenient but risky — see the trade-offs below.
• IoT and embedded devices: Giving a Raspberry Pi or sensor gateway a public endpoint so it can receive commands or push data without a static IP.

TLS passthrough

The page notes tunnels can "pass thru encrypted TLS connections." That means you can terminate TLS on your own machine rather than at the tunnel provider. A useful case is testing a service that requires end-to-end encryption, such as a local HTTPS API with client certificates, or a mail server doing STARTTLS. Your certificates and private keys stay on your hardware.

Custom domains and stable URLs

A custom domain subscription attaches your own hostname (or a stable lhr.rocks name) to a tunnel, with TLS certificates generated automatically. Beyond web development, this matters for:

• Webhooks: A stable URL lets a payment provider or Git host deliver callbacks to a service running on your laptop during integration testing.
• Long-lived endpoints: Devices or clients that can't be reconfigured every time the random URL changes.
• Demo environments: Sharing a named address with a client instead of a throwaway link.

Whose observations these are

The page itself is the source for the passthrough and non-HTTP claims; it does not document specific protocol support or limits. Treat the examples above as general advice about what a TCP tunnel enables, not as confirmed feature guarantees.

Trade-offs to weigh

A sensible next step: pick the least sensitive service first — an SSH shell or a test HTTP endpoint — and confirm the tunnel behaves as expected before exposing anything with credentials. For broader context on tunneling tools, see ngrok and Cloudflare Tunnel.