Next steps
Where to go after your first tunnel: sharing, teams, or production-style work.
You have a working tunnel. Where you go next depends on what you're trying to do. Pick the path that matches your situation.
I want to share my tunnel with someone
You're sending a URL to a client, designer, or coworker and you don't want it open to the public internet.
Add basic auth so anyone hitting the URL gets a password prompt — see Password-protect a tunnel. For repeat collaboration with the same person, walk through Share a tunnel with a client, which covers etiquette around URL stability, expirations, and what to do when the call ends.
If you need the URL to survive restarts so you can paste it into a doc once, Reserve a custom subdomain is the upgrade you want.
I'm setting this up for my team
You and your teammates each need tunnels under shared accounts (a personal context for solo work, a team context for shared subdomains and billing).
Start with Switch between accounts (contexts) — one local CLI install, multiple identities, switch with a flag. For receiving inbound webhooks reliably across machines, Run a worker tunnel keeps a single tunnel alive on a shared box rather than depending on whose laptop is awake. Read Teams for seat management and shared billing.
I'm running this for production-like work
You're past hobby use — you have a webhook integration that runs all day, a CI job that needs an inbound URL, or a smart-home device pointed at your stack.
Pin a stable URL with Reserve a custom subdomain, define everything declaratively with Use a tunnels.yaml config file, and host the tunnel itself on something that doesn't sleep — see Run a worker tunnel. For CI specifically, pass your API key via the JUSTTUNNEL_AUTH_TOKEN env var and tear the tunnel down at the end of the job.
Read up on Plans & limits before you commit a workflow to a tier — concurrent tunnel counts, reserved subdomain counts, and bandwidth differ.