HTTP & HTTPS Tunnels

Summary

Give a web app on your machine a public HTTPS link that anyone can reach over the internet, with one command. Create a tunnel in the dashboard, copy the command it builds, and get a real, browser-trusted URL like https://my-app.eu.localport.dev that stays the same across restarts. This guide walks the whole flow and how to secure it, step by step.

How an HTTP tunnel works#

An HTTP tunnel gives a web server running on your machine a public HTTPS URL that is reachable from anywhere. You run one command, Localport hands you a URL like https://my-app.eu.localport.dev, and requests to that URL are carried to your local app over a secure connection. It works with anything that speaks HTTP: Next.js, Vite, Django, Rails, Flask, Express, Laravel, or a plain static file server.

The connection is outbound from your machine to Localport, the same kind of connection your browser makes. There is no port to forward and no inbound firewall rule to add, so it works behind NAT, CGNAT, and corporate networks.

Both http:// and https:// resolve, and HTTPS is real

An HTTP tunnel serves your app over HTTPS with a real, browser-trusted certificate, so there are no self-signed warnings and nothing to install. Plain http:// requests resolve too, and you can send them to HTTPS automatically with one switch (see Force HTTPS).

To follow along you need a Localport account, the Localport CLI, and a web app listening on a local port. If you do not have an app handy, start a throwaway server on port 3000 with python3 -m http.server 3000.

Step 1: Create an HTTP tunnel in the dashboard#

Open dashboard.localport.io, go to Tunnels, and click New. The create panel slides in and asks for a few things:

Name. A label so you can tell your tunnels apart. You can rename it later.
Region. Where your tunnel is served from: EU, US, or Asia Pacific. Pick the closest one for lower latency.
Force HTTPS (on by default). Sends visitors from http:// to https:// automatically.

Give it a name, pick a region, and click Create.

Set up the tunnel, then the dashboard builds the exact command to run.

That is the only setup needed up front. Everything else has a sensible default and can be changed later from the tunnel's settings.

Step 2: Copy your connect command#

The moment the tunnel is created, the dashboard moves to the Connect step and builds the exact command to run. You can reopen it any time with the Connect button on the tunnel. Each control shapes the command:

Preset. Fills in the port for a known framework (Next.js on 3000, Vite on 5173, Django on 8000), or choose Custom.
Protocol. Leave it on HTTP for a web app or API.
Local Address. The address on your machine to forward to. Defaults to localhost; set something like 192.168.1.50:8080 to reach an app on another machine (see Forward to a service on another machine).
Custom Name. Labels the connection with --name.
No UI. Swaps the live status panel for plain log lines (--noui), for servers, CI, and Docker where there is no terminal to draw in.
Token. Your tunnel's secret key, already placed in the command. Treat it like a password.

Copy the finished command. For a web app on port 3000 it looks like this:

localport http 3000 --token tok_k8f2 --region eu

http is the protocol, for web apps and APIs.
3000 is the local port your app listens on.
--token authenticates the tunnel.
--region picks the region, matching the one you chose: eu, us, or ap.

The CLI reference documents every flag and form.

Step 3: Run the tunnel#

Paste the command into your terminal and press Enter. A second later the tunnel is live and the terminal turns into a status panel.

Run the command and the tunnel connects, with your public HTTPS URL under Forwarding.

The panel shows everything at a glance:

Forwarding is your public URL, the link you share.
Local is the address on your machine that traffic is carried to.
Region confirms the region you connected through.
Bandwidth and Connections update live as requests come in.

Leave the command running. As long as it runs, the URL is live. Press Ctrl+C to stop it; the public URL stops responding right away, and the tunnel and its URL stay saved to your account for next time.

Step 4: Open your public URL#

Your URL always takes the form <name>.<region>.localport.dev:

https://my-app.eu.localport.dev

Open it in a browser to confirm your app answers, then put it to work: send it to a client, open it on your phone over mobile data, or paste it into a webhook setting. See What you can do with the URL.

Your URL is static and stays yours

A standard tunnel keeps the same URL for as long as the tunnel exists. It does not change between restarts or sessions, so you can stop the tunnel, come back tomorrow, and share the exact same link. That is what makes it safe to paste into a webhook setting or an OAuth callback. To choose the word in front of the URL, set a custom subdomain in the tunnel's settings.

Secure your tunnel#

Open a tunnel from the Tunnels list and find the Network & Security section in its settings. This is where you control who can reach your HTTP tunnel and how. Change what you need and click Save.

The Network & Security section: IP allowlists on top, HTTP protection below.

Restrict who can reach it with an IP allowlist

Enter one or more IP addresses or CIDR ranges in Inbound IP Whitelist (for example 203.0.113.4, 198.51.100.0/24), and only those addresses can open the link. To everyone else the tunnel looks like it does not exist. Leave it blank to allow anyone. This is a good fit for locking a tunnel to a known office or server address.

Limit where the tunnel can start from

Network IPs restricts the other side: your app can only bring this tunnel online from the listed IP addresses or ranges, so a leaked token cannot be used to run the tunnel from somewhere else. Leave it blank to allow any location.

Put it behind a password with basic auth

Turn on Basic Auth and set a username and password. The browser then shows a login prompt before anyone can open your public URL. It is the quickest way to put a work-in-progress demo behind a shared password.

Send everyone to HTTPS with Force HTTPS

Force HTTPS redirects any plain http:// request to the secure https:// address before it reaches your app, so nothing is ever served in the clear. It is on by default.

Need per-device access control?

An IP allowlist and basic auth cover most cases. When you need every connecting client to prove its identity with a certificate you issued, use a locked tunnel, which requires mutual TLS before any request reaches you.

Forward to a service on another machine#

By default the CLI forwards to localhost. To reach a web app running on a different host on your network, a LAN box or a container, pass an explicit address with --local and the http:// scheme:

localport --token tok_k8f2 --local http://192.168.1.50:8080 --region eu

You can set the same thing visually in the connect sheet with the Local Address field. See the CLI reference for every form.

What you can do with the URL#

Once the tunnel is up, the URL works anywhere a public HTTPS address does:

Test webhooks. Point Stripe, GitHub, Slack, or Twilio at the URL and receive real events on your laptop. See the webhook guide.
Demo work in progress. Send the link to a client or teammate without deploying anywhere.
Test on real devices. Open it on your phone over mobile data to check responsive layouts and touch behavior.
Register OAuth callbacks. Use a real HTTPS redirect URI while developing against Google, GitHub, or any OAuth provider.
Give AI tools a callback. Hand an agent or LLM integration a public endpoint it can reach during development.

Frequently asked questions#

What is the difference between an HTTP tunnel and an HTTPS tunnel?

There is one tunnel, and it serves both. When you run an http tunnel, Localport terminates HTTPS with a real certificate and carries the request to your local app. You share the https:// URL; the http:// URL resolves to the same place and can be sent to HTTPS with the Force HTTPS setting.

Do I need my own SSL certificate?

No. Localport provisions and renews a real, browser-trusted certificate for every tunnel automatically. Your app can keep speaking plain HTTP on localhost while visitors reach it over HTTPS.

Does my tunnel URL change when I restart?

No. A standard tunnel keeps the same URL for as long as it exists, across restarts and sessions. You can set the word in front of it with a custom subdomain. This is what makes the URL safe to use in webhook and OAuth settings.

How do I password protect my tunnel?

Turn on Basic Auth in the tunnel's settings and set a username and password. Visitors get a browser login prompt before the public URL opens. To limit access by network address instead, use the inbound IP allowlist, and for per-device certificates use a locked tunnel.

Does Localport work behind a firewall, NAT, or CGNAT?

Yes. The tunnel is an outbound connection from your machine to Localport, the same as a browser request. There is no port to forward and no inbound rule to add, so it works on home routers, corporate networks, and mobile hotspots.

What happens when I rotate the token?

Rotating the token in the tunnel's settings generates a new one and stops the old one working immediately, so any connected client has to reconnect with the new token. The public URL and all other settings stay exactly the same. Rotate a token whenever it may have leaked.

Can I expose a database, SSH, or a game server this way?

Not with an HTTP tunnel. Those are not HTTP, so use a TCP tunnel instead.