What is Localport?

Summary

Localport gives anything running on your machine a public address, reachable over the internet on HTTP, HTTPS, TCP or TLS. One command puts a local port at an address like https://example-service.eu.localport.dev, with a browser-trusted certificate and no router settings to change. You choose who may open it, from your whole team down to one named machine.

Localport is a tunneling and identity-based remote access platform. A small agent runs on a machine that can reach your service and holds an encrypted outbound connection to Localport. Traffic sent to your public address reaches your service through that connection. No port forwarding, no firewall rule, no static IP address.

The machine needs nothing but an outbound internet connection. That covers a home connection behind carrier-grade NAT, a phone hotspot, an office where nobody is going to change the firewall for you, and a device on a mobile network that will never have a public IP address.

The agent is the only Localport code that runs inside your network, and it is open source under the Apache 2.0 licence. You can read it, build it, and check what it does before it goes near a work machine or a customer's hardware.

What is Localport used for?#

Localport covers two jobs, and plenty of teams use both.

A public address for something local. A web app a client wants to look at. A webhook endpoint Stripe can post to. A game server your friends join. A demo you would rather not deploy first. You get an address, you share it, and it answers from any browser or tool on the internet.

Remote access to the machines you have deployed. A customer's appliance on their site, a line of sensors in a factory, a fleet of kiosks, a database inside an office network. Each machine gets its own name and its own address, and nothing reaches it until you allow it. There is no client software to install on the far end and no inbound firewall rule anywhere.

What can go behind a tunnel?#

Anything that listens on a TCP port. Localport forwards bytes and does not care what produced them. UDP is not carried.

Protocol	Use it for
`http` and `https`	A web app, an API, a dashboard, a webhook endpoint, a local model server such as Ollama
`tcp`	Postgres, Redis, SSH, a Minecraft server, a Modbus PLC on a plant network, a label printer
`tls`	A service that holds its own certificate and terminates its own encryption

The service does not have to sit on the machine running the agent. Point the agent at another host on the same network, and traffic reaches that one instead.

Full reference: CLI.

How to create a tunnel#

Three steps, and only the last one repeats.

1. Create the tunnel at dashboard.localport.io. Give it a name and pick a region. You get a token and a fixed public address.

2. Install the agent on a machine that can reach your service. It is one binary with no runtime beside it. See Installation.

3. Run it against the local port.

localport http 3000 --token YOUR_TOKEN --region eu

The agent after it connects, showing the public address and the traffic it is carrying.

Your service is now answering at its own address.

https://example-service.eu.localport.dev

HTTPS uses a publicly trusted certificate. Browsers show no warning, and strict clients such as webhook senders and mobile apps accept it. There is nothing to install locally and nothing to renew. New tunnels have Force HTTPS switched on, so a plain http:// request redirects to the secure address.

The address belongs to the tunnel and not to the session. Stop the agent, restart the machine, come back a week later, and the same address is waiting.

Detailed guide: Quick Start.

Choosing your own address#

Yes. A standard tunnel gets a fixed address the moment you create it, and you decide what that address says.

Pick the subdomain. Type the label you want, and the dashboard tells you whether it is free before you save.
Bring your own domain. Add one CNAME record and serve the tunnel on a domain you own instead. Start the domain with *. to make it a wildcard, which also gives every device on a fleet an address under your own name.
Reserve a TCP port. A TCP tunnel takes a port per session by default. Reserve one and it stays yours, so a connection string you handed out keeps working.

Detailed guides: Custom Domains, TCP Tunnels.

Which tunnel type to use#

A standard tunnel covers most work. The other two cover a team sharing one incoming stream, and machines you have deployed and reach one at a time.

Type	How traffic arrives	Use it for
Standard	One device answers each request	A single app, database or server
Fanout	Every connected device receives a copy of each request, over HTTP	One URL the team registers once, so every teammate gets a copy
Fleet	Devices are addressed by name, and every caller presents a client certificate	Deployed machines, such as sensors, gateways, appliances

Standard and Fanout are delivery modes of one tunnel. Switching between them keeps the URL, so a link you already handed out still works. Fanout carries HTTP only.

A fleet is a different object and converts to neither mode. Every caller on a fleet presents a client certificate, and there is no switch to turn that off. A fleet carries HTTP and TCP, and refuses TLS passthrough.

To put a single service behind client certificates, make a fleet with one device.

Detailed guides: HTTP Tunnels, Fanout Tunnels, Fleets.

Who can reach your tunnel?#

By default, anyone holding the address. It is not guessable, and it is not a secret either, because anything pasted into a webhook form or a chat thread can be forwarded on.

Four controls sit in front of a tunnel. Each can be switched on while the tunnel is running, and they stack in the order shown.

Control	A caller must have
IP Allowlists	A connection from an address or range you approved
Basic Auth	A username and password
Header Authentication	A header value you choose, on every request
Webhook Verification	A valid signature from GitHub, Stripe, Shopify or Slack

The first refusal ends the request, and your machine never sees it.

How to give secure remote access to your machines#

Put them in a fleet. A fleet is private by default: every caller presents an identity that proves who they are, and a grant must allow that identity before it reaches any machine. An identity with no grant reaches nothing.

Grant to	Covers
Everyone	The whole team, including people who join later
Role	Owners, admins or developers
Member	One person on the team
Machine	A server, device or pipeline

Each grant names what it reaches: one device, a name prefix such as gw-*, or the whole fleet. Grants add up, and there are no deny rules.

A grant can name a role instead of a list of people. A new engineer inherits the access their role already carries, and off-boarding one person removes it everywhere at once.

How an identity proves itself depends on what it is.

A person signs in and gets a short-lived certificate. Signing in again is the renewal, so there is nothing to rotate.
A machine redeems a setup key once, then keeps its own certificate renewed for as long as it runs.
A CI pipeline uses the token its own platform already mints. No secret is stored in the repository, the CI settings or the runner.

Your private keys never reach us. Every certificate starts as a signing request made where it will be used, on the machine itself or in your browser. The key stays there. If your organisation already runs its own certificate authority, register that instead and we hold only its public certificate.

A person's certificate carries no contact details. It names a random account identifier, never an email address.

Your access log records every connection to a device, allowed or refused, and names the identity behind it. You can export every entry matching your filters as CSV.

Withdrawing access takes effect at once. Removing a grant, revoking a certificate and removing a device each close the live connections they affect.

Detailed guides: Remote Access, Grants and Access, CI/CD with OIDC.

Does Localport read your traffic?#

No. Payloads are not logged, not indexed, not sold, and never used to train a model.

Your traffic stays in the region you chose. A tunnel is pinned to EU, US or Asia Pacific when you create it, and traffic for an EU tunnel is never carried through another continent.

How much of a request Localport handles depends on the protocol.

TCP and TLS. Bytes are forwarded. We hold no key for the stream and never see inside it.
HTTP. Enough of the request is read to route it. The body is forwarded.
HTTPS and fleets. The request is decrypted in memory only long enough to forward it, re-encrypted on the way to your agent, and never written to disk.

What gets recorded is the shape of a connection. When it opened and closed, how many bytes and requests it carried, which identity opened it, and which device it reached.

Changes your own team makes are recorded separately in an audit log: who rotated a token, who wrote a grant, who revoked a certificate. Both logs depend on your plan. See pricing.

Full detail: Privacy Policy.

What runs inside your network?#

The Localport agent, and nothing else. It is a single binary for macOS, Linux and Windows, on Intel and ARM, with no runtime to install beside it. The same binary runs on a laptop, in a container, on a Raspberry Pi and inside a CI job.

It writes nothing to disk unless you give it a credential to keep. A tunnel authenticated with a token stores nothing. localport setup and localport login write a certificate under ~/.localport, with directories at mode 0700 and files at 0600, and the private key beside it is generated on that machine.

The agent also refuses to read a key file looser than 0600, and tells you which file it refused.

All of this is checkable against the source. The install script compares the download against the published SHA-256 checksum and aborts on a mismatch.

Which guide matches what you are building?#

IoT Device Management. A deployed fleet of sensors, cameras or controllers, each addressed by name.
CI/CD Preview Builds. A live preview URL for every pull request.
Webhook Development. Stripe, GitHub, Slack and Twilio deliveries, arriving on your laptop.
Expose a Local LLM. Ollama or LM Studio, reachable by another device or app.
Game Server Hosting. Minecraft and Terraria, with no port forwarding.
Homelab Remote Access. Home Assistant, Plex, Jellyfin and Pi-hole, reachable from anywhere.

Frequently asked questions#

Do I need to open a port on my router?

No. The agent makes an outbound connection to Localport and traffic comes back down that same connection, so there is no inbound port to open and no router setting to change. It also means your network has no listening port for anyone to scan.

Does Localport work behind CGNAT or a corporate firewall?

Yes. Carrier-grade NAT and mobile networks give you no public address to forward a port to, and corporate firewalls block inbound connections by design. Neither affects an outbound connection, which is all the agent makes. On networks that inspect HTTPS traffic, the agent picks a carrier that survives inspection without being told to.

Is my tunnel address public?

By default, yes. Anyone holding the address can reach the service while the agent is running, which is right for a demo and wrong for production. Add Basic Auth, an IP allowlist, Header Authentication, or Remote Access depending on who needs in. Any of them can be switched on while the tunnel is live.

Can Localport read the traffic going through my tunnel?

No. Payloads are never logged, indexed, sold or used to train a model. On a TCP or TLS tunnel the bytes are forwarded and Localport holds no key for the stream. On an HTTP tunnel the routing information is read so the request reaches the right tunnel, and the body is forwarded. What is recorded is connection metadata: start and end times, byte and request counts, the identity that connected, and the device it reached.

Does Localport hold my private keys?

No. Every certificate starts as a signing request created on the machine that will use it, or in your browser, and the private key never leaves that machine. Localport signs the request and returns a certificate. If you already run your own certificate authority you can register that instead, in which case we store its public certificate and the address of its revocation list, and never see its key either.

Does my address change when I restart the agent?

No. The address belongs to the tunnel and not to the session, so stopping and starting the agent brings back the same one. TCP and TLS tunnels are the exception. The host stays the same, and the port number is assigned per session unless you reserve one. See TCP Tunnels.

What do callers see when the agent is not running?

An HTTP address answers with a 404 and the message "Tunnel not found". A TCP or TLS address refuses the connection, because that port is only open while a device is connected. Nothing is lost. The tunnel, its address, its access rules and its settings are all waiting for the next time the agent starts.

What happens when I revoke a certificate or remove access?

The connections using it close at that moment. Revoking a certificate, narrowing what an identity may reach, removing a device and removing a certificate authority all cut the live sessions they affect. A control that only applied to the next connection would leave an attacker connected for as long as they cared to stay, so none of them behave that way.

Can I use my own domain name?

Yes. Add the domain in the dashboard, create one CNAME record at your DNS provider, and attach the domain to a tunnel. Localport obtains and renews the certificate for it. A wildcard domain also gives every device on a fleet an address under your own name. See Custom Domains.

Is Localport open source?

The agent is. It is Apache 2.0 at github.com/localport/agent, and it is the only Localport code that runs inside your network. Read it, build it, and audit the protocol before you run it.