LOCAL DEVELOPMENT · REAL-WORLD TESTS
Share localhost: phone previews and webhook tests
Your website runs on your computer. Give your phone, a client or a webhook service a temporary HTTPS link to reach it. No deployment needed.
Before you share: check the local address
Look at the URL printed by your development server. The protocol and port matter: http://localhost:5173 and https://localhost:7143 are different destinations. Open that exact address on your computer and complete one typical action before creating a tunnel.
One app, one port
If your page and API use the same local address, one tunnel can reach both. Paths are preserved: a public request to /contact reaches /contact in the local app. The tunnel does not copy or deploy your files.
Frontend and API on separate ports
A tunnel to your frontend does not automatically publish an API on another port. A browser calling localhost:3000 would call the visitor’s own device. Use your development server’s API proxy or give the API a reachable test URL and configure the frontend accordingly.
Get a public link
Start your website or API and check that it opens locally. GhostlyShare automatically detects running local web apps. Click Go Public to create a public HTTPS link.
- Keep your app and GhostlyShare running during the test.
- Open the link in a private browser window before sharing it.
- Use test data. Add a password for a private client preview when needed.
Windows & Linux. Free temporary links without an account, email or subscription.
Download GhostlyShare ↗
Open the public address once on your computer and once on another device. If the local page works but the public page fails, keep both URLs handy: this separates an app problem from a tunnel or host configuration problem.
Open localhost on your phone
On your phone, localhost refers to the phone itself, not your computer. Open the public link instead, or scan the QR code in GhostlyShare.
- Switch to mobile data to check access from outside your Wi-Fi.
- Try the menu, forms, keyboard and file uploads on the real device.
- Open a deep link and reload it. Check images and API responses too.
Only testing in the same Wi-Fi? Your computer’s LAN address may be enough if the dev server and firewall allow access. A public tunnel is useful for other networks and external services.
A useful five-minute phone test
- Navigation and layout
- Open the menu, rotate the phone and visit a long page. Look for horizontal scrolling, covered buttons and content hidden behind a sticky header. Browser emulation is useful, but it does not reproduce every real-device interaction.
- Forms and session state
- Tap every input, submit an invalid value and then a valid one. Check that error messages stay visible above the keyboard. If login works only on your computer, try a fresh browser session and check the callback address and cookie settings.
- Requests and loading
- Check an image-heavy page and an action that loads data. A slow response through your home connection is not a production performance benchmark. Record the failing page, device and action so you can reproduce the problem locally.
Show your work to a client
Send the exact page you want reviewed. Tell the recipient what to try and when the preview will close.
Before sending
Use a test account and sample content. Check that the link works without your own cookies or login session.
Ask for a specific check
Complete the contact form, review the mobile menu or try checkout with test payments. One clear task makes feedback more useful.
Here is the preview for today’s review. Please check the mobile menu and contact form. The link will close after our call.
Make feedback reproducible
Ask reviewers for the page URL, device, browser and the last action before the problem. A screenshot plus “I expected X, but Y happened” is more useful than “the page is broken”. If you edit the app during the review, mention it: depending on your setup, visitors may see changes or a reload immediately.
Receive a webhook locally
A webhook service cannot reach localhost on your computer. Give it the public tunnel address with your callback path. This example assumes your app already handles POST requests at /api/webhooks/demo.
http://localhost:5173/api/webhooks/demohttps://YOUR-TUNNEL.trycloudflare.com/api/webhooks/demo- Replace YOUR-TUNNEL with your actual hostname and enter the full callback URL in the provider’s test settings.
- Keep signature verification enabled. Store the webhook secret locally and send a test event from the provider.
- Check the delivery status and local logs. Return the success response expected by the provider and handle retries without repeating the action.
A browser password prompt can block a webhook sender. Use an endpoint the provider can reach and verify its signed requests. CORS applies to browser requests, not server-to-server webhook deliveries.
Read the webhook result, not just the browser page
Opening the callback URL in a browser usually sends a GET request. Many webhook endpoints accept POST instead, so a browser error alone does not prove delivery is broken. Send the provider’s test event and compare its timestamp and delivery ID with your local log.
- 404 / 405
- Check the path and HTTP method. Use the API’s port, not automatically the frontend’s port. A reachable home page does not mean the callback endpoint exists.
- 401 / 403
- Check which layer rejected the request: a preview password, app authentication or signature verification. For signed payloads, follow the provider’s rules for the original request body; parsing and rewriting it before verification can invalidate the signature.
- 5xx / Timeout
- Check whether the app is still running and whether it received the request. For slow processing, follow the provider’s response deadline and use background work where appropriate. Test a repeated delivery to ensure it does not create duplicate orders or messages.
Use the provider’s test mode and avoid logging secrets or complete personal payloads. A successful test checks delivery and your app’s handling; it does not replace the provider’s integration requirements.
The link opens, but something is broken?
The public link cannot reach the app
Open the local URL first. Check the port, HTTP versus HTTPS and whether the app and tunnel are still running.
Images or API calls fail
Look for hard-coded localhost URLs. Use relative paths where possible. A separate API port needs its own reachable route.
The app redirects to localhost
Check the public base URL, trusted proxy settings and login callbacks. Allow the actual preview host instead of disabling host checks globally.
Live reload or WebSockets fail
Check that WebSockets use the public host and wss on an HTTPS page. Some dev servers need a separate HMR host setting.
The webhook receives no success response
Check the callback path, HTTP method, signature secret and delivery log. Update the callback URL after starting a new temporary tunnel.
Finish the test and stop sharing
Stop sharing in GhostlyShare or stop the terminal tunnel with Ctrl+C. A link expiry can end a scheduled preview automatically. Remove temporary callback URLs from the webhook provider when you finish.
Need a fixed address for ongoing use?
A temporary preview is not a deployment. Our home-hosting guide covers named tunnels, domains, Windows services and running costs.
Set up a permanent Cloudflare Tunnel →Questions about local previews
FAQ
Why does localhost not work on my phone?
Localhost refers to the device opening the address. Use the public preview link to reach the app on your computer from your phone.
Does my computer need to stay on?
Yes. Your computer, local app and tunnel must keep running. Sleep mode or stopping the tunnel makes the preview unavailable.
Do I need a domain for a preview?
No. A temporary tunnel provides a public HTTPS address. Update shared links and webhook settings if that address changes.