Edges vs. Tunnels: Choosing the Default for Multi‑Service Exposure in ngrok v4

The Recommendation

For a deployment exposing three HTTP services on a single subdomain, the default should be an Edge. While legacy tunnels are simpler to launch, they cannot natively share a single subdomain across multiple services without external routing. An Edge acts as a programmable gateway, allowing you to route traffic to different local services based on path prefixes (e.g., /service1, /service2) using one public entry point.

Analysis of Constraints

Plan Limits and Cost

The choice depends heavily on your budget and scale:

• Paid Plans (Edges): Required for shared subdomains and HTTP/2. If your architecture requires a professional production-like URL structure or high-performance protocols, the cost of a paid plan is a prerequisite for using Edges.
• Free Plans (Tunnels): If cost is the primary constraint, you must use separate tunnels. This results in three distinct ngrok URLs, which increases management overhead and prevents a unified API gateway experience.

Protocol Flexibility

Tunnels are restricted to one protocol per service. Edges provide greater flexibility by allowing explicit hosts and protocols entries, making them the superior choice for complex environments where multiple protocols must be managed under a single domain.

Manual Migration Workflow

Because ngrok config migrate may not preserve all protocol settings or complex routing logic, use the following manual adjustment workflow when converting from v3 tunnels to v4 edges:

1. Audit v3 Config: Document all local ports and assigned domains from the legacy tunnels block.
2. Define the Edge: Create the Edge resource via the ngrok dashboard or CLI to establish the primary public hostname.
3. Map Backends: Manually add endpoints to the Edge configuration, mapping specific path patterns to the local addresses identified in step 1.
4. Verify Protocols: Explicitly define the protocols (e.g., http, https) in the v4 config file to ensure the Edge handles traffic as expected.

Verification Command

To verify if your current account supports Edge creation before committing to a migration, run:

ngrok edge create --name "my-gateway"

Missing Diagnostic Detail

To refine this recommendation: Are these services intended for internal development or external production access? If they are for temporary local development, the overhead of Edge configuration and paid plans may outweigh the benefits of a shared subdomain.