HerokuElizabeth CoxExplainer
Router 2.0 Common Runtime Router: The Road to Beta
Summary
Heroku’s Router 2.0 is a beta replacement for the Common Runtime’s Erlang-based “Hermes” router, which is planned to be replaced in 2024. The project addresses the difficulty of safely delivering upgrades from a legacy custom HTTP server and aims to share routing code with the Go-based Private Spaces router; common functionality has been extracted into an internal HTTP library. Architecturally, Router 2.0 is an L7 router running in memory behind the existing L4 proxy, alongside Hermes, allowing app-level traffic to move from the old path without a big-bang cutover. The team added continuous load testing that exercises scaling policies and blocks deployments missing internal service-level objectives, and introduced Network Error Logging to measure browser-observed failures. Feature parity is still incomplete, with HTTP/2 planned next; apps can opt into the beta using a Heroku Labs command.
Context
Hermes, the Common Runtime’s legacy Erlang router, became difficult to upgrade as Erlang expertise and contributions to its dependencies declined. The team pinned relevant software versions after failed upgrade attempts, but the old Erlang version blocked features such as HTTP/2 and made significant router upgrades risky.
Approach / What changed
Router 2.0 uses Go and shares functionality with the Private Spaces router through an internal HTTP library. An L7 router runs in memory behind the existing L4 proxy, allowing traffic to be directed incrementally between Hermes and Router 2.0. Continuous load testing, deployment-pipeline checks, autoscaling validation, and Network Error Logging support production readiness.
Takeaways
Router 2.0 is written in Go to match team expertise and share routing code with the Go-based Private Spaces router through an internal HTTP library.
The L4 proxy sends default-routing traffic through Hermes, while apps enabled for Router 2.0 use an in-memory listener to reach the new router, supporting a gradual strangler-pattern migration.
Continuous load tests push staging routers to their limits, exercise scaling policies, and feed results into the deployment pipeline, which blocks releases that miss internal service-level objectives.
Source and freshness
- Source
- heroku.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.