An ngrok alternative: share a local service, privately or publicly

What ngrok does, and why it became a reflex

ngrok’s principle is simple and effective: a client runs on your machine, establishes an outbound connection to ngrok’s servers, and they hand you a temporary public URL. Everything arriving at that URL is carried through the tunnel to the local port of your choice. Your machine has no inbound port to open; the local service becomes reachable from anywhere within seconds.

That is what made it a development staple: receiving a third-party service’s webhooks on your workstation, showing an application in progress without deploying it, testing an integration that requires an internet-reachable address. The tool does very well what it promises, and this page does not set out to argue otherwise.

The right question: who needs to reach your service?

Before looking for an ngrok alternative, it is worth sorting the use cases. In the vast majority of them, the people who need to reach your local service are known: a colleague, a client in a meeting, yourself from another device. A URL open to the whole world is then oversized: you are exposing to the entire internet what two people need to see. The only case that genuinely requires public reachability is the one where the caller is a third-party server you do not control — a payment provider, a code forge, a SaaS platform that must deliver its webhooks to an internet-reachable address.

Sharing privately: the mesh replaces the public URL

For every private use case, VIGIL-MESH replaces the public tunnel with a private network: your machine and your colleague’s join the same workspace and reach each other directly, over an end-to-end encrypted QUIC/TLS 1.3 session. The colleague points their browser at your machine’s name — a stable MagicDNS name, followed by the dev server’s port — and sees the demo as if they were on your local network. Nothing is published, nothing is reachable from the internet: there simply is no public URL to discover.

• A stable name, not a throwaway URL — the machine keeps its address (within 100.64.0.0/10) and its MagicDNS name across restarts and whatever physical network it sits on. The link you sent your colleague yesterday still works tomorrow.
• Access follows identity, not URL secrecy — ACLs, deny by default, decide who reaches what: you can open only your machine to the colleague, or even a single service, and nothing else on your network.
• Zero exposure — no inbound port anywhere: each machine only makes outbound connections, a single flow on 443 UDP. Your dev server shows up on no internet scan.
• It works behind any router — home NAT, corporate firewall, 4G/5G under CGNAT: the connection establishes immediately through a blind relay, then migrates seamlessly to the direct path.
• Revocable on the spot — once the demo is over, you suspend or revoke the guest device from the console: it loses access immediately.

When you genuinely need public: HTTP and TCP publication

That leaves the case where the caller cannot join your network: a third-party service’s webhook, an API consumed by an external partner. For this, VIGIL-MESH offers publication: a single public entry point that maps to one internal service. Incoming traffic is received by the platform, then relayed to the service across the encrypted mesh. The machine hosting the service still opens no inbound port — it can live behind a home NAT or a mobile link — and the visitor learns nothing about the topology or the services that stayed private.

HTTP publication is for services that speak the web: the platform acts as a reverse-proxy, terminates the TLS connection on the public side with a certificate obtained and renewed automatically for your domain name, then carries the request to the internal service. For anything that is not web — a line-of-business protocol, a raw stream — TCP publication exposes a transport port: the flow is relayed as-is, without being interpreted and therefore without TLS termination by the platform.

Actual need → right tool

The table below sums up the logic of this page: start from the actual need — who must reach the service, and for how long — and derive the tool from it, rather than applying the public-URL reflex to everything.

Step by step: the private demo, with nothing exposed

Scenario: your application runs on your workstation, and a remote colleague needs to see it. Once the workspace is in place, the whole operation comes down to enrolling their machine — and the next demos will require nothing at all.

1. 1
   Create an account and a workspaceThe workspace is the private perimeter that will hold your machines and your guests’. Done once.
2. 2
   Install the client on the machines involvedYours and the colleague’s — Windows, Linux or Android as appropriate. The client only makes outbound connections: nothing to configure on any router.
3. 3
   Enroll the colleague's machineNetworks page → Machines → “Add a machine”: the wizard hands out a single-use enrollment key, passed to the client as a command or as a QR code on mobile.
4. 4
   Verify connectivityThe machine appears in the console with its stable address and its MagicDNS name; a ping on the name confirms everything is in place.
5. 5
   Share the private linkThe colleague opens your machine’s name followed by the dev server’s port in their browser, as if local. After the demo, suspend or revoke their device from the console: access drops immediately.

Step by step: publishing a URL for a webhook

Scenario: a third-party service must deliver its webhooks to an internet-reachable URL, and the receiver runs on a mesh machine — your dev workstation, a server at home. HTTP publication creates that URL without the machine exposing anything itself.

1. 1
   Designate the internal service to publishThe mesh machine and the port the webhook receiver listens on. The service keeps running exactly as before, unmodified.
2. 2
   Choose the public nameThe domain or subdomain through which the third-party service will reach you. Its management (ownership, DNS, activation) is described in the domains documentation, at /en/docs/plateforme-domaines.
3. 3
   Let the platform obtain the certificateThe TLS certificate is requested and renewed automatically for the public name — no file to install, no expiry date to watch.
4. 4
   Enter the URL at the third-party serviceOnce the name is active, the reverse-proxy relays incoming traffic to your receiver across the encrypted mesh. The URL is durable: it does not change with each work session, and never needs reconfiguring on the third-party side again.

Frequently asked questions