The whole MapMap stack, on your own infrastructure.
Everything we run at api.mapmap.ai also runs as one Docker Compose stack under your own keys and your own data boundary: the gateway, our routing engine, an optional geocoder, and the MCP server.
The API: routing, ADR, metered keys, OpenAPI, llms.txt
Route computation with the bounded ADR costing extension
Forward and reverse geocoding, first-party or via Photon
Agent access to your own deployment over HTTP
The same stack. Yours, not ours.
There is no separate self-hosted product to fall behind the hosted one. It is the same gateway and the same routing engine, brought up on your infrastructure from the same distro/ checkout.
Weighing it against a sales-quoted on-premises licence? Self-hosting compared with Mapbox Atlas sets the two side by side on licence scope, caching terms and published price, with every claim about Atlas linked to Mapbox’s own documentation.

Routing, ADR and metered keys behind one API
The gateway serves routing, the ADR dangerous-goods costing, metered API keys, the OpenAPI schema and llms.txt. It’s the same surface your app already calls at api.mapmap.ai, pointed at your own origin instead. ADR tunnel enforcement requires the MapMap Valhalla image, which the Compose distro does not yet ship by default; dimensional constraints work on the stock build.

Pre-built packages, not a live OSM build
A bootstrap build straight from a Geofabrik OSM extract works for a first run. Production deployments install a signed territory package instead, which skips the tile build entirely and supports air-gapped installs.
Measured clearance is separate data again: a clearance field is baked per survey dataset and served from your own point-cloud directory, and a deployment holding none answers 501 rather than guessing.
Valhalla, GraphHopper, or auto
SN_ROUTING_ENGINE selects the routing engine, and a GraphHopper server is your own, reachable at a URL you set. Most endpoints behave identically either way. Two do not: /locate and /centroid are Valhalla-only and answer 501 on a GraphHopper-only deployment, and a GraphHopper backend ignores polygon and location exclusions on /matrix and /isochrone. The per-endpoint table is in the self-host guide.
First-party, or Photon as a fallback
The first-party path serves search in-process from a territory’s geocode index, no JVM, no separate search cluster, and is the only path that works air-gapped. Photon is the fallback.
An MCP server over your own engine
Enabled with a compose profile, the MCP server talks to your local engine directly, so agents wired to your deployment never leave your infrastructure.
A working stack, from one file.
The repository is private: source access comes with a commercial relationship or an evaluation, over email at hello@mapmap.ai. What follows assumes a checkout.
What you need
- Docker Engine 24+ with Compose v2 (docker compose version)
- Around 10 GB disk and 8 GB RAM for a UK-scale first tile build (serving needs less), plus around 1.5 GB once for shared global base-map sources
- Outbound internet on first boot only. Air-gapped installs are supported via pre-built territory packages, so no OSM download is needed
Set up and boot
cd distro
cp .env.example .env
# Admin token: protects /admin/*. Compose refuses to start without it.
sed -i '' "s/^SN_ADMIN_TOKEN=$/SN_ADMIN_TOKEN=$(openssl rand -hex 32)/" .env # macOS
docker compose up -d --build
docker compose logs -f valhalla # first boot builds tiles: ~30–60 min for the UKWhile tiles build, docker compose ps shows the gateway stuck in Created; that’s expected, not broken. You’re up when this succeeds:
curl -fsS http://localhost:8080/healthOffline maps you verify, not maps you trust.
Offline navigation runs on territory packages: signed, per-territory bundles of routing tiles, base-map tiles and a geocode index. Manifests are signed with ed25519, every layer content-addressed with BLAKE3. A hostile CDN or mirror can deny service, but it cannot alter what a device accepts.

Differential over-the-air updates
Layers are content-addressed, so two package versions sharing a layer share the blob: an unchanged multi-gigabyte tile tree costs no extra disk or download. Devices fetch only what changed, verify it, and apply it with an atomic swap.
Your own signing key
Self-hosted deployments sign with their own keys, so you choose who can publish maps to your fleet. snfactory keygen writes the pair; devices pin your key, not ours.
snfactory build ──▶ signed package ──▶ snfactory publish ──▶ channel dir
│
(any static host / CDN / rsync mirror)
│
gateway /territories ◄────────────────┘
│
device pulls
│
check_for_update ─▶ apply_update ─▶ verify ─▶ atomic swapMirror the channel directory inside your network with rsync. No vendor callback is part of the trust model.
The channel layout is documented and normative; packages can be unpacked and inspected with standard tools.
You generate the pair and hold the private half. No MapMap-held key can publish to your fleet.
How licensing works, plainly.
Running the whole platform on your infrastructure sits under a written self-host agreement covering source access and deployment rights, a different legal surface from the hosted API’s terms of service or the SDK commercial licence that covers apps embedding the SDKs alone. See licensing, plainly for how the three surfaces compare.
The ladder is published in full, and it starts at Team Lite: £2,500 a year for tiles, styles, static maps and geocoding on your own infrastructure, for one internal application and 500 monthly active users, with community support and quarterly territory updates. It runs no routing engine, so a deployment that needs routes starts at Team; moving up is an upgrade credited pro rata, not a re-purchase. Every rung is at pricing.
The right to run the stack on your hardware, per deployment, including production SDK rights for your apps.
The signed territory channel: world and regional map and routing builds, restriction-audited, delivered over the air with updates included.
A response target from Team upwards, with an optional verified source-escrow arrangement for the largest deployments. Team Lite is community-supported and carries no response target, which is what keeps its price where it is.

If you stop paying
Your deployment keeps running. You stop receiving territory updates, platform updates and support. Devices keep navigating on the data they already have; nothing bricks in the field.
Map data and attribution
Map data derives from OpenStreetMap under ODbL. Whatever you licence from us, anything you render or republish must credit “© OpenStreetMap contributors”. Our package format, pipeline, signing infrastructure and SDKs are proprietary; the ODbL data inside stays ODbL.
Read the docs before the call.
The self-host guide
The full first-boot walkthrough, plus the production guides that ship inside the checkout: sizing, backup, upgrades, hardening and air-gapped deployment.
Territory packages
The trust model behind signed, offline map and routing data: how differential updates, verification and your own signing keys work.
Licensing, plainly
The three legal surfaces MapMap sells under, and exactly what a self-host agreement contains, in plain language, no jargon.
Own your map
The no-expiry guarantee, what the SDKs do and don't send home, and how to check every claim against the source rather than take our word for it.
Talk to us about running MapMap on your own infrastructure.
Tell us your territories, your fleet and your procurement constraints, and we’ll scope the deployment and the evaluation pilot together.