The Apex Domain Battle: Affordable Root Domain Tunnels in 2026

If you’re a developer, freelancer, or agency owner, you already know the magic of tunneling your localhost to the public internet. You build a web application, run it on port 3000, fire up a tunnel, and instantly share a live link with a client halfway across the world.

But there’s a catch that breaks the illusion of a polished, production-ready product: the URL.

For years, the industry standard has restricted developers to auto-generated, randomized URLs like 1a2b3c.ngrok-free.app. If you want to white-label your local server with a custom domain, you’re often steered toward a subdomain (app.yourdomain.com). But what if you want your true root domain — yourdomain.com itself?

Welcome to the apex domain battle. And it’s a more lopsided fight than most comparison articles let on: the market leader, ngrok, doesn’t just make root domains expensive — its own documentation states plainly that it doesn’t support them at all, on any plan, at any price. That single fact reshapes this whole comparison, and it’s the first thing worth getting right before recommending anything.

This article explains why apex domains are hard to tunnel, what ngrok actually does and doesn’t offer in 2026, and how three genuinely different architectures — Pinggy’s DNS relay, Localtonet’s full nameserver delegation, and Cloudflare Tunnel’s CNAME flattening — solve the problem in practice.

1. Understanding the Apex Domain and the CNAME Problem

Before the alternatives, it helps to understand why root domains (also called apex or bare domains) are notoriously harder to tunnel than subdomains.

What is an apex domain?

In DNS hierarchy, the apex domain is the “root” of your domain name — no subdomain prefix.

• Apex/root domain: example.com
• Subdomain: www.example.com, api.example.com, staging.example.com

The CNAME limitation

When you point a custom domain at a tunneling service, the service typically asks you to create a CNAME (Canonical Name) record. A CNAME maps your domain to the provider’s hostname (e.g., mapping app.example.com to tunnel.provider.com).

The trouble is that a CNAME record can’t coexist with any other DNS record type at the same name, and an apex domain (example.com) must carry SOA (Start of Authority) and NS (Name Server) records at its root. Since a CNAME would override those, standard DNS doesn’t allow one at the zone apex — that’s a real constraint of the protocol, not a policy choice by any single provider.

How providers actually work around this

There isn’t one universal fix — different services genuinely use different mechanisms, and the choice matters for what you can and can’t do afterward:

• A/AAAA record relays. The provider gives you static IPv4/IPv6 addresses to place directly in your apex’s A and AAAA records. This is what Pinggy does.
• CNAME flattening (ALIAS/ANAME). Some DNS providers — Cloudflare natively, and others like DNSimple or DNS Made Easy via an ALIAS/ANAME record type — resolve the CNAME target on their own servers and hand the requester a flattened A/AAAA answer. Cloudflare Tunnel relies on this, which is why using it means moving your domain’s authoritative nameservers to Cloudflare.
• Full nameserver delegation. Rather than adding a couple of records to your existing DNS host, you point your domain’s entire nameserver delegation at the provider, who then becomes your DNS host for that domain — MX, TXT, everything. This is a bigger commitment than a relay, but it sidesteps the CNAME-at-apex problem entirely because the provider controls the zone directly. Localtonet uses this model.
• No support at all. Some providers simply don’t offer any of the above for the zone apex, full stop — as you’ll see below, this is ngrok’s actual position, not just its lower-tier position.

2. The Real Problem with Ngrok in 2026

Ngrok pioneered localhost tunneling and remains an excellent product for TCP/TLS/HTTP tunneling with OAuth, SAML, and observability features. But on apex domains specifically, the limitation isn’t a pricing tier — it’s the product itself. Ngrok’s own custom-domains documentation says it in four words: “ngrok does not currently support apex domains.” No footnote about Enterprise, no workaround listed, no A-record option. If you want yourdomain.com with no prefix pointed at an ngrok tunnel, ngrok is not currently a path to that, regardless of what you’re willing to pay.

That’s worth sitting with, because most comparison content — including earlier drafts of this one — frames this as ngrok “reserving root domains for higher tiers,” which implies paying more gets you there. It doesn’t. What paying more gets you is a subdomain custom domain (app.yourdomain.com), configured via a standard CNAME, and only on the Pay-as-you-go plan or above.

Here’s ngrok’s actual 2026 pricing, verified against its own pricing and limits documentation:

• Free — a one-time $5 usage credit, capped at 1 GB of data transfer, 20,000 HTTP requests, and up to 3 online endpoints. You get one auto-assigned dev domain; HTTP(S) endpoints show an interstitial warning page before forwarding traffic.
• Hobbyist ($10/month, or $8/month billed annually) — removes the interstitial page, includes 5 GB of data transfer and 100,000 HTTP requests, and unlocks up to 10 ngrok-branded (not custom) subdomains. No bring-your-own domain of any kind on this tier.
• Pay-as-you-go ($20/month base fee + usage) — the tier required for a true custom domain, but only as a subdomain via CNAME. Custom domains are metered at $0.01 per active endpoint-hour on top of the base fee; a separate $0.27/domain/active-hour fee applies if you bring your own TLS certificate instead of using ngrok’s automatic Let’s Encrypt provisioning.

If you leave a custom subdomain tunnel running ²⁴⁄₇ for a month (730 hours) on Pay-as-you-go, that’s roughly $7.30 in domain metering on top of the $20 base — around $27/month, and that’s before you’ve solved the apex problem at all, because ngrok can’t solve it for you on any plan.

One genuine ngrok workaround worth knowing about: for TCP endpoints specifically, ngrok’s docs describe CNAME-ing a subdomain to your randomly-assigned TCP hostname (e.g., tcp.mydomain.com → 5.tcp.ngrok.io) so at least the hostname looks stable. It’s a real feature, but it’s a subdomain trick for TCP, not an apex-domain solution for HTTP(S).

3. Why Developers Need Root Domain Tunnels

Given that ngrok is out of the running here entirely, why fight this battle at all instead of settling for staging.example.com?

A. White-labeled client demos. Sending a client https://59d3a1.ngrok-free.app reads as “work in progress.” Sending https://staging.youragency.com is better. Sending https://client-startup-name.com — routing straight to your local machine — reads as a finished product mid-Zoom-call, no CI/CD required.

B. Strict webhook testing. Payment and API providers (Stripe, Shopify, Mailgun, and others) require HTTPS webhook endpoints, and some integrations validate against the exact registered domain rather than an arbitrary subdomain. A stable custom domain — apex or subdomain — avoids re-registering callback URLs every time a tunnel restarts.

C. Cookie and CORS behavior. If your frontend sets cookies scoped to the apex domain (.example.com) in production, testing on an auto-generated tunnel domain or an unrelated subdomain can surface cookie- and CORS-related bugs that only show up because the domain shape doesn’t match production. Running local dev on the literal apex domain you’ll use in production eliminates that class of environment-specific bug.

4. The Top Affordable Options for Apex Domains

1. Pinggy — the documented relay approach

Pricing: Pro plan at roughly $3/month billed monthly (~$2.37–$2.50/month billed annually). The free tier is permanently free but tunnels are capped at 60 minutes with random, non-persistent URLs.

Pinggy is a strong pick for apex domains specifically because it publishes an actual mechanism for the CNAME-at-apex problem, called a relay. You verify domain ownership with a TXT record, choose a relay region nearest your traffic, and Pinggy hands you static A and AAAA IP addresses to set on your root domain’s @ record.

One nuance the pricing pages don’t lead with: Pinggy’s own docs note that a relay-based custom domain works for HTTP(S), TLS, and TCP tunnels, but not UDP — if you need a UDP tunnel on your literal apex domain, Pinggy’s persistent subdomain (not the bare root) is the supported path.

Setting it up (real syntax):

# 1. Start your local server
npm run start
# Server listening on http://localhost:3000

# 2. In the Pinggy dashboard (Custom Domains), add your root domain,
#    verify the TXT record, choose a relay region, and add the A/AAAA
#    records it gives you at your DNS provider (host: @)

# 3. Once validated and the certificate is issued, start the tunnel
#    with your Pro token — the domain configured for that token is
#    used automatically:
ssh -p 443 -R0:localhost:3000 <your-token>@pro.pinggy.io

There’s no special inline flag for “use my custom domain” — you attach the domain to your token in the dashboard once, and every tunnel started with that token routes through it. Pinggy provisions a Let’s Encrypt certificate automatically once the DNS records validate.

2. LocalXpose — excellent for subdomains, unconfirmed for true apex

Pricing: Pro plan at $8/month ($96/year), 10 active tunnels, unlimited bandwidth subject to an acceptable-use policy. Free tier includes 2 active HTTP tunnels.

LocalXpose is a genuinely full-featured tunneling tool — HTTP(S), TCP, TLS, and UDP are all supported, along with a native desktop GUI, wildcard subdomains, and IP/basic-auth access controls. Marketing copy for LocalXpose does say it supports “custom domains,” and this is true and valuable for subdomains.

Where the picture gets murkier is the literal apex domain. LocalXpose’s own documentation for setting up a custom domain (loclx domain reserve --domain example.com) walks through creating a CNAME record — the same mechanism that, per the DNS rules in Section 1, cannot legally sit at a zone apex. There’s no published A/AAAA relay flow, TXT-plus-static-IP process, or nameserver delegation option documented anywhere for LocalXpose the way there is for Pinggy or Localtonet. That doesn’t necessarily mean it’s impossible — some DNS providers with CNAME flattening (Cloudflare, DNSimple) could make a CNAME “work” at an apex regardless of what the tunnel provider does — but it means LocalXpose’s own docs don’t currently give you a documented apex path the way its competitors do. If a true root domain is the requirement, it’s worth confirming directly with LocalXpose support rather than assuming parity with Pinggy from feature-comparison pages.

3. Localtonet — apex support via full nameserver delegation

Pricing: ~$2/tunnel/month, charged only while the tunnel is running (pay-as-you-go, no monthly floor). Free tier: 1 tunnel, 1 GB/month, 30-minute session timeout.

Localtonet takes a different, heavier-commitment approach than Pinggy’s relay: rather than adding a couple of records to your existing DNS provider, you register the domain in Localtonet’s DNS Manager and then replace your domain’s authoritative nameservers at your registrar with ns1.localtonet.com and ns2.localtonet.com. From that point, Localtonet is your DNS host for the domain — A, CNAME, MX, and TXT records for it are all managed from the Localtonet dashboard instead of your registrar.

The upside of this heavier setup is that it’s uniform: once nameservers propagate (Localtonet says 1–2 hours typically, up to 48 in rare cases), you can point HTTP, TCP, or UDP tunnels at the bare root domain by simply leaving the subdomain field blank when creating a tunnel — no separate relay flow, and no protocol left out. Automatic Let’s Encrypt HTTPS is included. The trade-off is real, though: you’re handing over DNS control for the whole domain, including email routing (MX/TXT), which is a bigger step than adding a TXT and two A/AAAA records the way Pinggy’s relay does. If you have existing MX records for email on that domain, plan to recreate them in Localtonet’s DNS Manager before you cut over.

4. Cloudflare Tunnel — free, but the most infrastructure-heavy

Pricing: Cloudflare Tunnel itself carries no separate charge and has no bandwidth cap — it’s bundled into Cloudflare’s Zero Trust platform, which has its own free tier (up to 50 users) and an optional $7/user/month Pay-as-you-go tier for identity/access policy features you don’t need just to run a tunnel.

Cloudflare Tunnel (the cloudflared daemon, formerly Argo Tunnel) routes traffic through Cloudflare’s network to a lightweight process on your machine. Because Cloudflare is also a DNS provider, its zone-apex CNAME flattening applies automatically once your domain’s nameservers point to Cloudflare — no A/AAAA IP addresses to babysit, no relay region to pick.

The catch: you have to migrate your domain’s nameservers to Cloudflare (similar commitment to Localtonet’s model, just with a different provider), install and authenticate cloudflared, and set up ingress rules — a meaningfully steeper initial setup than running one SSH command. For a domain you’re going to keep long-term and want production-grade edge infrastructure behind, it’s a strong, genuinely free option. For a five-minute client demo, it’s overkill.

5. Quick Comparison

Provider	Entry price	True apex domain	Mechanism	UDP on apex
ngrok	$10/mo Hobbyist, $20/mo+usage Pay-as-you-go	No — documented as unsupported on any tier	N/A (subdomain-only CNAME on paid tiers)	No (ngrok has no UDP tunnels at all)
Pinggy	~$3/mo	Yes, documented	TXT verification + A/AAAA relay	No (relay excludes UDP)
LocalXpose	$8/mo	Undocumented/unconfirmed	CNAME only (per official docs)	Yes, for subdomains
Localtonet	~$2/tunnel/mo	Yes, documented	Full nameserver delegation	Yes
Cloudflare Tunnel	Free	Yes, documented	CNAME flattening (requires NS migration)	No (Cloudflare Tunnel is HTTP/TCP-focused)

6. Performance and Security Considerations

Exposing localhost to the internet — especially on a highly visible root domain — bypasses your router’s NAT firewall, so a few basics matter regardless of which tool you choose.

Automated TLS. Don’t use a 2026 tunneling tool that lacks automatic HTTPS. Pinggy, LocalXpose, and Localtonet all provision Let’s Encrypt certificates automatically for custom domains.

Geographic latency. If your client is in London and you’re in Tokyo, a tunnel relay in the wrong region adds real latency. Pinggy explicitly lets you choose a relay region; pick the one nearest where your traffic actually originates, not where your laptop sits.

Access control. If your local admin panel or database is reachable at your apex domain, anyone scanning the internet can find it. Use built-in basic auth or IP allow-listing — both Pinggy and LocalXpose support this — and whitelist known IP ranges (a client’s office, a webhook provider’s published IP list) wherever the tool allows it.

7. Conclusion

The apex domain problem is a real DNS constraint, not a marketing gimmick — but the vendor landscape solving it is more differentiated than a simple price comparison suggests. Ngrok isn’t the expensive option here; it’s the option that doesn’t do this at all, on any plan. Pinggy solves it cheaply with a documented, moderate-commitment relay. Localtonet solves it just as thoroughly but asks for full DNS control over the domain. Cloudflare Tunnel solves it for free but asks for the same nameserver commitment plus a steeper setup. LocalXpose is a genuinely capable all-protocol tunnel that, as of this writing, simply hasn’t published an apex-domain mechanism the way its competitors have.

Whichever you pick, the choice isn’t really “cheap vs. expensive” — it’s how much DNS control you’re willing to hand over, and whether every one of your protocols (including UDP, if you need it) actually needs to live at the bare root.

Frequently Asked Questions

Q: Can I use a CNAME record for an apex domain? A: No. Standard DNS doesn’t allow a CNAME to coexist with the SOA and NS records required at a zone apex. You need A/AAAA records, a provider offering CNAME flattening/ALIAS/ANAME, or full nameserver delegation to that provider.

Q: Does ngrok support apex/root domains on any plan, including Enterprise? A: Ngrok’s documentation states unconditionally that it does not currently support apex domains. Even its Pay-as-you-go tier, which does add true custom domains, only supports them as subdomains via CNAME.

Q: Which of these tools actually documents apex domain support? A: Pinggy (via a TXT-verified A/AAAA relay) and Localtonet (via full nameserver delegation) both publish a specific apex-domain mechanism. Cloudflare Tunnel supports it too, via CNAME flattening, once your domain’s nameservers point to Cloudflare. LocalXpose’s public docs only show a CNAME-based flow, which is technically a subdomain mechanism.

Q: Do these alternatives support wildcard subdomains too? A: Yes — Pinggy, LocalXpose, and Localtonet all support wildcard domain routing (*.example.com), which is useful for testing multi-tenant SaaS setups locally.

Q: Are these tunneling services secure by default? A: All the services discussed here provide automatic HTTPS. Since you’re exposing a local machine to the internet, it’s still worth turning on basic auth or IP allow-listing for anything sensitive — these are opt-in features, not defaults.

---

Changelog

Fact-checked against primary sources (ngrok, Pinggy, LocalXpose, and Localtonet official documentation, plus Cloudflare’s DNS and Zero Trust docs) on September 5, 2026. Changes from the original draft:

• Biggest correction, reframes the whole piece: the draft’s premise was that ngrok “restricts base-tier users to subdomains… reserving full root/apex domain support for its higher-priced tiers.” This is false. Ngrok’s own custom-domains documentation states unconditionally, with no tier qualifier, “ngrok does not currently support apex domains” — not on Free, Hobbyist, or Pay-as-you-go. Rewrote Section 2 and the conclusion around this; ngrok’s real limitation on paid tiers is that custom domains are subdomain-only (CNAME-based), separate from the apex issue entirely.
• Corrected ngrok’s free tier from a vague “1 dev domain” description to its documented limits: a one-time $5 usage credit, 1 GB data transfer, 20,000 HTTP requests/month, up to 3 online endpoints, and an interstitial warning page on HTTP(S) endpoints.
• Verified ngrok’s Hobbyist tier ($10/mo, $8/mo annual) explicitly does not include any bring-your-own domain, custom or otherwise — only up to 10 ngrok-branded subdomains — correcting the draft’s implication that Hobbyist offered some subdomain-level custom domain access.
• Added ngrok’s separate $0.27/domain/active-hour bring-your-own-TLS-certificate fee (distinct from the $0.01/hour custom domain metering the draft already had), and added the documented CNAME-to-TCP-hostname workaround ngrok itself publishes for TCP endpoints.
• Added a load-bearing correction for LocalXpose: the draft listed it with unqualified “Root Domain Support: Yes,” but LocalXpose’s own custom-domain tutorial and CLI reservation docs only demonstrate a CNAME-based flow (a subdomain mechanism), with no published A/AAAA relay, TXT-plus-static-IP, or nameserver-delegation option anywhere in its documentation the way Pinggy and Localtonet both have. Reframed LocalXpose’s apex support as undocumented/unconfirmed rather than confirmed, while keeping its verified strengths (full protocol support including UDP, $8/mo Pro, 10 tunnels, unlimited bandwidth) intact.
• Corrected Localtonet’s apex mechanism: the draft implied it works like Pinggy’s relay. It doesn’t — Localtonet requires migrating the domain’s authoritative nameservers to ns1.localtonet.com/ns2.localtonet.com, making Localtonet the DNS host for the entire domain (MX/TXT included), not just adding a couple of relay records. Added the real setup flow and the email-record migration caveat.
• Corrected Pinggy’s real technical mechanism and added a nuance missing from the draft: relay-based custom domains work for HTTP(S)/TLS/TCP but explicitly not UDP, per Pinggy’s own relay documentation.
• Replaced the draft’s fabricated Pinggy SSH syntax (ssh -p 443 -R 0:localhost:3000 -t a@pinggy.io "custom_domain: example.com", which is not real Pinggy syntax) with the documented command pattern (ssh -p 443 -R0:localhost:3000 <token>@pro.pinggy.io), where the custom domain is attached to the token via the dashboard rather than passed inline.
• Updated Pinggy pricing to ~$3/month billed monthly (~$2.37–$2.50/month annual), replacing the draft’s flat “$3.00/month,” and added that Pinggy’s free tier now carries a 60-minute session cap with non-persistent URLs.
• Confirmed LocalXpose Pro pricing ($8/month, $96/year, 10 active tunnels, unlimited bandwidth subject to acceptable use) and free tier (2 active HTTP tunnels), replacing the draft’s unsourced figures.
• Confirmed Localtonet’s pay-as-you-go pricing (~$2/tunnel/month, charged only while running) and free-tier limits (1 tunnel, 1 GB/month, 30-minute timeout) against localtonet.com directly.
• Clarified Cloudflare Tunnel’s actual cost structure: the tunnel itself is free and uncapped; the $7/user/month figure belongs to Cloudflare Zero Trust’s optional identity/access add-ons, not to running a tunnel with a custom domain, correcting the draft’s vague “free” framing into something sourced and specific.
• Removed the draft’s unsupported claim that some enterprise APIs/OAuth providers “refuse” tunnel URLs due to “phishing and abuse concerns” as a blanket assertion; softened to a general, unattributed industry pattern (webhook/API providers validating against a stable registered domain) rather than presenting a specific enforcement policy as fact.
• Added a comparison table summarizing entry pricing, apex-domain status, underlying mechanism, and UDP-on-apex support across all four providers, since these turned out to differ enough between vendors that a prose-only comparison undersold the differences.
• Removed inline scaffolding (broken markdown-in-parens links, stray extra spaces) and stripped source metadata from the original draft.