Tips & Tricks for Migrating to Router 2.0

Summary

Heroku Router 2.0 is generally available and is expected to become the default, making migration planning important before rollout. The guidance recommends creating a staging application, enabling the http-routing-2-dot-0 feature, restarting web dynos when needed, and checking response headers and system logs to confirm routing. Router 2.0 identifies requests with Via values such as “2.0 heroku-router” or “1.1 heroku-router,” and its logs add protocol, tls, and tls_version fields. HTTP/2 is enabled by default on custom domains with valid TLS certificates, while HTTP/2 can be disabled through a Labs feature. Keepalives are also enabled between the router and web dynos, but applications using recent Puma versions may need the keepalive opt-out because of a connection-handling bug.

Takeaways

1. 1

   HTTP/2 terminates at the Heroku router, which forwards HTTP/1.1 to the application; HTTP/2 support applies to custom domains, not the built-in herokuapp.com domain.

2. 2

   Router 2.0 log entries use protocol values such as http2.0 and http1.1 and can include tls and tls_version fields, unlike the legacy router’s https or http values.

3. 3

   Recent Puma versions can show significantly longer tail request latencies with Router 2.0 keepalives enabled; the http-disable-keepalive-to-dyno Labs feature provides an opt-out.