Practical localhost sharing guide
Expose localhost with Cloudflare and GhostlyShare
When a client needs a preview, a webhook provider needs a callback URL, or you want to open your dev server on a phone, you need a public URL for something that still runs locally. This guide shows the terminal-first Cloudflare path, then the GhostlyShare workflow for repeated sharing.
Fast decision
Use the tool that matches the amount of sharing
The mistake is treating every local preview like hosting. A tunnel is best for temporary access. GhostlyShare is best when this becomes a regular workflow. A real deployment is best when users depend on the URL.
Use cloudflared.exe
Install Cloudflare's tunnel client once, run one command, copy the temporary URL, then stop it with Ctrl+C.
Use GhostlyShare
Let the desktop app detect local services, start sharing, show readiness, copy the URL, and stop access without hunting through terminal output.
Deploy the app
If the URL needs uptime, monitoring, backups, stable releases, or support ownership, a laptop tunnel is the wrong reliability boundary.
Method 1
Cloudflare EXE: the quickest clean command-line flow
Cloudflare's tunnel client is called cloudflared. On Windows you can install it with winget or download the EXE manually. For a short development preview, Quick Tunnel gives you a random HTTPS URL 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 does not work locally, a public tunnel cannot fix it.
npm run devInstall 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.cloudflaredCreate 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:5173Test before you share
Open the generated trycloudflare.com URL in a private window or on another device. Check login, assets, redirects, and API calls before sending it to someone else.
https://example-random-name.trycloudflare.comStop the tunnel deliberately
When the demo or webhook test is over, stop the terminal process. If your machine sleeps or disconnects, the quick tunnel will stop working anyway.
Ctrl+CStable preview names
Random URL or custom Cloudflare hostname?
Random URLs are perfect when the link can disappear after a test. Custom domains make sense when the preview should look stable, for example demo.example.com, and you already manage the domain in Cloudflare.
| Need | Use | Why it fits |
|---|---|---|
| A five minute demo or webhook callback | Random URL | No account or DNS work is needed, and the link is easy to throw away after the test. |
| A client review that should look branded | Custom domain | A hostname you control is easier to recognize, but it needs your Cloudflare zone, token permissions, DNS, and tunnel routing. |
| A preview that should not be casually opened | Password protected link | Add a password before going public, then share the URL and password separately with the small group that needs access. |
Other options
Other ways to expose localhost
You do not need one tool for every situation. The best choice depends on whether you want one disposable link, a desktop workflow, a branded preview, a private network tool, or a deliberately hardened self-hosted setup.
| Tool | Typical command or action | Best for | Watch out |
|---|---|---|---|
| Cloudflare Quick Tunnel | cloudflared tunnel --url http://localhost:5173
|
Fast disposable public HTTPS URLs without router changes. | Development and testing only; random URL; terminal lifecycle. |
| GhostlyShare | Select Go Public in the desktop app
|
Repeated local previews, webhook tests, password-protected demos, and optional Cloudflare custom domains. | Still not production hosting; your local app and machine must keep running while the link should work. |
| ngrok | ngrok http 5173
|
Teams already using ngrok, reserved domains, traffic inspection, and provider-specific routing features. | Account and plan details matter; more provider setup than a throwaway quick tunnel. |
| Tailscale Funnel | tailscale funnel 3000
|
People already using Tailscale who want a public HTTPS endpoint for a tailnet device. | Requires Tailscale setup and Funnel enabled for the tailnet. |
| localtunnel | npx localtunnel --port 3000
|
Quick Node-based localhost sharing for simple tests. | Useful for simple previews; think carefully before using it for anything sensitive. |
| Router port forwarding | Configure router, DNS, TLS, and reverse proxy
|
Permanent self-hosting when you intentionally operate the infrastructure. | More exposed attack surface; patching, firewall rules, logs, and TLS become your job. |
Webhook testing
The details that save time with webhooks
Webhook providers cannot call http://localhost on your laptop. They can call the public tunnel URL. Treat that URL like a real external integration: keep signatures enabled, use the exact callback path, and check redirects and CORS.
Use the full callback path
If your receiver listens on /api/webhooks/stripe, paste the public URL with that same path, not only the domain.
Keep signature validation enabled
A public tunnel makes real webhook signatures easier to test. It is not a reason to disable signature verification.
Watch base URLs and forwarded headers
If the public URL redirects back to localhost, configure public base URLs, forwarded headers, trusted proxies, or framework host settings.
Test from a clean browser session
Use a private window or a second device so cached localhost state does not hide problems with cookies, CORS, redirects, or mixed content.
Troubleshooting
Fix the common tunnel problems first
The tunnel starts, but the page is blank
Open the local URL directly, then check whether assets, API URLs, WebSocket URLs, or environment variables still point to localhost.
The public URL redirects to localhost
Many frameworks build redirects from the request host. Fix forwarded headers, trusted proxies, public origin, or forced development redirects.
The link appears before it works
Cloudflare routing, DNS, GhostlyShare's local proxy, and the origin app may need a short moment to agree. Wait a few seconds, refresh, and test again.
HTTPS localhost certificates cause errors
For short previews, tunnel the local HTTP endpoint when available. For longer setups, configure origin TLS intentionally instead of guessing.
Hot reload or WebSockets fail
Use a tool that supports WebSockets and make sure the app builds ws or wss URLs from the public host, not from a hard-coded localhost value.
Safety
Before you send the public URL
A public preview URL is still public access. Password protection can reduce accidental access, but it does not make a risky local service safe. Share the narrowest URL, use test data, and stop the link after the review or webhook test.
Use test data
Do not expose real customer records, database admin screens, internal dashboards, seed secrets, or private company data.
Keep app authentication enabled
If a feature normally requires login, it should still require login during the public preview.
Use password protection for private previews
For small review groups, add a GhostlyShare password before going public and share it separately from the link.
Stop and rotate links
Stop temporary links after use. If a URL or password leaks into a ticket or chat, create a fresh preview instead of reusing it.
FAQ
Frequently asked questions
What is the exact Windows command?
After installing cloudflared, run cloudflared.exe tunnel --url http://localhost:PORT, replacing PORT with your app's local port, for example 5173, 3000, 5080, or 8080.
Is GhostlyShare only a wrapper around cloudflared?
No. GhostlyShare uses Cloudflare-powered tunnels, but it adds a desktop workflow around app detection, random or custom public links, readiness state, stopping access, and optional password protection.
Can GhostlyShare protect a public link with a password?
Yes. Enable password protection before going public. Visitors must enter the password before GhostlyShare forwards traffic to the selected local app, but this is still not a replacement for proper app security.
Do I need router port forwarding?
No for the tunnel workflows in this guide. cloudflared, GhostlyShare, ngrok, Tailscale Funnel, and similar tools open outbound connections from your machine, so you usually do not need inbound router forwarding.
Can I test webhooks through a local tunnel?
Yes. Start the local webhook receiver, expose it through the tunnel, paste the public HTTPS URL plus the correct callback path into the provider, send a test event, and inspect the request locally.
Should I expose admin tools or databases?
Usually no. Do not expose database consoles, admin dashboards, infrastructure panels, debug endpoints, or internal services unless they are deliberately hardened and meant to be reachable from the internet.
Should I use a laptop tunnel for production traffic?
No. Use a real deployment or a managed tunnel on infrastructure that is meant to stay online, receive updates, be monitored, and recover after failures.