LOCAL DEVELOPMENT · REAL-WORLD TESTS
Share localhost: test on your phone and receive webhooks
Your site is running on your computer. A temporary HTTPS link lets your phone, a client or a webhook service reach it without a deployment.
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
Run your website or API and make sure it opens locally. GhostlyShare detects running local web apps automatically. Click Go Public for a public HTTPS link.
- Keep your app and GhostlyShare running during the test.
- Open the link in a private browser window before sharing it.
- Work with test data. If the preview is for a client only, add a password when needed.
For Windows and Linux. Temporary links are free, with no 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
Localhost on a phone points to that phone, not to your computer. Use the public link or scan the QR code shown 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.
Testing only on the same Wi-Fi network? The computer’s LAN address may suffice, provided your development server and firewall permit access. Use a public tunnel for other networks or 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
Share the precise page you want the client to review. Explain what to try and when access will end.
Before sending
Choose a test account and sample content. Make sure the link works without relying on your cookies or signed-in session.
Ask for a specific check
Ask them to fill in the contact form, check the mobile menu or complete a checkout with test payments. A specific task produces more useful feedback.
This is the preview for today’s review. Please try the mobile menu and contact form. I will close the link 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 connect to localhost on your computer. Supply the public tunnel URL followed by the callback path. The example assumes your app already accepts POST requests at /api/webhooks/demo.
http://localhost:5173/api/webhooks/demohttps://YOUR-TUNNEL.trycloudflare.com/api/webhooks/demo- Use your real hostname in place of YOUR-TUNNEL, then add the complete callback URL to the provider’s test settings.
- Keep signature verification enabled. Store the webhook secret locally and send a test event from the provider.
- Review the delivery status alongside your local logs. Send the success response the provider requires, and handle repeat deliveries without performing the same action twice.
A browser password screen may prevent webhook delivery. Provide an endpoint the sender can access and validate signed requests. CORS concerns browser requests, not webhook traffic between servers.
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
First check the local URL. Verify the port and whether it uses HTTP or HTTPS, and confirm that both app and tunnel are still running.
Images or API calls fail
Check for localhost addresses hard-coded into the app. Prefer relative paths where possible; an API on a different port needs a reachable route of its own.
The app redirects to localhost
Review the public base URL, trusted proxies and sign-in callbacks. Permit the actual preview hostname rather than turning off host validation for every host.
Live reload or WebSockets fail
Make sure WebSockets connect to the public host and use wss on HTTPS pages. A development server may also require its HMR host to be configured separately.
The webhook receives no success response
Review the callback path, HTTP method, signing secret and delivery log. Remember to replace the callback URL when you start a new temporary tunnel.
Finish the test and stop sharing
End sharing in GhostlyShare, or press Ctrl+C in the tunnel’s terminal. An expiry time can close a scheduled preview automatically. Afterwards, remove temporary callback URLs from the webhook provider as well.
Need a fixed address for ongoing use?
A temporary preview does not deploy your site. See our home-hosting guide for named tunnels, domains, Windows services and ongoing costs.
Set up a permanent Cloudflare Tunnel →Questions about local previews
FAQ
Why does localhost not work on my phone?
Localhost means the device where you open the address. On your phone, use the public preview URL to connect to the app running on your computer.
Does my computer need to stay on?
Yes: the computer, local app and tunnel all need to stay running. Sleep mode or a stopped tunnel will make the preview inaccessible.
Do I need a domain for a preview?
No domain is required. A temporary tunnel gives you a public HTTPS URL; if it changes, update the links you shared and your webhook configuration.