Introduction:

We’re excited to announce public beta support for HTTP/2 on both Heroku Common Runtime and Private Spaces. HTTP/2 support is one of the most requested and desired improvements for the Heroku platform. HTTP/2 is significantly faster than HTTP 1.1 by introducing features like multiplexing and header compression to reduce latency and therefore improve the end-user experience of Heroku apps.

Since 2023, we’ve been working on a large platform modernization of our Common Runtime router. This project will allow us to start delivering more modern networking for Heroku. With the majority of that work now complete, we’re excited to focus more on the future and new features.

What...

Today we are announcing that Session Affinity routing is now generally available as a fully supported part of the Heroku Platform. When Session Affinity is enabled for an app, requests from a given browser will always be routed to the same Dyno. Under the hood, the Heroku Router will add a cookie to all incoming requests from new clients; this cookie allows subsequent requests from that client to return to the same Dyno. With specific clients bound to specific Dynos, apps that depend on ‘sticky sessions’ can still take advantage of Heroku’s flexible scaling.

We introduced Session Affinity in Heroku Labs last April. Since then, many customers have built apps with the new routing strategy...

HTTP routing on Heroku is made up of three main logical layers:

1. The state synchronization layer ensures that all nodes in the routing stack are aware of the latest changes in domains, application, and dyno locations across the platform;
2. The routing layer chooses which dyno will handle an HTTP request (random or sticky), performs logging, error-reporting, and so on;
3. The HTTP proxying layer handles the validation, normalization, and forwarding of requests between clients and dynos.

This last part is the one the platform team is happy to open-source today with the Vegur library.

The Heroku Routing team does a lot of work with Erlang, both in terms of development and maintenance, to make sure the platform scales smoothly as it continues to grow.

Over time we've learned some hard-earned lessons about making systems that can scale with some amounts of reliability (or rather, we've definitely learned what doesn't work), and about what kind of operational work we may expect to have to do in anger.

This kind of knowledge usually remains embedded within the teams that develop it, and tends to die when individuals leave or change roles. When new members join the team, it gets transmitted informally, over incident simulations, code reviews, and other similar...