Traffic Policy is now 10x cheaper, and idle custom domains are free

At ngrok we’re building infrastructure that developers trust in production. Pricing changes are rarely popular, so I wanted to lay out what we’re doing clearly. We recently made three changes:

• Traffic Policy pricing drops by 10x. TPUs are now much cheaper.
• Custom domains move to active-only billing. You only pay when the domain is actually receiving traffic. For most users, this is much cheaper.
• Endpoint Pooling now bills per active endpoint. This is the one change that will increase costs for a small number of heavy users.

The first two are straightforward improvements. The third is a correction to how we were counting usage.

Traffic Policy (TPUs)

Traffic Policy lets you do things like block AI scrapers, enforce auth, rate limit, or rewrite URLs. We measure the work with Traffic Processing Units (TPUs) because different rules have very different costs to our infrastructure when we run them on your behalf.

We’re lowering the price of TPUs by 10x: from $1 to $0.10 per 100k, with volume discounts kicking in past 1M.

If you were spending $1,000/month on TPUs before, the same usage should now cost around $100/month. We made this change on June 22, and it rolls out with no plan changes or configuration required: the new rates apply automatically at the start of your next billing cycle.

For free users, your $5 signup credit will now go a lot further. Rules that used to burn through that credit in days now cost a tenth as much to run.

This change makes it practical to run serious protection (blocking bots, authentication, etc.) without it becoming expensive. There’s no reason to have an unprotected ngrok endpoint on the public internet anymore.

See the pricing page for the full rate table.

Custom domains: pay only when live and active

Previously we charged for custom domains by the hour from the moment you added them, even if nothing was hitting them. Starting June 29, we’re only charging for hours when the domain actually receives traffic, at a flat $0.01 per hour. Quiet domains (staging environments, preview deploys, domains you’ve set up but aren’t using yet) won’t cost anything.

This will help teams with bursty traffic, seasonal workloads, or anyone who likes to set things up ahead of time without paying for idle time. To cut costs even further, apply Traffic Policy to your endpoints to block unwanted visitors, like bots and scrapers, before they ever reach your upstream service. At the new TPU rates, that protection costs a tenth of what it used to.

Endpoint pooling changes

This is the one change that isn’t a price reduction. Endpoint Pooling is our built-in load balancing: multiple endpoints sharing the same URL. Before, we treated an entire pool as one active endpoint for billing purposes. Going forward, each endpoint in the pool that’s actively handling traffic bills separately.

Idle endpoints, even when pooled, still don’t cost anything. The feature (how pools form, how traffic is distributed, policies, etc.) hasn’t changed. We’re making this change because the previous model didn’t reflect the actual infrastructure we were running on your behalf. It’s more accurate and consistent with the active-only direction we’re moving in elsewhere. I’ve already emailed the small number of accounts (under 1% of our total user base) where this will have a noticeable impact. For most people running small pools (2–3 endpoints), the difference should be modest.

Why we’re making these changes

ngrok is infrastructure. Primitives like endpoints, Traffic Policy, custom domains, and endpoint pools are stable building blocks, and we plan to make them cheaper and simpler to run at every scale.

For too long, our pricing made more sense for someone testing services on localhost than for someone who ships something to production and leaves it running. Active-only billing, TPU costs that don’t punish you for protecting your endpoints, and pooling that reflects actual usage are all moves in the same direction: pricing that gets out of the way when you’re building something real.

We’ll keep adjusting as we learn what actually matters to people running real workloads. If any of this is unclear, or if the impact on your account is worse than expected, reply to the email we sent or email me directly at sam@ngrok.com. I read and reply to each one.

Thanks for using ngrok.