Before sharing a localhost demo with a client

Letting a client try a screen in their own browser produces different feedback from sending a screenshot. Exposing localhost through a public link also makes a running development app reachable from the internet. Good demo preparation begins before copying the address and continues after the meeting finishes.

Separate the demo from production data

Use sample customers, products and orders. Even if the admin page shows no real personal information, API responses, error pages and other endpoints called by the browser may carry it. Check the application's test mode and the sandbox state of connected services. A button that sends a real email can still send a real email during a demo.

LocalTR does not upload and host your source code as a static package. A public HTTP request travels through the relay to your Mac, and the application's response travels back to the visitor. “My code is not uploaded” does not mean “no data passes through a server.” What gets exposed depends on your application as well as the link.

Verify the address from another network

First confirm the local service responds at its direct port. Then create the public URL and open it outside your own Wi-Fi network. A mobile connection can serve as that check. Test the correct page, assets and basic form behavior. Exercise the routes needed during the meeting: a successful home page does not verify the entire workflow.

There is one simultaneous public tunnel per Mac. Opening a public URL for another project replaces the current client. Account for that before opening another connection during a meeting. A chosen subdomain depends on server validation and availability; it is not support for attaching a domain you purchased.

Test access controls

If a password is appropriate, enable Basic Auth and try incorrect credentials in a fresh browser session. Then open the link with the correct credentials. Change the assumption that anyone who knows the URL can access it deliberately. A link password still does not replace your application's own user roles or authorization.

If a webhook or external service uses the same URL, check password behavior with that client. Not every client can send Basic Auth. A difficult-to-guess subdomain is not authentication either. Choosing a useful control requires understanding how the other party will connect.

Treat the Mac as part of the meeting

The live tunnel depends on the Mac, internet connection, LocalTR and development server remaining available. Sleep, a network switch or an app restart can interrupt access. Reconnection attempts are not a guarantee of uninterrupted service. This workflow is not permanent hosting or a snapshot that stays available while your Mac is off.

Do not assume public WebSocket, SSE or general TCP/UDP support in this release. If pages work but live updates do not, local WebSocket support is not evidence of public streaming support. Verify the exact flow you plan to show, and use a persistent test environment for requirements this tunnel does not cover.

End access when the meeting ends

Pausing sharing is useful for stopping new requests. It is not a guarantee that every transfer already in progress is cancelled instantly. Close the public connection when it is no longer needed. Remember when choosing sample data that you cannot remotely withdraw a response or screenshot someone already saved.

A final checklist is straightforward: sample data, correct service, reachability from a separate network, a password if needed and closure at the end. Clear results for each step let you focus on client feedback rather than uncertain connectivity. Find setup details in the public URL guide and the data path on the security page.

12-point demo checklist

Check items here or use your browser’s Print menu. Your selections stay in the open tab, reset on reload and are not sent to the site. Verify each item with your own build and test environment.

Before opening the link

• Open the direct port. Check the actual localhost address and the page/form you plan to demonstrate.
• Choose sample data. Keep real personal data, orders, sessions and production credentials out of the demo.
• Check side effects. Email, payment, webhook and external service actions point to controlled test or sandbox targets.
• Choose the service. Confirm the project and port. A new public connection on the same Mac may replace the current one.

Before sending the link

• Test from another network. Open the public URL outside your Wi-Fi and check the routes, images and forms needed for the demo.
• Choose access controls. If using a password, test wrong and correct credentials in a clean session. Check application authorization too.
• Test callback clients. Confirm a webhook provider can use your chosen access method.
• Keep the Mac ready. The Mac, LocalTR, network and development server stay online during the demo. A live tunnel is not persistent hosting.

After the demo

• Keep the useful result. Link feedback to redacted test notes rather than sharing an entire capture history.
• Close sharing. Close the public connection when the task is done. Distinguish pausing new requests from closing access.
• Check new access. Verify that the closed link no longer serves a new request. Previously saved copies cannot be recalled.
• Tidy test data. Remove temporary records and shared files according to your application’s policy.

Your next step

• Open the demo checklist
• Prepare a password-protected Mac demo

Notify me when downloads open

The signed installer is in preparation. After email verification, the optional notification covers one download opening; it does not start a trial or subscribe you to a blog newsletter.