Practical guide to sharing localhost
Share localhost using Cloudflare and GhostlyShare
When a client requires a preview, a webhook provider needs a callback URL, or you want to access your dev server on a phone, you need a public URL for a locally running service. This guide covers the terminal-first Cloudflare method, followed by the GhostlyShare workflow for repeated sharing.
Quick decision
Choose the tool that fits the sharing volume
The error is treating every local preview as hosting. A tunnel suits temporary access. GhostlyShare is ideal for regular workflows. Real deployment is best when users rely on the URL.
Use cloudflared.exe
Install Cloudflare's tunnel client once, run a single command, copy the temporary URL, then stop it with Ctrl+C.
Use GhostlyShare
Allow the desktop app to detect local services, start sharing, display readiness, copy the URL, and stop access without searching terminal output.
Deploy the application
If the URL requires uptime, monitoring, backups, stable releases, or support ownership, a laptop tunnel is not a suitable reliability boundary.
Method 1
Cloudflare EXE: the fastest straightforward command-line method
Cloudflare's tunnel client is named cloudflared. On Windows, install it via winget or download the EXE manually. Quick Tunnel provides a random HTTPS URL for short development previews without router port forwarding, a Cloudflare DNS zone, or a custom domain.
Start the local app
Open the local URL in your browser first. If the app fails locally, a public tunnel won’t resolve the issue.
npm run dev
Install cloudflared on Windows
Use winget when it is available. If you download the EXE manually, place it in a folder such as C:\Cloudflared\bin and call it cloudflared.exe.
winget install --id Cloudflare.cloudflared
Generate the public URL
Use the exact local HTTP URL and port. In PowerShell from the EXE folder, use .\cloudflared.exe if the executable is not on PATH.
cloudflared.exe tunnel --url http://localhost:5173
Test before sharing
Open the generated trycloudflare.com URL in a private browser window or on another device. Verify login, assets, redirects, and API calls before sharing.
https://example-random-name.trycloudflare.com
Deliberately stop the tunnel
When the demo or webhook test ends, stop the terminal process. If your device sleeps or disconnects, the quick tunnel will cease functioning regardless.
Ctrl+C
Stable preview names
Random URL or custom Cloudflare hostname?
Random URLs are ideal when the link can be discarded after testing. Custom domains suit previews needing stability, such as demo.example.com, when you manage the domain in Cloudflare.
| Requirement | Use | Why it suits |
|---|---|---|
| A five-minute demo or webhook callback | Random URL | No account or DNS configuration is required, and the link can be discarded after testing. |
| A client review that should appear branded | Custom domain | A hostname you control is easier to identify, but it requires your Cloudflare zone, token permissions, DNS, and tunnel routing. |
| A preview that should not be opened casually | Password-protected link | Set a password before going public, then share the URL and password separately with the small group requiring access. |
Other options
Alternative methods to expose localhost
You don’t need a single tool for every scenario. The best option depends on whether you want a disposable link, a desktop workflow, a branded preview, a private network tool, or a deliberately secured self-hosted setup.
| Tool | Typical command or action | Best suited for | Be cautious |
|---|---|---|---|
| Cloudflare Quick Tunnel | cloudflared tunnel --url http://localhost:5173
|
Rapid disposable public HTTPS URLs without router configuration changes. | For development and testing only; random URL; terminal session lifecycle. |
| GhostlyShare | Choose Go Public in the desktop app
|
Repeated local previews, webhook tests, password-protected demos, and optional Cloudflare custom domains. | Not production hosting; your local app and device must remain active while the link is in use. |
| ngrok | ngrok http 5173
|
Teams already using ngrok, reserved domains, traffic inspection, and provider-specific routing features. | Account and plan details are important; this involves more provider configuration than a disposable quick tunnel. |
| Tailscale Funnel | tailscale funnel 3000
|
Users already on Tailscale seeking a public HTTPS endpoint for a tailnet device. | Requires Tailscale setup with Funnel enabled for the tailnet. |
| localtunnel | npx localtunnel --port 3000
|
Quick Node-based localhost sharing for straightforward tests. | Suitable for simple previews; consider carefully before using for sensitive content. |
| Router port forwarding | Configure router, DNS, TLS, and reverse proxy
|
Permanent self-hosting when you deliberately manage the infrastructure. | Greater exposed attack surface; patching, firewall rules, logs, and TLS become your responsibility. |
Webhook testing
Details that save time with webhooks
Webhook providers cannot access http://localhost on your device. They use the public tunnel URL. Treat this URL as a genuine external integration: keep signatures enabled, use the exact callback path, and verify redirects and CORS.
Use the complete callback path
If your receiver listens on /api/webhooks/stripe, use the public URL including that path, not just the domain.
Keep signature validation enabled
A public tunnel simplifies testing real webhook signatures but is not a justification to disable signature verification.
Monitor base URLs and forwarded headers
If the public URL redirects to localhost, configure public base URLs, forwarded headers, trusted proxies, or framework host settings.
Test using a clean browser session
Use a private window or a second device to prevent cached localhost state from masking issues with cookies, CORS, redirects, or mixed content.
Troubleshooting
Resolve common tunnel issues first
The tunnel starts but the page remains blank
Open the local URL directly, then verify if assets, API URLs, WebSocket URLs, or environment variables still reference localhost.
The public URL redirects to localhost
Many frameworks create redirects based on the request host. Correct forwarded headers, trusted proxies, public origin, or forced development redirects.
The link appears before it is active
Cloudflare routing, DNS, GhostlyShare's local proxy, and the origin app may need a moment to synchronise. Wait a few seconds, refresh, and try again.
HTTPS localhost certificates cause errors
For brief previews, tunnel the local HTTP endpoint if available. For longer setups, deliberately configure origin TLS rather than guessing.
Hot reload or WebSockets failure
Use a tool supporting WebSockets and ensure the app constructs ws or wss URLs from the public host, not a hard-coded localhost address.
Safety
Before sharing the public URL
A public preview URL remains accessible to anyone. Password protection helps prevent accidental access but does not secure a risky local service. Share the most specific URL, use test data, and disable the link after the review or webhook test.
Use test data
Avoid exposing real customer records, database admin panels, internal dashboards, seed secrets, or confidential company data.
Keep application authentication enabled
If a feature usually requires login, it should still require login during the public preview.
Use password protection for private previews
For small review groups, set a GhostlyShare password before going public and share it separately from the link.
Stop and rotate links
Disable temporary links after use. If a URL or password leaks into a ticket or chat, create a new preview rather than reusing it.
Frequently Asked Questions
Frequently asked questions
What is the precise Windows command?
After installing cloudflared, run cloudflared.exe tunnel --url http://localhost:PORT, replacing PORT with your app's local port, such as 5173, 3000, 5080, or 8080.
Is GhostlyShare merely a wrapper for cloudflared?
No. GhostlyShare utilises Cloudflare-powered tunnels but adds a desktop workflow for app detection, random or custom public links, readiness status, stopping access, and optional password protection.
Can GhostlyShare secure a public link with a password?
Yes. Enable password protection before going public. Visitors must enter a password before GhostlyShare forwards traffic to the chosen local app, but this does not replace proper app security.
Is router port forwarding necessary?
No, for the tunnel workflows in this guide. cloudflared, GhostlyShare, ngrok, Tailscale Funnel, and similar tools open outbound connections from your device, so inbound router forwarding is usually unnecessary.
Is it possible to test webhooks via a local tunnel?
Yes. Start the local webhook receiver, expose it via the tunnel, enter the public HTTPS URL with the correct callback path into the provider, send a test event, and inspect the request locally.
Should I expose admin tools or databases?
Usually not. Avoid exposing database consoles, admin dashboards, infrastructure panels, debug endpoints, or internal services unless deliberately secured and intended for internet access.
Is a laptop tunnel suitable for production traffic?
No. Use a proper deployment or a managed tunnel on infrastructure designed to remain online, receive updates, be monitored, and recover from failures.