ngrok describes itself as a globally distributed reverse proxy, delivering traffic to services running anywhere — a cluster, a Raspberry Pi, or your laptop. When the thing on the other end genuinely is a running service, that's exactly what you want, and nothing on this page replaces it: for a dev server someone needs to poke at, a webhook endpoint a third party has to reach, or an app with a backend behind it, a tunnel is the right shape and you should use one. The mismatch shows up when people reach for a tunnel to share something that isn't running at all — an exported report, a built static site, a self-contained page an AI wrote. Then you're keeping a machine awake and a process alive to serve a file that will never change on its own.
Try it now
Drop a file — get a private link in seconds. No sign-up.
Drop an HTML file or ZIP bundle, or click to choose.
Single file or ZIP. Max 3 MB.
Up to 3 MB, link self-destructs after 7 days. Sign up free to keep links forever, password-protect them, and store more.
Upload the finished thing instead of proxying to it: a single self-contained HTML file, or a ZIP of a built folder — dist, out, build — where the entry page is found automatically and relative paths keep resolving. It's served from a CDN rather than from your machine, so your laptop can close, your Wi-Fi can drop, and the link keeps working for the person you sent it to.
Add the controls that a tunnel isn't really designed to carry. A password, so a forwarded link still needs the passphrase. An expiry, so a review window closes without you remembering to kill anything. Both free on every plan. The URL is a long unguessable string, no-indexed by default, so it won't turn up in search results and can't be found by guessing.
Replace the contents when the build changes, at the same address, with the password and expiry preserved. If it's your AI tool doing the rebuilding, it can publish and replace the page itself over MCP, or you can push a folder from the terminal with npx miinideck deploy ./dist — which is the closest thing here to the muscle memory of starting a tunnel, minus the part where the URL only lives as long as the session does.
Whenever the other end has to actually run. Letting a client click through a dev server with hot reload, exposing a local endpoint so Stripe or GitHub can deliver a webhook, debugging a mobile device against your laptop, demoing something with a live backend, giving a colleague temporary access to a service on a private network — all of that is a tunnel's job and none of it is ours. Static hosting can't proxy to a process. If your answer to 'what am I sharing' involves the words 'my server', use ngrok.
Yes, and that's usually the simpler answer. If what you want someone to see is the output — an exported HTML report, a built site, a bundled prototype, a page an AI generated — there's no process that needs to be reachable, only files that need to be served. Uploading them once removes an entire category of failure: nothing to restart, no session to keep alive, no 'sorry, try again, I had to reboot' message at nine in the evening.
No, and that's the practical reason people switch for this particular job. A tunnel is a live path to something on your side; if the machine sleeps or the process stops, the far end of it stops working. An uploaded file is stored and served independently of you, so the link behaves the same at midnight as it did at noon, and the person you sent it to never sees a state that depends on where your laptop is.
ZIP the built folder and upload that. The entry HTML is detected automatically, relative paths to CSS, JavaScript, images, and fonts keep resolving, and it's served as an ordinary site. What doesn't survive is anything requiring a server at request time — API routes, a database, server-side rendering, authentication. If your build needs those, it needs a real deployment, and Vercel or Netlify are the right tools for that half.
As long as you choose, which is the other structural difference from a tunnel session. An anonymous upload self-destructs after 7 days, a free account can hold one always-on link, and on Solo ($4.99/mo) and Studio ($14.99/mo) links never expire unless you set an expiry deliberately. Setting a deliberate end date is a feature rather than a limitation — a review link that closes itself on the 14th is one less thing to remember.
Yes, over MCP. Connect it once and a tool like Claude Code can publish the HTML it just wrote and then replace that page in place as it iterates, keeping the same URL throughout. That's the workflow a tunnel is often standing in for — someone wants to see the thing as it develops — except the address doesn't change and the machine doing the building doesn't have to be the machine serving it.
No card to try, no sign-up to get a link. Sign up free to keep links forever, password-protect them, and store more.