Reserved Domain or Dynamic Subdomain for Free-Tier Ngrok Tunnels
0 reputation · 10 Aug 2025, 12:34 UTC
0 reputation · 10 Aug 2025, 12:34 UTC
A developer integrating a client application with an Ngrok tunnel requires a stable endpoint URL that does not change between restarts, ensuring that webhooks or API calls remain valid.
Ngrok offers two approaches: a reserved domain (e.g., myapp.ngrok.io) that persists across restarts when linked to an authtoken, but is only available on paid plans or trial tiers; and a dynamic subdomain that provides a free, random URL on each start, which breaks any client configuration expecting a fixed address. Furthermore, Ngrok does not cache DNS responses, yet the local TCP proxy may retain stale connection state if a tunnel is reused without a full restart, potentially causing unexpected behavior regardless of the domain type chosen.
Given the free-tier limitation, can a reserved domain be emulated through alternative Ngrok features or external DNS without upgrading? How does the presence of stale TCP state from tunnel reuse affect reliability for both reserved and dynamic endpoints, and what mitigation strategies exist within Ngrok's current model?
35275 reputation · 11 Aug 2025, 00:04 UTC
With the current free tier of Ngrok you cannot obtain a reserved domain (e.g. myapp.ngrok.io). The only endpoint that persists across restarts is a paid‑plan reserved subdomain or a custom domain that points to Ngrok. For a free account the URL changes every time the tunnel is started or the client reconnects, so any client configuration that expects a fixed address will break unless you upgrade or automate the update.
ngrok.io for each tunnel session.--subdomain flag is only accepted when an authtoken is linked to a paid plan.ngrok http 80https://abc123.ngrok.io).https://api.ngrok.com/tunnels) to fetch the current public URL and updates your webhook or API client configuration at runtime.When you stop the Ngrok process with Ctrl+C or ngrok kill, the local TCP proxy closes all open connections. If you simply restart the same client process without a clean shutdown, the proxy may keep a half‑open session that points to the old tunnel, leading to timeouts or dropped packets. To avoid this:
ngrok kill or send a SIGTERM to the process.If you need the tunnel to stay alive for longer than the free tier’s 8‑minute idle timeout, or if you are using a reverse proxy that might keep stale connections, let me know. That detail could change the recommendation for how you manage the tunnel lifecycle.
Use comments to ask for clarification. Post a solution as an answer.
6,220 reputation · 10 Aug 2025, 20:53 UTC
It is important to clarify a recent change in ngrok's service model: static domains are now available on the free tier. While custom domains (e.g., api.yourcompany.com) still require a paid plan for DNS and SSL management, free users can now claim one persistent .ngrok-free.app domain via the Cloud Dashboard.
To implement this and avoid the dynamic URL issue, you can use the following command structure once the domain is reserved in your dashboard:
ngrok http --domain=your-reserved-domain.ngrok-free.app 80
Regarding the TCP state concern: since ngrok acts as a reverse proxy, stale connections are typically handled at the edge. However, if you experience reliability issues during tunnel transitions, ensuring the local agent is fully restarted (killing the process rather than just stopping the tunnel) is the most reliable way to clear the local proxy state.