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.
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.
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.
Valhalla, GraphHopper, or auto
SN_ROUTING_ENGINE selects the routing engine. Every endpoint behaves identically either way; a GraphHopper server is your own, reachable at a URL you set.
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 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.
Included with every self-host agreement, with an optional verified source-escrow arrangement for the largest deployments.
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.