Open-source routing and geospatial APIs, honestly reviewed. No marketing fluff, just what you get when you self-host it.

TL;DR

What it is: Open-source (GPL-3.0) routing and geospatial API server — think Google Maps Directions API, but running on your own server and consuming free OpenStreetMap data [README].
Who it’s for: Developers and founders building apps that need routing, isochrones, or distance matrices — and who are tired of per-request billing from Google Maps or Mapbox. Also logistics companies, humanitarian organizations, and GIS analysts who need customizable routing profiles [README][4].
Cost savings: Google Maps Directions API costs around $5 per 1,000 requests. At 10,000 daily requests that’s $1,500/month. OpenRouteService self-hosted runs on a VPS and the requests are free [README][4].
Key strength: Seven specialized API endpoints under one service — directions for 14+ travel profiles, isochrones, distance matrices, snapping, and export — all built on OpenStreetMap data [README].
Key weakness: The self-hosted Docker version is significantly less complete than the public hosted API. Geocoding (Pelias), POI search, elevation, and VROOM vehicle routing optimization are separate services not bundled with the core — something that catches most new users off guard [1][README].

What is OpenRouteService

OpenRouteService (ORS) is a Java-based routing engine that sits on top of OpenStreetMap data and exposes it through a clean REST API. Built and maintained by HeiGIT (Heidelberg Institute for Geoinformation Technology), it’s been powering humanitarian logistics, academic research, and commercial apps since 2008. The GitHub description is honest about what it is: “The open source route planner api with plenty of features.” No hype [README].

Under the hood, ORS uses a forked version of GraphHopper 4.0 to build weighted routing graphs from OSM .pbf files. You feed it a region’s OSM data, it builds the graph (this can take significant time and RAM for large regions), and then it serves requests against that pre-built graph at high speed. The graph-first approach means startup time and memory usage scale with region size, not with request volume — a key tradeoff to understand before you deploy [README].

The project sits at 1,848 GitHub stars — modest compared to OSRM or Valhalla, but ORS has breadth where those tools have speed. It covers more travel profiles (driving-car, driving-hgv, cycling-regular, cycling-road, cycling-mountain, cycling-electric, foot-walking, foot-hiking, wheelchair, and more) and adds isochrones and matrix endpoints that OSRM doesn’t offer natively [README][4].

HeiGIT describes ORS as humanitarian-focused: “We want to make life better and easier. Therefore, we constantly develop our services to meet current needs of people and search for new ways to engage in disaster prevention and relief” [website]. This isn’t just marketing — the New York Times used ORS to analyze subway accessibility for disabled residents in New York, and HeiGIT maintains a disaster management client with hourly OSM graph rebuilds for active disaster zones [website].

Why people choose it over Google Maps, Mapbox, and OSRM

The honest case for OpenRouteService comes down to three things: cost at scale, data ownership, and routing profile breadth.

Versus Google Maps / Mapbox. This is where the economics are most clear. Google Maps Directions API bills per request. At 10,000 requests per day — not an unusual number for a logistics app or delivery SaaS — you’re looking at roughly $1,500/month just for routing calls, before you add geocoding, maps tiles, or anything else. Mapbox’s Directions API is cheaper but follows the same metered model. With ORS self-hosted, you pay for the VPS and your OSM data download, and then requests are unlimited. Elestio’s fully managed ORS starts at $14/month including automated backups, SSL, and updates [4]. The math is hard to argue with for any application doing meaningful routing volume.

Versus OSRM. OSRM (Open Source Routing Machine) is the speed king — it uses Contraction Hierarchies preprocessing for near-instant route lookups and is what powers many OpenStreetMap-based apps. But OSRM gives you routes and distances, period. It doesn’t have isochrones, distance matrices as a first-class API, vehicle dimension constraints, or the 14+ travel profiles ORS offers. If you need just fast A-to-B directions, OSRM or Valhalla might be better fits. If you need routing plus reachability analysis plus logistics matrices, ORS is the option that packages it all [README].

Versus Valhalla. Valhalla (used by Mapbox) is C++-based, fast, and supports most of what ORS does including isochrones. It has a more permissive MIT license. If MIT licensing matters for commercial embedding, Valhalla wins on that dimension — ORS is GPL-3.0, which is a copyleft license with commercial use implications [README].

On humanitarian use. ORS’s institutional backing by HeiGIT and the Missing Maps project means the project has maintained serious investment in wheelchair routing, pedestrian accessibility analysis, and disaster response tooling that commercial APIs don’t prioritize [website]. If you’re building anything in the accessibility or humanitarian space, that depth matters.

Features: what it actually does

Based on the README, documentation, and website:

Core routing API endpoints:

Directions Service: Route calculation for 14+ travel profiles including driving-car, driving-hgv (heavy goods vehicle with dimension/weight constraints), cycling variants, foot-walking, foot-hiking, and wheelchair. Returns turn-by-turn instructions, geometry, duration, and distance. Supports avoid_features (highways, tollways, ferries, fords, steps) [README][2].
Isochrones Service: Computes reachability areas — “what can I reach within 15 minutes driving from this point?” Useful for logistics coverage analysis, real estate search radius, healthcare accessibility mapping [README][4].
Matrix Service: Many-to-many time and distance calculation. Feed it 50 origins and 50 destinations, get a 50×50 matrix back. Essential for delivery route optimization [README][4].
Snapping Service: Snap arbitrary GPS coordinates to the nearest road network point [README].
Export Service: Download the underlying routing graph for external analysis, such as calculating edge centrality [README][website].
Health and Status endpoints: Instance health checks — only available on self-hosted instances, not the public API [README].

What is NOT included in the self-hosted Docker version:

This is the most important thing to understand before you start. The public API at openrouteservice.org includes several services that are separate standalone projects and are NOT bundled with the core ORS Docker image:

Pelias geocoding (address-to-coordinates and reverse) — separate service, requires its own data pipeline [1][README]
openpoiservice — points of interest search, separate service [README]
openelevationservice — elevation data based on SRTM, separate service [README]
VROOM — vehicle routing optimization (traveling salesman / VRP), separate service [README]

A Stack Overflow user discovered this the hard way when their pelias_search() calls threw 404s against a self-hosted instance — routing worked fine, but geocoding simply doesn’t exist in the core package [1]. The README acknowledges this, but it’s buried, and the disconnect between the public API and what you get when you self-host trips up most first-time deployers [1][README].

Version 8.0 highlights (recent):

Low RAM option for running smaller regions on constrained hardware
New Docker Compose setup
Run as JAR (finally) without Docker
Overhauled configuration system
Improved logging [website]

Pricing: SaaS vs self-hosted math

OpenRouteService public API (their hosted version):

Free tier: up to 500 isochrones/day, 2,000 directions requests/day [website]
Paid plans: sign up on openrouteservice.org — tiered by request volume
The API is designed for development and small production workloads; heavy commercial use is expected to self-host

Self-hosted:

Software license: $0 (GPL-3.0) [README]
VPS: $6–20/month depending on region size and RAM needs
Elestio fully managed: starting at $14/month, includes automated backups, SSL, updates, monitoring [4]
Your time for setup and OSM data management

Google Maps Directions API for comparison:

$5 per 1,000 requests
Free monthly credit of $200 (~40,000 requests)
Past the free tier: 10,000 requests/day = ~$1,500/month
100,000 requests/day = ~$15,000/month

Concrete example:

A logistics SaaS computing delivery routes: 50,000 matrix calculations per day to optimize driver routes. On Google Maps Distance Matrix API that’s roughly $5,000–10,000/month. On ORS self-hosted on a $40/month dedicated server with enough RAM for your region’s graph, it’s $40/month. The math is straightforward. The only question is whether your engineering team can handle the operational overhead.

GPL-3.0 licensing caveat: if you’re embedding ORS directly in commercial software you ship to customers, the GPL-3.0 copyleft requirements apply — you may need to open-source your integration code or use the API over HTTP (which is generally considered outside the GPL’s distribution scope). Consult a lawyer if this matters for your product structure. [README]

Deployment reality check

ORS’s Docker-first deployment is reasonably well documented, but the RAM and storage requirements surprise people who don’t read the documentation before spinning up a $6 VPS.

What you actually need:

A Linux VPS with at minimum 2GB RAM for small regions (a single country); 8–16GB RAM for continental-scale graphs; 32GB+ for full planet routing
Docker and docker-compose
Significant storage: Germany’s OSM extract is ~4GB; the full planet is ~75GB uncompressed
Time: graph building for a large country can take 30–90 minutes on first startup
A domain and reverse proxy (nginx or Caddy) for HTTPS
Separate setup if you need geocoding (Nominatim or self-hosted Pelias), POI search, or elevation — none of these are bundled [1][README]

What can go sideways:

Version 9.4.0 had a documented bug where highway/motorway avoidance via avoid_features silently stopped working — routes still calculated, just ignored the avoidance setting. The bug was fixed in 9.5.0 and never affected the public API, but anyone self-hosting on 9.4.0 would have shipped broken behavior without obvious errors [2].

Geocoding is the most common deployment gotcha. If your app needs to convert addresses to coordinates (and most routing apps do), you’re setting up a second service — either self-hosted Nominatim, self-hosted Pelias, or a third-party geocoding API. ORS doesn’t do this for you, and the error you get when you call pelias_search() against a vanilla Docker install is a cryptic JSON decode error, not a helpful “this endpoint doesn’t exist in self-hosted” message [1].

The openpoiservice setup also has friction. Forum posts from 2020 document database connection issues during initial data import that required debugging docker-compose networking — the kind of setup problem that still appears in the support forum years later [3].

Realistic time estimates:

Technical user who has deployed Docker apps before: 1–3 hours for core routing to work, not counting graph build time
Adding geocoding via Nominatim: another 2–4 hours and a separate VPS or significantly more RAM
Non-technical founder following a guide: not recommended solo; this is a project that needs a developer

Pros and cons

Pros

Free at any request volume. Once self-hosted, routing calculations cost nothing per-call. For high-volume applications the economics are compelling [README][4].
14+ routing profiles out of the box. Car, HGV with vehicle dimensions, multiple cycling profiles, walking, hiking, wheelchair — more travel modes than any comparable open-source routing engine [README][4].
Isochrones and matrix endpoints included. Most routing engines make you build these yourself. ORS ships them as first-class API endpoints [README].
OpenStreetMap data. No vendor-controlled data layer. OSM data is global, free, and improving constantly [README][website].
Humanitarian depth. Wheelchair routing profiles, accessibility analysis, disaster management client — genuine investment in edge cases that commercial APIs skip [website].
Version 8.0 low RAM option makes small-region deployments viable on modest hardware [website].
Well-documented REST API with an interactive playground at openrouteservice.org [website].
Active support forum (ask.openrouteservice.org) with HeiGIT staff responding to issues [2][3].

Cons

Geocoding not included. The single biggest source of confusion for new deployments. If you need address search, you’re running a separate service [1][README].
GPL-3.0 license. Not MIT, not Apache 2.0. Copyleft implications for commercial software distribution. Valhalla (MIT) or OSRM (Apache 2.0/MIT) are better choices if license permissiveness matters [README].
RAM-hungry for large regions. A full national routing graph for a large country will require 8–16GB RAM minimum. The $6 VPS pitch doesn’t hold for anything beyond a small city or region [README].
Java-based overhead. JVM startup time and heap configuration add operational complexity compared to C++-based alternatives like OSRM or Valhalla.
Graph build time on first start. Large regions take 30–90 minutes to initialize. Cold starts and region updates are slow operations [README].
Separate services for full feature parity. To match the public API you’d need: core ORS + Pelias + openpoiservice + openelevationservice + VROOM. Each is a separate deployment and maintenance burden [README][1][3].
Modest community. 1,848 GitHub stars is small for a routing engine. n8n has 100K+, OSRM has 6K+. Smaller community means fewer guides, fewer integrations, slower ecosystem [README].
Bugs do ship. The v9.4.0 highway avoidance bug — where the routing worked but silently ignored user preferences — is the kind of silent failure that’s hard to catch without specific test cases [2].

Who should use this / who shouldn’t

Use OpenRouteService if:

You’re building a logistics, delivery, or field service app that makes tens of thousands of routing API calls per month, and your Google Maps bill is approaching $500+/month.
You need isochrones (reachability zones) as a first-class API, not something you have to build yourself.
You’re working in humanitarian, accessibility, or academic GIS — the wheelchair routing profiles and humanitarian tooling are meaningfully better than commercial alternatives.
You have a developer who can manage a Docker deployment and handle the initial OSM data setup.
You need vehicle dimension constraints (height, width, weight) for HGV routing — this is rare to find in open-source alternatives.

Skip it (use OSRM instead) if:

You need raw routing speed above all else and don’t need isochrones or matrices.
Your region is large and RAM is constrained — OSRM’s MLD algorithm is more memory-efficient than ORS for pure directions.

Skip it (use Valhalla instead) if:

MIT licensing for commercial embedding is a requirement.
You need good documentation in English, a larger GitHub community, and more recent development activity.

Skip it (stay on Google Maps) if:

Your request volume is low enough to stay in the $200/month free credit tier.
You need geocoding and maps tiles bundled in one API with a single billing relationship.
You have no one to manage infrastructure.

Skip it (use Nominatim-only) if:

All you need is geocoding (address search) — ORS isn’t the right tool for that use case, and its bundled Pelias is a separate service anyway [1].

Alternatives worth considering

OSRM (Open Source Routing Machine) — C++, Apache/MIT license, fastest open-source routing engine. Does directions and matrices. No isochrones. Great for pure A-to-B routing at scale.
Valhalla — C++, MIT license, used by Mapbox. Comparable feature set to ORS including isochrones. More permissive license, larger community.
GraphHopper — Java (same lineage as ORS — ORS uses a fork), Apache 2.0 license. Well-documented, active community. More polished than ORS for pure routing; no isochrones in the free edition.
Google Maps Platform — easiest integration, global coverage with real-time traffic, expensive at scale. The obvious incumbent ORS displaces.
Mapbox Directions API — cheaper than Google, developer-friendly, still metered and closed-source.
HERE Routing API — strong for enterprise logistics and live traffic; generous free tier (250K transactions/month); closed-source SaaS.
Nominatim — if you only need geocoding, run Nominatim (MIT) separately rather than ORS + Pelias.

For a non-technical founder escaping Google Maps bills, the realistic shortlist is ORS vs GraphHopper vs Valhalla. Pick ORS if you specifically need isochrones, wheelchair profiles, or humanitarian tooling. Pick Valhalla if MIT licensing matters. Pick GraphHopper if you want the most mature Java-based routing with better documentation.

Bottom line

OpenRouteService is a legitimate, production-grade routing engine with a solid feature set and institutional backing from HeiGIT. The economics for high-volume routing are compelling — the difference between $1,500/month on Google Maps and $15/month self-hosted is hard to ignore once your application reaches meaningful scale [4]. The isochrones and matrix endpoints being first-class, and the depth of travel profiles including real wheelchair accessibility, make it genuinely differentiated in the open-source space.

The honest caveat: ORS is not a drop-in replacement for Google Maps Platform. It’s a routing engine that covers one part of what Google Maps does. Geocoding, elevation, and POI search require separate service deployments, and the gap between what the public API offers and what you get with docker-compose up will catch you off guard if you don’t read carefully first [1][README]. The GPL-3.0 license adds complexity for commercial products. And the operational overhead — RAM sizing for large regions, graph build times, multi-service architecture — is real work that requires developer attention.

For the right use case — a developer or technical team building logistics, field service, or geospatial analysis that’s paying meaningful money to a routing API vendor — ORS is worth the setup cost. For a non-technical founder wanting to add a map to their app, it’s probably too much infrastructure to manage alone.

If the infrastructure part is the blocker, that’s exactly what upready.dev deploys for clients. One-time setup fee, you own the stack.

Sources

Stack Overflow — “Self-hosted OpenRouteService (Python) geocoding error” (Mar 2024). https://stackoverflow.com/questions/78167359/self-hosted-openrouteservice-python-geocoding-error
OpenRouteService Community Forum — “Avoid Highways/Motorways has no effect” (Dec 2025). https://ask.openrouteservice.org/t/avoid-highways-motorways-has-no-effect/7826
OpenRouteService Community Forum — “Unable to create DB or import data — openpoiservice” (Feb 2020). https://ask.openrouteservice.org/t/unable-to-create-db-or-import-data/1336
Elestio — “Managed Openrouteservice as a Service”. https://elest.io/open-source/openrouteservice
Elestio — “Development | Managed Open-Source”. https://elest.io/fully-managed-services/development

Primary sources:

GitHub repository and README: https://github.com/giscience/openrouteservice (1,848 stars, GPL-3.0 license)
Official website: https://openrouteservice.org
API documentation: https://giscience.github.io/openrouteservice/api-reference/
Demo map client: https://maps.openrouteservice.org

Features

Integrations & APIs

REST API

Related Maps & Geolocation Tools

View all 30 →

Organic Maps

13K

Organic Maps is a self-hosted privacy & encryption tool with support for privacy, android, ios.

maps geo

Dawarich

8.4K

Dawarich gives you visualize your location history on your own infrastructure.

maps geo AGPL-3.0

Open Source Routing Machine (OSRM)

7.6K

Released under BSD-2-Clause, Open Source Routing Machine (OSRM) provides high performance routing engine designed to run on OpenStreetMap data and offering...

maps geo BSD-2-Clause