That was the moment I decided I'd never share another *.ngrok-free.app or *.somevendor.com URL with another human. If I'm going to share a localhost preview, it's going on a real domain that actually says my name.

This post walks through how I do that today, using a domain I already owned, for free, in about five minutes.

Short answer: Install tunnelto, add one CNAME record at your DNS provider, and run tunnelto add preview.yourdomain.com 3000. tunnelto handles certificate issuance and routing automatically. The free plan includes 1 custom domain.

Why do I want a custom domain on localhost in the first place?

Three reasons keep coming up:

1. Stable URLs. Random tunnel subdomains rotate every reconnect. A URL on my own domain doesn't. That means webhook configs, OAuth callbacks, bookmarks, and shared preview links keep working forever.

2. Trust. A URL like preview.acme.com looks like a real product. A URL like 7f3a2b9.tunnel-vendor.com looks like phishing. This matters more than it should when you're sharing previews with non-technical stakeholders.

3. No vendor lock-in. If I ever change tunnel providers, my domain stays the same. I just point the CNAME somewhere else. No dead links anywhere.

The first reason is purely technical. The second is about how the link reads to a human. The third is about not painting yourself into a corner. All three are real.

What's the cheapest way to get a custom domain on localhost?

Three options, in increasing order of friction:

I use tunnelto because it works with whatever DNS provider I already have. My domains are at Namecheap and Porkbun, so the Cloudflare option would mean transferring DNS just to put a tunnel on a subdomain, and that's not a tradeoff I'm willing to make for a dev setup.

The free plan is genuinely free. No credit card. The 1-hour tunnel session limit on free is fine for active development. If you want a tunnel that stays up forever (for staging, internal services, or webhook receivers you can't be there to restart), the Hobbyist plan is $2/month.

How do I set this up step by step?

Step 1: Which subdomain should I use?

Pick a subdomain on a domain you already own. Common patterns:

• dev.yourdomain.com for general localhost development

• preview.yourdomain.com for client previews

• hooks.yourdomain.com for webhook receivers

• api.yourdomain.com for local API testing

If you don't own a domain yet, grab one. They're cheap and you'll use it for everything else too. Any registrar works (Namecheap, Porkbun, Route 53, GoDaddy, Cloudflare, whoever).

For this guide I'll use preview.acme.com. Substitute your actual subdomain everywhere.

Step 2: How do I install tunnelto?

tunnelto is a free localhost tunnel with 1 custom domain included on the free plan.

macOS / Linux:

curl -sf https://app.tunnelto.me/install.sh | sh

Windows (via Scoop):

scoop bucket add tunnelto https://github.com/asabi/scoop-tunnelto
scoop install tunnelto

Run tunnelto once after installing and follow the interactive setup. Email-based, takes about 30 seconds.

Step 3: How do I point my subdomain at tunnelto?

In your DNS provider's dashboard, add one CNAME record:

The exact target value comes from tunnelto in the next step. There's nothing to copy or paste manually before that.

Step 4: How do I create the tunnel?

Start your local server (let's say on port 3000), then run:

tunnelto add preview.acme.com 3000

Within a few seconds you should see:

✓ Tunnel Created: https://preview.acme.com -> localhost:3000
✓ SSL certificate will be automatically provisioned on first request.

That's it. https://preview.acme.com is now a public HTTPS URL that forwards every request to localhost:3000 on your machine. The certificate is real (Let's Encrypt) and automatically renewed.

Note: The first load can take a couple of seconds as it provisions your SSL connection.

Step 5: How do I keep the tunnel running across reboots?

If you want the tunnel to stay up automatically, install tunnelto as a system service (the install does it automatically, but just in case):

tunnelto install-service

This registers tunnelto with launchd on macOS, systemd on Linux, or Windows Service. After that, tunnelto start, stop, restart, and status manage it like any other service. The tunnel survives reboots, terminal closes, and laptop sleeps.

What if I want multiple subdomains on the same domain?

Two ways to handle this:

Option 1: Multiple custom domains. Paid plans on tunnelto include more custom domains (3 on Plus, 5 on Pro, up to 100 on Enterprise). Each one is configured independently.

Option 2: Wildcard DNS. tunnelto supports wildcard DNS for custom domains. Configure *.dev.acme.com once, and any subdomain like feature-x.dev.acme.com, staging.dev.acme.com, or branch-42.dev.acme.com routes to your local server. Useful for multi-tenant testing, branch previews, and per-feature subdomains. This counts as a single custom domain.

For most solo developers, the free plan's 1 custom domain plus a wildcard configuration covers everything you'd want.

How do I handle WebSockets, Postgres, or other non-HTTP services?

tunnelto isn't HTTP-only. A few extra options worth knowing:

WebSockets: Set the tunnel's TLS termination to server-tls in the dashboard. In this mode, tunnelto terminates TLS at the edge and forwards raw TCP to your local service, so the WebSocket upgrade passes through transparently. wss:// connections then work through the tunnel like any other HTTPS request.

Raw TCP: Postgres, Redis, SSH, MQTT, game servers, and anything else that speaks raw TCP. Enable "Allow External TCP" on the tunnel from the dashboard. tunnelto allocates a port and exposes it directly.

Static files only, no local server: Pass a directory path instead of a port. tunnelto add demo.acme.com /path/to/build serves the directory contents directly. Useful for sharing static site builds and design mockups without spinning up Nginx or a Vite preview.

Forward to a different machine on your LAN: Pass host:port instead of just a port. tunnelto add api.acme.dev 192.168.1.50:8080 forwards traffic to whichever machine you specify. Useful for tunneling to a Raspberry Pi, Docker host, or VM. The tunnelto client process opens the connection, so whichever machine runs the client must be able to reach the target on its LAN.

Will SSL just work?

Yes. tunnelto provisions a real Let's Encrypt certificate the moment your DNS verification succeeds. There's nothing to copy, no certbot to run, and no renewal cron job to forget about. Browsers trust it like any other public site.

If you ever change DNS providers or add new subdomains, tunnelto re-verifies and re-issues certificates automatically.

Does this work for OAuth callbacks?

Yes, and this is one of the most common reasons to want a custom domain on localhost in the first place. OAuth providers (Google, GitHub, Microsoft, Auth0, Okta) require a stable redirect URI. If your tunnel URL changes every reconnect, every OAuth provider stops trusting your callback and the login flow silently breaks.

With a custom domain, you set the OAuth redirect URI once and forget about it. https://preview.acme.com/auth/callback is yours forever.

A small gotcha: some OAuth providers (Google in particular) won't let you use a custom subdomain for OAuth unless you've verified ownership of the parent domain. Verifying takes a few minutes via TXT record, and once it's done, every subdomain is fair game.

Where do I go from here?

The whole point of putting localhost on a custom domain is to stop thinking about the tunnel URL. It becomes invisible plumbing. Webhook configs, OAuth callbacks, shared previews, and bookmarks all keep working forever.

If you haven't installed tunnelto yet, take 60 seconds to create your free account. The free plan is permanent, includes 1 custom domain, and doesn't ask for a credit card. You can read more about the custom domain use case here, or jump straight to the tunnelto homepage.

Happy tunneling.

1. Every reconnect handed me a new random subdomain, which broke every webhook config and OAuth callback I'd set up the day before.

2. The free tier capped me at one tunnel and one hour of session time before forcing a reconnect.

3. Putting a real domain on a tunnel cost money. Real money. Even though my domain was already paid for.

The fix turned out to be simpler than I thought. This post walks through exactly how I migrated, what changed in my workflow, and what to do if you've already wired ngrok URLs into Stripe, GitHub, OAuth providers, or anywhere else.

Short answer: Install tunnelto, point a subdomain you own at it, and update your old ngrok URLs to the new one. Total time is about 10 minutes for the first tunnel and 30 seconds for each one after.

Why am I leaving ngrok?

Most developers using ngrok bump into the same wall. The free tier is good enough until you start integrating with a real third-party service. Then the random subdomain becomes a problem you can't ignore.

Stripe stores the webhook URL in your account. So does GitHub. So does Slack. So do all your OAuth providers (Google, Microsoft, GitHub, Auth0). Every time the ngrok URL rotates, you have to log into each of those dashboards and update the URL by hand. Forget one and you spend an hour debugging "why are my webhooks failing" before you remember.

There are paid plans that give you a stable subdomain or a custom domain, but they start around $8 per month. That's not a huge amount in absolute terms, but it's a lot for a feature that is essentially "give me a string that doesn't change."

What I actually want is:

• A URL on a domain I already own

• That stays the same forever

• For free

• With HTTPS

• Without a credit card

That's a real list of requirements, and it's the reason I went looking for an alternative.

What's the best free alternative to ngrok?

I tried four. Here's the honest comparison:

I landed on tunnelto because it was the only one that gave me a custom domain on the free plan with any registrar, not just Cloudflare. My domains live at Namecheap and Porkbun, so the Cloudflare option would have meant transferring DNS just to get a tunnel. tunnelto just works with whatever I already have.

That's the rest of this post: how to actually do the migration.

How do I migrate from ngrok to tunnelto?

The migration is six steps. The whole thing takes about 10 minutes the first time.

Step 1: How do I install tunnelto?

tunnelto is a free localhost tunnel that includes 1 custom domain on the free plan. No credit card required.

macOS / Linux:

curl -sf https://app.tunnelto.me/install.sh | sh

Windows (via Scoop):

scoop bucket add tunnelto https://github.com/asabi/scoop-tunnelto
scoop install tunnelto

Sign up at app.tunnelto.me to get your access token, then run tunnelto once and paste the token when prompted. Takes about 30 seconds.

Step 2: Which subdomain should I use to replace my ngrok URL?

Use a subdomain on a domain you already own. My personal pattern is:

• dev.mydomain.com for general localhost development

• hooks.mydomain.com for webhook receivers

• preview.mydomain.com for client previews

For this guide I'll use dev.acme.com. Substitute your real domain everywhere below.

Step 3: How do I point my subdomain at tunnelto?

Add the parent domain (acme.com) in your tunnelto dashboard. The dashboard then shows you two records to add at your DNS provider (Namecheap, Porkbun, GoDaddy, Route 53, anywhere your domain lives):

The TXT record proves you own the domain. The wildcard A record lets tunnelto serve any subdomain under it (dev.acme.com, hooks.acme.com, preview.acme.com, etc.) — that's why you only need one custom domain to cover the whole pattern.

Tip: Many DNS providers auto-append the parent domain when you enter the Name field — if so, enter only _tunnelto-verify and * in the Name field.

DNS changes can take a few minutes to propagate. tunnelto checks both records automatically every 5 minutes, or you can click Verify DNS in the dashboard to check immediately.

Step 4: How do I create the tunnel?

Start your local server (let's say on port 3000), then run:

tunnelto add dev.acme.com 3000

You'll see:

Tunnel created: https://dev.acme.com -> 127.0.0.1:3000
SSL certificate will be automatically provisioned on first request.

That's it. https://dev.acme.com is now a public HTTPS URL forwarding to localhost:3000. The first incoming request triggers Let's Encrypt to issue a real certificate; renewals happen automatically. The URL is yours and it doesn't rotate.

Step 5: How do I update my old ngrok URLs?

This is the part that takes most of the time, and it's also the part that you only do once. Here's a checklist by service:

Stripe

• Dashboard → Developers → Webhooks → click your endpoint → "..." menu → Update details → paste the new URL

• The signing secret stays the same. Don't regenerate it.

GitHub webhooks

• Repo or org Settings → Webhooks → click the webhook → Payload URL field → save

• The webhook secret stays the same.

Slack apps

• api.slack.com → your app → Event Subscriptions → Request URL field

• Slack will re-verify the URL when you save. tunnelto handles the verification challenge correctly.

OAuth providers (Google, GitHub, Microsoft, Auth0, etc.)

• Find the redirect URI list in the OAuth client config

• Replace the ngrok URL with your new tunnelto URL

• This is the most commonly forgotten step. Your OAuth flow will silently fail if you skip it.

Twilio

• Phone number config → Voice/Messaging webhook URL fields

• Update both incoming SMS and incoming voice if you use both.

Shopify app webhooks

• Apps → your app → API Configuration → webhook subscription URLs

Discord interactions

• Application → General Information → Interactions Endpoint URL

Anything else

• Search your codebase for .ngrok-free.app and .ngrok.app to catch hardcoded URLs. There are usually a few.

Step 6: How do I make sure my tunnel stays up?

One more upgrade over the ngrok workflow: tunnelto can run as a background system service so your tunnel stays up across reboots and terminal closes. Run this once:

tunnelto install-service

After that, tunnelto start, stop, restart, and status manage it just like any other launchd/systemd/Windows service. No more "I came in this morning and forgot to start the tunnel before triggering the test webhook."

What if I'm using ngrok features that tunnelto doesn't have?

Honest answer: ngrok has a richer free request inspector UI than tunnelto does, and ngrok's traffic policy / rules engine is more powerful if you're doing complex header rewrites or rate limiting at the tunnel layer. If those features are core to your workflow, you may want to keep both around.

For the 80% case (running a local dev server, receiving webhooks, sharing previews, supporting OAuth callbacks), tunnelto covers everything ngrok does and adds the custom-domain-on-free piece that ngrok charges for.

A few specific notes:

• WebSockets work, with one configuration step. See the WebSocket FAQ on the homepage.

• Raw TCP (Postgres, Redis, SSH, MQTT, game servers) is supported. Configure it per tunnel from the dashboard.

• Bearer + Basic Auth can be enabled together on a single tunnel. Both credentials are bcrypt-hashed at rest, and neither is forwarded upstream.

• Static file hosting without a local server: pass a directory path instead of a port.

• LAN host targets: pass host:port to forward to a Pi, Docker host, or VM on your network.

Will my OAuth and webhook secrets break when I migrate?

No. Webhook signing secrets and OAuth client secrets are tied to the third-party service's account, not to the tunnel URL. When you swap the URL in the third party's dashboard, the secret stays the same.

The only thing that changes is the URL itself. Your application code that verifies signatures (Stripe, GitHub, Slack) doesn't need to change at all. tunnelto forwards the raw request body and headers unchanged, so signature verification works exactly the same way.

The one place to be careful: if you have the ngrok URL hardcoded somewhere in your code or config (not just stored in a third-party dashboard), grep for it before you decommission ngrok. Common spots:

git grep -i "ngrok"

Common offenders include:

• Local .env files with WEBHOOK_BASE_URL or similar

• Test fixtures that hit the tunnel URL

• README setup instructions

• CI environment variables

What do I do with my ngrok account?

Once everything is migrated and you've left a few days for any forgotten integration to surface, you can either downgrade ngrok to the free tier (if you were paying) or delete the account entirely. I downgraded mine first and let it sit unused for a month before deleting it, just to be safe.

Where do I go from here?

The whole point of the migration is that you stop thinking about the tunnel URL. It becomes a permanent, free fixture of your dev setup, like your shell prompt.

If you haven't installed tunnelto yet, take 60 seconds to create your free account. The free plan is permanent, includes 1 custom domain, and doesn't ask for a credit card. You can read more about the ngrok alternative use case here, or jump straight to the tunnelto homepage.

Happy tunneling.