Expose Your Localhost to the Internet With One Command, No Account, No Config File

Every developer eventually hits the same wall. You built something on your laptop, it works on localhost, and now someone else needs to see it. A teammate wants to test your API from their machine. A webhook provider needs a public URL to call you back on. A client wants to click through the prototype without you screen-sharing.

The traditional answers are all heavier than the problem. Deploy to a staging server for a five-minute demo. Pay for a tunneling service. Create an account, generate a token, wire it into your shell config. All of that for "let someone hit my port 8080."

Cloudflare's Quick Tunnels strip almost all of that away. One command, no account, no domain, no config file, and you get a public HTTPS URL on trycloudflare.com that routes straight to your local port. The feature has been around since 2021, but it trended hard on Hacker News this week (812 points at the time of writing), because a lot of developers still do not know it exists or do not know where its edges are.

Full disclosure: everything in this article is verified against Cloudflare's official documentation, and I have not run quick tunnels in a production setting. This is a "read the docs and map the edges" piece, not a war story. Links to every claim are inline.

The one command

After installing the cloudflared daemon, exposing a local server looks like this:

cloudflared tunnel --url http://localhost:8080

That is the whole setup. cloudflared opens an outbound-only connection to Cloudflare's edge, the edge service generates a random subdomain like https://some-random-words.trycloudflare.com, and requests to that URL are proxied over the tunnel to whatever is running on your local port 8080. You get HTTPS for free, which matters more than it sounds: webhook providers almost universally require it, and the browser padlock stops the "is this link safe?" questions before they start.

Because the connection is outbound-only, nothing about your network needs to change. No port forwarding on the router, no firewall holes, no public IP requirement. The tunnel works the same from a coffee shop NAT, a corporate network, or a home connection behind carrier-grade NAT, which is a real concern for a lot of developers in Bangladesh and elsewhere where a genuinely public IPv4 address is not something you can assume.

Quick walkthrough:

• Install cloudflared. It is a single lightweight daemon, packaged for every major OS. Cloudflare's docs cover the install for each platform.
• Start any local server. Anything that answers on a local port works. A Node dev server, a Python FastAPI app, a static site preview, a local admin panel.
• Run the tunnel command pointing at that port.
• Share the printed URL. Anyone with the link can reach your local service through Cloudflare's network.

The limits that actually matter

The feature is free and instant for a reason, and the docs are unusually honest about where it falls short. These are the constraints to internalize before you lean on it:

• The URL is ephemeral. The hostname changes every time you start a quick tunnel, and access ends for everyone the moment the cloudflared process stops. Abandoned tunnels get cleaned up after being disconnected for more than five minutes. This is a demo link, not an address.
• 200 in-flight requests, hard limit. Each quick tunnel supports up to 200 concurrent requests. Beyond that, Cloudflare returns a 429. Fine for a demo with a handful of users, instantly wrong for anything load-bearing.
• No Server-Sent Events. SSE is explicitly unsupported on quick tunnels. If your app streams tokens from an LLM endpoint or pushes live updates over SSE, the quick tunnel will break it. WebSockets are a different mechanism and generally behave better here, but test before you demo.
• No uptime guarantee. Cloudflare's docs state this plainly: quick tunnels are for testing and development only.
• The URL is completely public. Anyone who obtains it can reach your local service. There is no built-in authentication layer. If you are tunneling an admin panel or anything with write access, you are relying entirely on your application's own auth.
• Config file conflict. If a config.yaml exists in your ~/.cloudflared directory, quick tunnels are not supported until you rename or move it. This trips up people who already use cloudflared for a named tunnel.

That last pair deserves a pause. "Free public URL to my laptop" plus "no auth at the tunnel layer" is a genuinely dangerous combination if the thing on localhost trusts localhost. Plenty of dev tools default to open access when the request comes from 127.0.0.1, and a quick tunnel is not localhost anymore, it is the internet knocking through a proxy. Treat the URL like a password: share it with the person who needs it, regenerate it when the session ends by simply restarting the process, and never point a tunnel at a service you would not expose deliberately.

Quick tunnel vs the alternatives

This is the decision I would actually make, given the options in October 2026:

• Quick tunnel: you need a public HTTPS URL in the next sixty seconds, for a demo, a webhook test, or a "can you check this on your phone" moment. Zero setup cost. Constraints above apply.
• Named Cloudflare Tunnel (still free with an account): you need a stable hostname, SSE, more headroom than 200 concurrent requests, or anything resembling persistence. You attach it to a domain on Cloudflare, and tunnels become long-lived objects. This is the documented path for anything beyond testing.
• ngrok and friends: you want built-in inspection of requests hitting your tunnel, or you are already embedded in that ecosystem. The free tiers generally require an account and come with their own URL-rotation and rate limits. If all you want is a link, quick tunnels beat the signup ceremony.
• Tailscale or a VPN: the person who needs access is on your team and can install a client. This is strictly more secure than any public tunnel because the URL is not public at all. The cost is that the other person has to join your network, which kills it for demos to outsiders.

The honest summary: quick tunnels win on time-to-first-URL, and lose on everything else by design. The moment your use case includes the words "longer than today," upgrade to a named tunnel.

A practical checklist before you share a tunnel link

Save this one for the next time you spin one up:

• Check what your local service exposes. Does it have auth? Does it trust loopback requests? An open tunnel to an unauthenticated service is a breach waiting for a bored scanner.
• Do not tunnel databases, message brokers, or anything with a default-credential admin UI.
• Assume the URL leaks the moment more than one person has it. Treat it as time-boxed.
• If you hit random 429s mid-demo, that is the 200 concurrent request cap, not a bug in your app.
• Streaming endpoints: test SSE through the tunnel before the client call, not during it.
• Kill the process when the session is done. The URL dies with it, which is the feature.
• If you need this twice a week for the same service, spend the ten minutes setting up a named tunnel with your own domain. The random-hostname shuffle stops being cute fast.

The bigger picture

Quick Tunnels are a small feature, but they sit in an interesting spot in the current dev-tool landscape. The trend all year has been friction removal at the edges of development: tools that assume you want to get from "it works on my machine" to "it works where someone can see it" without a DevOps ceremony in between. Tunnels, preview environments, one-command deploys. The tools that survive this cycle are the ones that make the common case free and the serious case a config file away, and Cloudflare has structured this exactly that way: the quick tunnel costs nothing and asks for nothing, and every limitation is a gentle upsell to the named tunnel, which is also free but wants an account.

There is also a security culture point worth making. The same week this trended, the front page of Hacker News also carried a story about a code assistant silently uploading users' git history to the cloud. The lesson of both stories is the same: "it made something convenient" and "it sent my stuff somewhere public" are independent facts, and it is on us to check the second one. Quick tunnels are convenient. Whether the thing behind the tunnel should face the internet is a question the tool will never answer for you.

---

I write about developer tools, backend engineering, and working with AI systems every week. Subscribe, it is free, and it means the next one shows up without you hunting for it.

Have you used quick tunnels or ngrok-style services for demos and webhook testing? Did anything break in surprising ways, especially around SSE or auth? I am curious where the edges bit people in practice.