An ngrok custom domain lets you serve a tunnel through a hostname you own, such as preview.example.com, instead of an auto-assigned ngrok hostname.
That can improve trust, make OAuth callbacks easier, and keep links stable across sessions. It also adds account, plan, and DNS setup that may be unnecessary for a short local review.
This guide explains the current setup path, the cost surface to check, and when a temporary review link fits better.
ngrok custom domain: what it means
In ngrok’s current docs, domains enable public endpoints with hostnames matching a domain object on your account. The domain can be ngrok-managed or a domain you bring yourself.
For bring-your-own domains, ngrok says you must already own the domain. ngrok is not a registrar. The custom domain guide also states that custom domains are available on the Pay-as-you-go plan.
For free accounts, ngrok’s domain docs state that you get an assigned dev domain and cannot choose or reserve custom domain names. Plan details can change, so verify the pricing and limits page before you commit.
Basic ngrok custom domain setup
The official setup has three main steps.
First, add the domain in the ngrok dashboard. ngrok gives you a CNAME target.
Second, add the CNAME record at your DNS provider. The docs show CNAME as the record type and the ngrok-provided value as the target.
Third, start an endpoint with that domain:
ngrok http --url preview.example.com 3000
After DNS resolves and ngrok provisions the endpoint, traffic to the custom hostname forwards to your local port.
This path works best when the hostname matters across repeated sessions, not just one review.
Costs and limits to check
Avoid hard-coding pricing assumptions into a workflow. Tunnel vendors change plans.
As of the current ngrok docs fetched for this article, the Pay-as-you-go page describes a base monthly fee with included usage, and the domain docs list bring-your-own domains under Pay-as-you-go. The pricing and limits docs also list request, transfer, connection, endpoint, and user limits by plan.
Check these items before you decide:
- Does your plan support custom domains?
- Does your plan include the endpoint hours you need?
- Do request and data-transfer limits match your usage?
- Do you need wildcard domains?
- Do you need custom TLS certificates or dedicated IPs?
- Will the link be public, or will you add authentication?
If you only need one stakeholder review, those questions may be more work than the review itself.
Custom domain benefits
A custom domain helps when trust and stability matter.
OAuth providers often require registered callback URLs. A stable hostname avoids updating callback settings for every random tunnel URL.
Clients may trust preview.yourcompany.com more than a random provider subdomain. Internal tools may also need allowlists, cookie domains, or host-based routing that works better with a known domain.
Teams that use ngrok daily can treat a custom domain as part of the development platform.
Those benefits matter. They just belong to recurring workflows, not every demo.
Custom domain tradeoffs
A custom domain adds friction:
- You need domain ownership.
- You need access to DNS.
- DNS propagation can delay setup.
- The plan must support the domain feature.
- The hostname can feel permanent even when the app is unfinished.
- Someone must own cleanup and access controls. For unfinished local builds, permanence can work against you. A reviewer may reuse an old URL after the local app has changed. A short TTL makes that mistake less likely.
Temporary review links as an alternative
If the goal is a local review, you may not need a branded hostname. You need a link that opens, expires, and shows what happened.
wiremaven creates temporary encrypted public links for local dev servers. It uses an outbound WebSocket relay from your machine and supports 15, 30, or 60 minute TTLs. During beta, no account is required.
npx wiremaven-cli 3000 --expires 30m --name client-review
The developer sees viewer joins, request outcomes, failure events, and remaining session time. That turns the review into a monitored session instead of a loose public URL.
For setup, see the wiremaven docs. For the relay model, read how wiremaven works.
When to use each path
| Need | Best fit |
|---|---|
| Stable OAuth callback | ngrok custom domain |
| Repeated demos on a trusted hostname | ngrok custom domain |
| One-off client review | Temporary review link |
| Webhook debugging with traffic inspection | ngrok endpoint and inspector |
| Short QA check from localhost | wiremaven review URL |
The domain decision should follow the workflow, so do not buy permanence for work that needs a 30 minute review window.
FAQ
Is ngrok custom domain free?
Check the current ngrok pricing page before you decide. The docs reviewed for this article state that free accounts get an auto-assigned dev domain and custom domains are available on Pay-as-you-go.
Can I use an apex domain with ngrok?
The current ngrok custom domain docs state that apex domains are not supported. Use a subdomain such as preview.example.com.
Do I need a custom domain for client review?
No. A temporary HTTPS link with a short TTL and live session signals is enough for most local reviews.
Start with the review window
If you need a stable domain, configure ngrok and DNS. If you need a short local review, start with a temporary link:
npx wiremaven-cli 3000 --expires 30m
Related: ngrok skip browser warning and ngrok alternatives.