High-performance self-hosted routing on OpenStreetMap data, honestly reviewed. No marketing fluff, just what you get when you run it yourself.

TL;DR

What it is: A high-performance C++ routing engine built on OpenStreetMap data — the open-source infrastructure behind turn-by-turn directions, distance matrices, and GPS map-matching [README].
Who it’s for: Developers and technical founders who need routing API calls at volume and are tired of Google Maps or Mapbox per-request billing. Not a no-code tool. Someone needs to write code to use it [README][1].
Cost savings: Google Maps Directions API costs $5 per 1,000 requests after the $200/month free credit. At 100,000 requests/month that’s roughly $300–$450/mo. OSRM self-hosted on a dedicated VPS runs the same load for $20–40/mo in compute [2].
Key strength: Genuinely fast — sub-millisecond routing on continental road networks. The Contraction Hierarchies pipeline is still the best option for bulk distance matrix calculations [1][README].
Key weakness: This is infrastructure, not a product. There’s no admin UI, no managed cloud tier, no SaaS fallback. The public demo server (router.project-osrm.org) has been returning 504 Gateway Timeout errors in 2024 [5]. If you need it working, you host it yourself.

What is Open Source Routing Machine (OSRM)

OSRM is a C++ routing engine that processes OpenStreetMap data and exposes routing functionality via HTTP API, C++ library, and a Node.js wrapper. The project has been around since roughly 2010 and sits at 7,570 GitHub stars. The license is BSD-2-Clause — permissive, commercial-friendly, no strings attached [README].

What it actually does: you feed it an OSM extract (a .pbf file of a city, country, or continent downloaded from Geofabrik), run a preprocessing step that builds a routing graph, and then you have a local HTTP server that answers routing questions in milliseconds. The API exposes six services [README]:

Route — finds the fastest route between two or more coordinates
Table — computes a duration/distance matrix for all pairs of N coordinates (the expensive thing you’d otherwise pay Google for)
Nearest — snaps a GPS coordinate to the closest street segment
Match — fits a noisy GPS trace onto the road network (useful for fleet tracking)
Trip — solves the Travelling Salesman Problem via greedy heuristic for multi-stop optimization
Tile — generates Mapbox Vector Tiles with routing metadata for visualization

The project’s homepage describes it as: “Modern C++ routing engine for shortest paths in road networks. Handles continental sized networks within milliseconds” [website]. That’s the honest pitch. It doesn’t try to be a full mapping platform — it’s a routing engine you call from your application.

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

The people reaching for OSRM are almost always reacting to an API bill that surprised them. Routing APIs have a sneaky cost structure: the free tier feels generous until your app gets traction, then you’re suddenly paying per-request at scale.

Versus Google Maps Platform. The Directions API charges $5 per 1,000 requests after the first $200/month credit (roughly 40,000 free requests). The Distance Matrix API — the bulk-computation endpoint that OSRM’s table service replicates — charges $10 per 1,000 elements, where each origin-destination pair is an element. A 10×10 matrix is 100 elements. At any real logistics scale, this compounds fast. OSRM’s table service handles the same calculations with no per-request cost once deployed [1][2].

Versus Mapbox. Mapbox’s Directions API pricing is similar in structure to Google’s. The Matrix API also charges per element. For consumer mapping Mapbox’s rendering quality is better, but for backend routing logic where you don’t need tiles, you’re paying for capabilities you don’t use.

Versus pgRouting. This is the most direct technical comparison. pgRouting lives inside PostgreSQL and leverages PostGIS spatial indexes. OSRM uses a custom preprocessed graph format (Contraction Hierarchies or Multi-Level Dijkstra) [1]. The trade-off is clear: pgRouting gives you more routing algorithm options, built-in constraints like turn restrictions and time-dependent routing, and deep integration with a PostgreSQL ecosystem. OSRM gives you dramatically faster response times for standard route and matrix queries. If you’re already running PostGIS and need flexible constraints, pgRouting is the right tool. If you need speed and simplicity, OSRM wins [1].

On OpenStreetMap data quality. OSRM is a consumer of OSM data, not a replacement for it [2]. The map quality in North America and Western Europe is excellent. In less-mapped regions it degrades. Any errors in OSM coverage show up as routing errors in OSRM — OSRM doesn’t fix the underlying data, it just routes on what’s there.

Features

Routing algorithms:

Multi-Level Dijkstra (MLD) — recommended default. Supports dynamic edge weights, making it suitable for live traffic integration in principle [README].
Contraction Hierarchies (CH) — the older pipeline. Faster for large distance matrix queries (the table service) but doesn’t support dynamic weights [1][README].

API services in practice:

The route endpoint returns geometry (encoded polyline), step-by-step instructions via osrm-text-instructions, duration, and distance [README][docs].
The table endpoint is the main reason logistics companies use this — compute durations between every combination of N depots and M delivery points in a single request [1].
The match endpoint takes a list of GPS coordinates with optional timestamps and snaps them to the road network — useful for cleaning up fleet telemetry data [README].
The trip endpoint implements a Travelling Salesman heuristic. It won’t find the globally optimal route for 20 stops, but it’s fast and good enough for most delivery sequencing tasks [README].

Profiles (transportation modes): The engine uses Lua scripts (“profiles”) to define how road attributes map to routing weights. Built-in profiles cover car, bicycle, and foot. You can write custom profiles for trucks, emergency vehicles, or any mode with specific road restrictions [3][README]. Hiking trail support is limited by default — OSRM doesn’t support OSM route relations out of the box, which matters for official trail networks [3].

Integration: Available as Docker images, an npm package (osrm), and a C++ library. The Docker path is the recommended starting point [README]. A separate osrm-frontend repository provides a Leaflet-based map interface for testing — this is what runs at the public demo server [README].

Pricing: SaaS vs self-hosted math

There is no commercial OSRM SaaS. The software is BSD-licensed and entirely self-hosted [README]. Pricing comparison is entirely against alternatives.

Google Maps Distance Matrix API:

$10 per 1,000 elements
10×10 matrix = 100 elements = $1.00
1,000 such queries/day = $1,000/day at scale

Google Maps Directions API:

$5 per 1,000 requests
100,000 requests/month ≈ $500/month minus the $200 credit = $300/month

OSRM self-hosted, equivalent load:

VPS with 4–8 GB RAM for a country-scale dataset: $15–40/month (Hetzner, Contabo, DigitalOcean)
OSM data updates: free from Geofabrik, but re-preprocessing takes compute time
Your engineering time to set up and maintain

Concrete example: A small logistics app computing 500 distance matrices per day (each 10×10 = 100 elements). On Google Maps: 500 × 100 × $0.01 = $1,500/month. On OSRM on a $20 Hetzner VPS: $20/month. That’s a $17,760/year difference — enough to hire someone to maintain it.

The math only works at volume. Under a few thousand API calls per month, the free tier on Google or Mapbox covers you and there’s no reason to operate infrastructure. Past that threshold, the case for self-hosting becomes harder to ignore.

Deployment reality check

The README’s recommended path is Docker, and it works — but “works” requires some qualification.

Step 1: Download OSM data. Geofabrik provides regional extracts by country and continent. Germany’s Berlin extract is a few hundred MB. Full India is around 550 MB. The continental USA is several GB [README].

Step 2: Preprocessing. This is the step that surprises people. Running osrm-extract on a 550 MB Mexico file takes around 30 minutes on modest hardware, per the README’s own example [README]. A full country like the USA takes hours. You do this once (or on data updates), not on every request — but the initial setup time is non-trivial, and if you’re running on a server with limited RAM, it may fail.

One Stack Overflow question documents an OSRM extraction failure on a full India map even with 32 GB RAM [5]. Large regions require either chunking the data or provisioning significant hardware for the preprocessing step.

Step 3: Run the server. After preprocessing, the routing server itself is lightweight. A preprocessed Germany graph runs comfortably on 2–4 GB RAM [README].

What you need:

Docker installed on a Linux VPS
4+ GB RAM for most country-scale datasets (more for preprocessing)
Disk space for raw PBF + preprocessed files (multiply raw PBF size by roughly 3–5x)
A reverse proxy (nginx or Caddy) for HTTPS if serving externally

What can go sideways:

The public demo server (router.project-osrm.org) has been returning 504 errors and 500 errors as of late 2024 [5]. Don’t use it for production. Don’t rely on it for testing at scale.
Preprocessing time is a real operational concern. If you need daily map updates and have a large region, you’re scheduling multi-hour processing jobs [README][5].
There is no web UI for monitoring or administration. The only interface is the HTTP API and whatever you build on top.
Setting up the osrm-frontend (the map UI) requires a separate Docker container and additional configuration — it’s not wired up automatically [5].

Realistic time estimate for a developer comfortable with Docker: 2–4 hours for a working country-level instance. For someone who’s never run Docker: budget a full day and expect to Google error messages.

Pros and cons

Pros

BSD-2-Clause license. Genuinely permissive. Use it commercially, embed it in products, deploy it for clients — no commercial agreement, no usage limits, no licensing calls [README].
Fast. Sub-millisecond routing on continental networks is a real capability, not marketing. The Contraction Hierarchies algorithm has been studied and benchmarked extensively [1][2].
Distance matrix at scale. The table service is the killer feature for logistics applications. One request, N×M pairs, no per-element billing [1].
Multiple routing modes via Lua profiles. Car, bike, foot included; custom profiles possible [3][README].
GPS map-matching. The match service is the only free self-hosted option for serious GPS trace cleaning outside of dedicated commercial platforms [README].
Active developer community. 7,570 stars, Discord server, ongoing CI/CD [README].

Cons

Developer tool only. There is no admin UI, no dashboard, no web interface for non-technical users. Every integration requires writing code [README].
No managed SaaS fallback. If your server goes down, you’re down. There’s no paid tier to fall back on. Unlike n8n or Activepieces where a managed cloud exists, OSRM is infrastructure you own entirely [README].
Preprocessing complexity at scale. Large regions require significant RAM and compute time. 32 GB RAM isn’t always enough for India [5].
Public demo server is unreliable. The official demo at router.project-osrm.org has documented 504 and 500 errors [5]. Don’t build against it.
No dynamic traffic. MLD supports dynamic weights in principle, but integrating live traffic data requires your own pipeline. Out of the box, routing is based on static speed estimates from the OSM profile [1].
Routing constraints are limited. Toll road avoidance, vehicle-specific restrictions, and time-dependent routing require custom Lua profile work. pgRouting handles these more elegantly [1].
Hiking and trail routing is second-class. OSRM doesn’t support OSM route relations natively, which limits usefulness for official hiking and cycling trail networks [3].
No official SLA, no support contract. It’s a community project. Questions go to GitHub issues and Discord. If you need guaranteed support, you’re paying a consultant.

Who should use this / who shouldn’t

Use OSRM if:

You’re building a product that makes routing or distance matrix API calls at volume and the Google Maps bill is becoming a line item worth optimizing.
You have a developer on the team (or can hire one) who can set up and maintain Docker-based infrastructure.
Your use case is car routing in well-mapped regions (North America, Europe, East Asia).
You need GPS map-matching to clean up fleet or delivery telemetry.
You want BSD-licensed routing infrastructure you can embed in a commercial product without legal complexity.

Skip it if:

You need a no-code solution. There is nothing here for non-technical users to click on.
Your routing needs are simple and under the Google Maps free tier (under ~40,000 requests/month). Self-hosting is more expensive than free.
You need live traffic data. OSRM doesn’t provide it and integrating it is a real engineering project.
You need robust hiking, cycling trail, or multi-modal (transit + walking) routing. OSRM’s profile system can be extended but it’s not designed for this [3].
You’re routing in a region where OSM coverage is sparse. OSRM is only as good as the underlying map data [2].

Pick pgRouting instead if:

You’re already running PostgreSQL/PostGIS and want routing without a separate service.
You need flexible routing constraints (turn restrictions, vehicle types, time-dependent speeds) without writing Lua [1].
You need network analysis beyond routing: nearest facility, driving distance polygons, TSP with complex constraints [1].

Pick Valhalla instead if:

You need turn-by-turn navigation with elevation data, multimodal routing (transit + foot + bike), and better international road coverage. Valhalla is the other major open-source routing engine and is more feature-complete for consumer navigation use cases.

Alternatives worth considering

Valhalla — the other major open-source routing engine from Mapbox. Supports multimodal routing, elevation, better narrative instructions. More complex to deploy than OSRM, more features for consumer navigation.
pgRouting — PostgreSQL extension. Easier if you’re already on Postgres, more flexible routing constraints, slower for high-throughput queries [1].
GraphHopper — Java-based routing engine. Commercial hosting available, good documentation, supports custom models for routing preferences. A reasonable middle ground between OSRM’s raw performance and more feature-complete engines.
OpenRouteService — Java-based, self-hostable, more routing options out of the box (isochrones, elevation, wheelchair routing). Slower than OSRM.
Google Maps Platform — the obvious paid alternative. Easiest integration, best data quality globally, per-request pricing that scales badly at volume.
Mapbox Directions — similar to Google, better for custom map styling, same per-request cost model at scale.
HERE Routing — enterprise-focused, competitive pricing for high volume, proprietary.

For a developer team running routing at volume, the realistic comparison is OSRM vs Valhalla vs GraphHopper. OSRM wins on raw speed. Valhalla wins on features. GraphHopper wins on documentation and ease of deployment.

Bottom line

OSRM is mature infrastructure for a specific problem: high-throughput routing on OpenStreetMap data without paying per-request. The BSD license, C++ performance, and distance matrix capability make it the standard choice for logistics and fleet management applications that need to escape Google Maps API bills. The trade-offs are real — no managed cloud, no UI, preprocessing complexity at scale, no dynamic traffic — but for the target audience (a development team running hundreds of thousands of routing queries per month), those trade-offs are worth it. The math is not subtle: $20/month on a VPS versus hundreds or thousands per month on commercial APIs.

What it isn’t: a tool you hand to a non-technical founder to deploy on a Tuesday afternoon. Someone needs to own the infrastructure, handle map data updates, and monitor the server. If the engineering time and operational overhead is the blocker, that’s the kind of deployment work upready.dev handles for clients — one-time setup, you own the stack.