// the find
headwaymaps/headway
Self-hostable maps stack, powered by OpenStreetMap.
Headway bundles a full self-hosted maps stack — tile server, Pelias geocoder, Valhalla routing, and a Vue/Quasar frontend — into a single Docker Compose or Kubernetes deployment backed by OpenStreetMap data. It is aimed at teams that want Google Maps-level functionality without the API bill or data dependency. This is not a library; it is an ops project.
1. Genuinely complete stack: Pelias for geocoding, Valhalla for driving/cycling/walking routing, OpenTripPlanner for transit, tileserver-gl for basemap — all pre-wired together. Nobody wants to integrate these four things themselves. 2. Dagger-based build pipeline (Go) gives reproducible container image generation instead of the usual pile of ad-hoc shell scripts — the build is testable and auditable. 3. Pre-configured area definitions for cities and the full planet with sane defaults in `.env` files; you pick a city and run, rather than reading documentation to understand what OSM extract + config combination works. 4. The GTFS transit tooling (`gtfout`) is written in Rust and handles feed merging and bounding box filtering properly, which is the part that usually falls apart in Python glue scripts.
1. amd64 Linux/macOS only — the README says so explicitly. Apple Silicon works through emulation, which is painful for a stack that needs 8GB RAM and 50–100GB disk during data builds. ARM servers are increasingly common in cost-sensitive self-hosted setups. 2. Transit directions are listed as work-in-progress. That is a core feature for anything urban; if you need it today, you are debugging OpenTripPlanner integration yourself. 3. The operational surface is large: six distinct services, each with its own init scripts, config generation, and health checks. The Kubernetes manifests are generated from templates via shell, which means your k8s config is not in a standard tool (Helm, Kustomize) and diffs are painful. 4. Data pipeline is a one-shot offline process — updating to a newer OSM extract or adding a transit feed requires a full rebuild, not an incremental update. For anything that needs reasonably current map data this is a real constraint.