Skip to content

HTTP & HTTPS Tunnels

Share local web apps with a public HTTPS URL. Automatic TLS certificates, subdomain routing, custom domains. Works with any framework.

The quickest way to put something on the internet. Run one command, get a real HTTPS URL, and anyone (a client, a teammate, a webhook provider, your phone on mobile data) can reach the app running on your laptop. Works with React, Next.js, Django, Rails, Flask, Express, Laravel, or anything else that speaks HTTP.

Basic usage

localport http 3000 --token YOUR_TOKEN

Localport prints a public URL on a subdomain of tunnel.localport.dev. Both http:// and https:// resolve. The HTTPS URL is served with a real, browser-trusted certificate, so there are no self-signed warnings or extra setup.

The round trip adds a few milliseconds of overhead. For development, demos, webhook testing, and mobile QA, it's unnoticeable.

Custom subdomains

By default, Localport generates a random subdomain like abc123. On any plan, you can reserve a subdomain from the dashboard so your URL stays the same between sessions:

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

When to reserve a subdomain

Reserve a subdomain if you're using the URL in webhook configurations, OAuth callback URLs, or shared links that shouldn't change every time you restart the tunnel.

End-to-end encryption

Traffic from the browser to Localport's network is always HTTPS. The hop from our network to your machine is its own TLS 1.3 connection. For most apps that is plenty, since your dev server speaks plain HTTP locally and never sees the public internet directly.

If you need the bytes to stay encrypted all the way to your local server (for example, a service that already terminates TLS on a real certificate), use the tls protocol instead:

localport tls 3000 --token YOUR_TOKEN

Localport runs TLS pass-through: encrypted bytes flow straight to your local TLS server without ever being decrypted in transit. Your service handles the handshake and the certificate.

For stronger guarantees, such as restricting which clients are allowed to connect at all, see Locked tunnels, which adds mutual TLS on top.

Common use cases

  • Demo to a client. Share your work in progress without deploying anywhere.
  • Test webhooks. Point Stripe, GitHub, or Slack at your tunnel URL (webhook guide).
  • Mobile testing. Open the URL on your phone to test responsive layouts on a real device.
  • Team review. Share with teammates for quick feedback.
  • OAuth callbacks. Use a real HTTPS URL for redirect URIs during development.
  • AI tool callbacks. Provide a public endpoint for AI and LLM integrations that need a URL.

Next steps

Previous Configuration Next TCP Tunnels