GraphHopper

Open-source routing and route optimization, honestly reviewed. No marketing fluff, just what you get when you self-host it or use the managed API.

TL;DR

• What it is: An open-source (Apache-2.0) routing engine built on OpenStreetMap data. Runs as a Java library or standalone web server. Also available as a managed Directions API with route optimization [README].
• Who it’s for: Developers and technical founders building location-aware apps — delivery software, fleet management, logistics tools, outdoor navigation apps — who are tired of paying Google Maps API bills that scale with usage.
• Cost savings: Google Maps Directions API costs $5 per 1,000 requests. At any meaningful scale, that adds up fast. Self-hosted GraphHopper runs on your own server with $0 per-request cost [README][website].
• Key strength: Serious routing depth — custom vehicle profiles, turn restrictions, isochrone analysis, map matching, and a flexible custom model system that lets you tune how routes are calculated without writing Java [4][5].
• Key weakness: It’s fundamentally a developer tool, not a no-code product. Setup requires Java knowledge (or Docker), and the round-trip routing algorithm has real limitations that at least one developer publicly documented [2]. Non-technical founders will need engineering help to deploy and integrate it.

---

What is GraphHopper

GraphHopper is a routing engine — the software that answers “what’s the fastest path from A to B?” It’s built in Java, uses OpenStreetMap data by default, and has been in active development long enough to accumulate 6,361 GitHub stars and a production user base the company describes as 600+ companies worldwide [website].

The project operates in two modes that are worth keeping separate in your head. First, there’s the open-source routing engine (Apache-2.0 licensed) that you compile and run yourself — this is what developers embed in their applications or run as an internal web server. Second, there’s the GraphHopper Directions API, a managed cloud service the company sells for teams that want the routing capabilities without the operational overhead of running Java infrastructure [website][README].

Beyond basic A-to-B routing, GraphHopper handles map matching (snapping GPS tracks to the road network), isochrone calculation (which areas can you reach within X minutes?), and route optimization — the harder problem of ordering multiple stops efficiently. The route optimization piece targets logistics and delivery use cases specifically, and the website claims it can save up to 30% on time and fuel costs [website].

The company is based in Munich, Germany, is a member of the OpenStreetMap Foundation, and has been shipping major version releases consistently — version 11.0 dropped in October 2025 [README][website].

---

Why people choose it

The GraphHopper forum [4] is active enough to be a useful signal: developers are running self-hosted instances for real production workloads, including custom bike route planners, hiking applications, and delivery dispatch systems. The questions being asked — custom model tuning, urban density weighting, GTFS integration, landmark algorithms — indicate a user base that’s pushed well past “hello world” use.

Versus Google Maps Directions API. This is the primary cost driver that sends developers toward GraphHopper. Google charges per API call. At $5 per 1,000 requests, an application doing 100,000 routing requests per month is paying $500/month just for directions. Self-hosted GraphHopper flips that model: you pay for infrastructure (a VPS), not per request. A server that handles your entire routing workload costs $20-50/month regardless of request volume.

Versus Mapbox Directions API. Mapbox offers a more generous free tier (100,000 requests/month before billing starts), but once you cross that threshold the costs compound similarly. GraphHopper’s self-hosted option removes the ceiling entirely.

Versus OSRM and Valhalla. The two other serious open-source routing engines. OSRM is extremely fast but rigid — you preprocess a graph for specific profiles and re-processing takes hours for large regions. Valhalla is more flexible and easier to configure. GraphHopper sits between them: fast (Contraction Hierarchies preprocessing), but with more runtime flexibility via the custom model system that OSRM lacks [4][5].

The honest developer assessment from Trail Router [2]: One developer building a nature-favoring running route planner evaluated GraphHopper specifically for round-trip routing and found the algorithm “too naive” for their use case. GraphHopper’s round-trip routing works by drawing a circle and routing between waypoints along it — it doesn’t seek out green features like parks or rivers. The developer ended up extending OpenRouteService (which is itself based on GraphHopper) and generating their own greenery data instead. This is a real limitation worth knowing before you assume GraphHopper’s round-trip feature is sophisticated [2].

---

Features

Core routing:

• Turn-by-turn directions with road attributes, distances, and travel times [README]
• Support for multiple simultaneous routing profiles [4][5]
• Built-in vehicle profiles: car, bike, mountain bike, racing bike, foot, hiking, wheelchair, scooters, delivery trucks, cargo bikes [website][4]
• Custom profiles — define your own weighting based on road attributes, speed, access restrictions, surface type [4][5]
• Custom model system: fine-tune routing behavior via JSON config without touching Java code [5]
• Contraction Hierarchies (CH) for fast speed-mode routing; Landmark (LM) hybrid mode for more flexible queries [5]
• Turn restriction support [README]
• Import OpenStreetMap PBF files, GTFS data for transit routing, and other data sources [README]

Analysis tools:

• Isochrone calculation: reachability polygons for given time/distance limits [README]
• Map matching: snap GPS coordinate traces to the road network [README][4]
• Snap-to-road [README]

Route optimization (separate product, same API):

• Vehicle Routing Problem (VRP) solver for multi-stop delivery optimization [website]
• Handles time windows, vehicle capacities, driver constraints, workload balancing [website]
• Recent additions: multiple reasons for unassigned jobs, workload balancing across drivers [website blog]

Self-hosting specifics:

• Runs as a standalone web server (Jetty embedded) or as a Java library [README]
• Docker support [merged profile]
• Preprocessing required for each OSM region (pbf file ingestion) — this takes time and disk space for large regions
• Web UI (GraphHopper Maps) bundled [README]
• Active community forum with developer support [4]

---

Pricing: SaaS vs self-hosted math

GraphHopper Directions API (managed): The pricing page was partially unavailable at scrape time, so specific tier numbers aren’t available here — check https://www.graphhopper.com/pricing/ directly for current figures. The website describes “fair, effort-based pricing that scales with your needs” and a “recommended plan” calculator on the pricing page [website].

Self-hosted (open-source engine):

• Software license: $0 (Apache-2.0) [README]
• VPS or cloud instance to run it: varies by region size
• Small country or metro area: 2-4GB RAM, $10-20/month VPS adequate
• Full Europe or US: 16GB+ RAM for graph storage, $80-150/month for a serious instance
• Your ops time for maintenance and OSM data refreshes

Google Maps Platform for comparison:

• Directions API: $5 per 1,000 requests
• 50,000 requests/month: $250/month
• 200,000 requests/month: $1,000/month
• Route Optimization API: separate, higher pricing

Concrete math: A logistics startup doing 50,000 routing queries per day (not unusual for a fleet of 20 drivers using the app every few minutes throughout a workday) would pay $250/day or roughly $7,500/month to Google. A self-hosted GraphHopper instance on a $150/month server handles that same workload for $150/month. The payback period on the engineering time to set it up is measured in days, not months.

The managed GraphHopper API sits between these extremes — useful for teams who want OSM-based routing without Google’s terms of service restrictions and at lower price per request, but without the operational work of running Java infrastructure themselves.

---

Deployment reality check

This is where GraphHopper diverges sharply from the other tools reviewed on this site. It is not a “spin up a Docker container and you’re done in 20 minutes” experience.

What the setup actually involves:

1. Download an OSM PBF file for your target region from Geofabrik or similar
2. Run the GraphHopper import process, which preprocesses the graph — this is CPU and RAM intensive and can take anywhere from minutes (a single city) to hours (a full continent) [README]
3. The processed graph persists to disk and GraphHopper loads it into memory at startup
4. For large regions, graph storage requires significant RAM — a full Europe or US graph can consume 8-20GB
5. Configure routing profiles, CH/LM modes, and custom models via a YAML config file [5]
6. Set up a reverse proxy for HTTPS if you’re exposing it externally

What can go wrong:

• The forum [4] shows real users hitting issues: GraphHopper “stuck at Starting Server on Windows 11 (WSL)”, strange map matching results, configuration errors for custom profiles. These are solvable but they require troubleshooting comfort.
• OSM data goes stale. You need a process to periodically re-import updated PBF files if you want current road data. There’s no auto-update.
• Round-trip routing is limited in sophistication — as documented publicly by the Trail Router developer [2], it routes between equidistant waypoints on a circle, without environmental preference awareness.
• The custom model system is powerful but has a learning curve — forum posts show experienced developers spending time getting urban density weighting, curvature settings, and access restrictions right [4][5].

Realistic time estimates:

• Developer comfortable with Java/Docker, routing a single city: 2-4 hours to working deployment.
• Non-technical founder: not a realistic solo project. You need an engineer.
• A dev who’s done it before setting up a VPS with a regional graph, configured profiles, and a reverse proxy: half a day.

---

Pros and Cons

Pros

• Apache-2.0 license — permissive. Use it commercially, embed it in a product, resell it, no restrictions [README]. No “Fair-code” games.
• Zero per-request cost when self-hosted. The math becomes compelling very quickly for any application doing meaningful routing volume.
• Custom model system is genuinely powerful — tune routing behavior via JSON without writing Java. Experienced users run highly specialized profiles (hiking with elevation, urban vs. rural bike routing, truck dimension restrictions) [4][5].
• Full routing stack in one package: directions, isochrones, map matching, route optimization — not just A-to-B.
• Active project with consistent major releases (v8 through v11 in 2023-2025) and a real company behind it [website][README].
• World-wide coverage via OpenStreetMap — no country or region restrictions [website].
• Permissive commercial terms: use it for vehicle tracking, navigation apps, delivery software — the website explicitly calls these out [website].
• Production battle-tested: 600+ companies in production, with named customers in logistics and navigation [website].

Cons

• Not for non-technical users. There’s no admin UI for routing configuration, no drag-and-drop profile builder. You edit YAML and JSON files [README][5].
• Round-trip routing is naive. Documented limitation: it doesn’t seek out favorable terrain or scenery — it geometrically places waypoints on a circle [2]. If you need intelligent round-trip route discovery, you’ll need to extend it or look elsewhere.
• Java runtime requirement. Most developers today are comfortable with Node, Python, or Go. Java adds toolchain overhead that’s unfamiliar for many small teams.
• Graph preprocessing is slow for large regions. Re-importing updated OSM data for large areas takes hours and temporary memory/CPU spikes [README].
• No built-in live traffic. OSM data is static — there’s no real-time traffic feed out of the box. Commercial alternatives include traffic data that GraphHopper won’t have unless you pay for or integrate a traffic layer separately.
• Managed API pricing is opaque. The pricing page requires a calculator interaction rather than clear published tiers [website].
• Memory hungry at scale. Large regional graphs require serious RAM. This rules out cheap 1-2GB VPS options for anything beyond city-scale deployment.

---

Who should use this / who shouldn’t

Use GraphHopper if:

• You’re building a product with significant routing volume — delivery dispatch, fleet tracking, field service scheduling — and Google Maps API costs are already painful or will become painful.
• You have at least one developer comfortable with Java or Docker who can handle the deployment and occasional maintenance.
• You need routing customization that managed APIs won’t give you — custom vehicle profiles, access restriction tuning, elevation-aware weighting.
• Data sovereignty matters. Every route calculation staying inside your own infrastructure is a feature, not just a cost consideration.
• You’re building on OpenStreetMap data and want aligned tooling.

Skip it if:

• You’re a non-technical founder without engineering support. The deployment and configuration work is real and ongoing.
• Your routing needs are simple (basic A-to-B car directions for occasional queries). Just use the Mapbox free tier.
• You need sophisticated round-trip route discovery that factors in scenery, terrain character, or dynamically sourced preferences [2].
• Real-time traffic is non-negotiable for your use case.
• You need a routing API operational in a day. GraphHopper self-hosted requires setup time.

---

Alternatives worth considering

• OSRM (Open Source Routing Machine) — fastest raw routing performance, simpler to deploy for fixed profiles, but almost no runtime flexibility. Good if your profiles are stable and speed is critical.
• Valhalla — open-source, more flexible at runtime than OSRM, good multi-modal (transit + walking) support. Worth comparing if you’re already in the OpenStreetMap space.
• OpenRouteService — built on top of GraphHopper, adds more functionality including greenery routing profiles (Germany only at last check), hosted API available [2].
• Google Maps Platform Directions API — easiest integration, real-time traffic, massive ecosystem. Expensive at volume, proprietary, usage terms restrict some use cases. The benchmark everything is priced against.
• Mapbox Directions API — competitive free tier, good developer experience, proprietary. Reasonable choice if your volume stays under their free threshold.
• HERE Routing API — enterprise-grade, strong traffic data, higher cost. Relevant for automotive or fleet management at serious scale.
• Valhalla via Stadia Maps — managed hosting for Valhalla with OSM data if you want the flexibility without the Java ops.

---

Bottom line

GraphHopper is the right answer to a specific question: “how do I get serious routing capabilities into my product without paying per-API-call forever?” The Apache-2.0 license, world-wide OSM coverage, and depth of routing features (custom models, isochrones, map matching, VRP optimization) make it the most complete open-source routing stack available. The forum activity shows a real engineering community running real production workloads.

But the target audience here is developers, not non-technical founders. If you’re paying $500+/month in Google Maps API costs and you have an engineer on your team, GraphHopper’s self-hosted option deserves serious evaluation — the payback math is fast. If you don’t have engineering support, this is not a self-service tool. The managed GraphHopper Directions API is a middle path — you get OSM-based routing without the operational overhead, at commercial-API pricing that’s typically more favorable than Google’s for equivalent capabilities.

One last honest note: if your specific need is sophisticated round-trip route planning that seeks out parks, trails, or scenery — the built-in round-trip algorithm is documented as naive by at least one developer who evaluated it for exactly that use case [2]. Know the limitation before you build around it.

---

Sources

1. AndroidFreeware — Critical Maps APK Download (app built with Apache-2.0 tools including GraphHopper). https://www.androidfreeware.net/download-critical-maps-apk.html
2. Tom Conroy, Trail Router Blog — “How Trail Router works” (2020-06-03). Includes first-hand evaluation and documented limitations of GraphHopper’s round-trip routing algorithm. https://trailrouter.com/blog/how-trail-router-works/
3. AlternativeTo — “Apple Maps Alternatives” (updated July 2025). Context for the open-source mapping and routing alternatives landscape. https://alternativeto.net/software/apple-maps/?p=3
4. GraphHopper Forum — Open Source Routing Engine — Active developer community, real-world deployment questions and solutions. https://discuss.graphhopper.com/c/graphhopper/6
5. GraphHopper Forum — “Urban Density for bike?” (September 2025). Real self-hosted deployment example with custom model configuration for a bike route planner. https://discuss.graphhopper.com/t/urban-density-for-bike/9760

Primary sources:

• GitHub repository and README: https://github.com/graphhopper/graphhopper (6,361 stars, Apache-2.0 license)
• Official website: https://www.graphhopper.com/
• Pricing page: https://www.graphhopper.com/pricing/
• Documentation: https://github.com/graphhopper/graphhopper/blob/master/docs/index.md