LRO as an ngrok alternative

People arrive at this comparison from two different places. Some want a tunnel that is easier or cheaper for the job ngrok already does well. Others want the opposite of what ngrok does: reaching a machine that should not be published to the internet at all. LRO is built for the second group, and this page is written so you can tell within a minute which one you are.

Short version: ngrok creates a public endpoint, so anyone holding the URL can reach your service unless you put an authentication policy in front of it. LRO pairs two agents and opens a private tunnel between them — nothing becomes publicly addressable, and the relay only ever moves ciphertext it cannot read.

The core difference: a public endpoint versus a paired tunnel

ngrok runs an agent on the machine hosting your service and creates an endpoint on its cloud. That endpoint lives on the public internet, and the consuming side needs no software at all — a browser, a webhook provider or any client just opens the URL. That property is the whole point of the tool.

LRO expects an agent on both ends. One machine runs the agent in the client role, where the service lives. The machine you sit at runs it in the support role and opens a local listener. You then connect to 127.0.0.1 on your own machine, and the traffic travels between the two agents. Nothing is published, and there is no URL to leak.

Side by side

	ngrok	LRO
What gets exposed	A public endpoint on ngrok's network — a URL, or a host and port.	Nothing. Both agents dial out, and the tunnel surfaces only as a local port on your machine.
Who can reach it	Anyone holding the address, unless you configure an authentication policy in front of the endpoint.	The paired agent, plus the users you explicitly granted that endpoint to.
Software on the consuming side	None.	An LRO agent, which opens the local listener you connect to.
Encryption	HTTP endpoints terminate TLS at ngrok's edge by default — that is what makes their request inspector possible. TCP and TLS endpoints pass bytes through without decrypting them.	Always end-to-end between the two agents, with per-tunnel keys. It cannot be switched off, and the relay cannot read what it carries.
What you connect with	Whatever speaks the endpoint's protocol, pointed at the public address.	Your normal client pointed at a local port — `ssh`, an RDP or VNC viewer, a database client, a browser.
Access control	Traffic policy in front of endpoints, such as OAuth or basic authentication, depending on plan.	Organizations, per-user and per-endpoint permissions, per-device revocation and an audit log.
The job it is built for	Webhook development, demos, sharing work in progress with someone outside your network.	Administering machines you own, over their real protocols, for as long as they exist.

When ngrok is the better tool

If the other side must reach your service without installing anything — a payment provider posting a webhook, a client clicking a link to review a demo, a colleague on a phone — ngrok does exactly that and LRO cannot. Requiring an agent on both ends is a deliberate design choice here, and it rules out the anonymous-visitor case entirely.

The same goes for inspecting and replaying HTTP requests while you develop. That workflow depends on TLS being terminated at the provider's edge, which is precisely the property LRO gives up in exchange for the relay being unable to read anything.

When LRO fits better

The machine should never be publicly addressable — a customer's server, a production database, a device on an industrial network.
Both ends belong to you, so installing an agent on each is not an obstacle.
The access is ongoing rather than a one-off demo: the same servers, every week, over SSH, RDP, VNC, a database protocol or a device's web panel.
More than one person needs access, with different rights, and someone will eventually ask who connected to what.

Agents run on Linux, Windows, macOS and Android, and neither side needs an inbound port opened or a router touched.

What it looks like in practice

Install the agent on the remote machine and register it in the client role.
Install the agent on your own machine in the support role.
Create an endpoint describing the service — for example port 22 on the remote host.
Open a tunnel. Your machine starts listening on a local port.
Connect your usual client to that local port.

The first-tunnel guide walks through it end to end with screenshots.

What it costs

LRO charges a small subscription per agent plus metered traffic, so agents that sit idle cost close to nothing. New accounts start with a free balance, which is enough to install both agents and run a first tunnel before paying anything. The billing FAQ has the details.

Reach your own machines over their real protocols, without publishing anything to the internet.

Create an account →