(Headway maintainer here)

Indeed there is currently no incremental update in Headway, and deployments are largely an exercise left to the reader.

For maps.earth (a Headway planet deployment), I typically rebuild the world, and then do a blue/green deployment.

I guess the one exception is for transit routing. We have individual transit zones small enough to fit into memory, which can be deployed incrementally. There’s nothing really built in about it - just another level of indirection via our “travelmux” service which redirects your routing queries to a different backend depending on mode and region.

Thanks for chiming in - super helpful context.

I am trying to learn from real deployments as I design Corviont's updater for edge boxes (bandwidth caps, maintenance windows, unreliable WAN, atomic swap + rollback).

When you say transit "zones" are small enough to deploy incrementally - what is the actual artifact per zone (roughly what format), and what sizes do you typically see?

And when a transit zone dataset changes, how do you roll that out safely - do you restart/reload the backend that serves that zone, or do you bring up a new backend/version and then flip travelmux to point at it?