Goal: treat maps/routing/search like a local appliance. Once the dataset is on the device, there are no external map/routing/geocoding API calls. After the initial Docker pulls, you can unplug WAN and still browse tiles, route A→B, and search/reverse-geocode locally. It’s packaged behind a single local gateway/port so any app on the LAN can hit the same endpoints.
Also important for consistency: tiles, routing tiles, and the geocoder index are all built from the same underlying extract for a given region (so you don’t end up mixing sources/versions across components).
How this differs from common alternatives:
- Mapbox / HERE SDKs: they do support offline use cases, but the typical path is SDK-first (embed their SDK in every app, manage offline packs per app/device, adopt their licensing + integration surface). This project is server-style offline in Docker: drop it onto an edge box and multiple clients can share the same local tiles + routing + geocoding service without wiring a proprietary SDK into each client.
- Mapbox Atlas: Atlas is the closest “serious” comparison (an on-prem/offline Mapbox platform). The difference I’m aiming for is edge ops: Corviont is intentionally focused on specific regions and a smaller “appliance-like” bundle (PMTiles + Valhalla + SQLite geocoder) designed to be friendlier to edge hardware and simple deployments, rather than a full on-prem mapping platform.
- Google Maps Platform: for developers, offline usage is effectively contractually off-limits (tight restrictions on caching/storage and “offline use” of map content). So “just run Google Maps offline on my fleet” isn’t a realistic path.
- Tiles-only servers: offline tiles are only one piece — many deployments still need routing + geocoding locally. This bundles all three behind one gateway/port.
- Routing-only engines (OSRM/GraphHopper/Valhalla alone): routing doesn’t cover the “search / reverse-geocode” side. This is meant for navigation-like UX, not just a route endpoint.
- Running Nominatim: it’s powerful, but it’s heavy to operate (Postgres, import/tuning, ongoing ops). This demo uses a SQLite-based offline index derived from Nominatim-style data so it’s easier to ship as an artifact to edge targets.
What’s next (and what I’m trying to validate): a signed on-device updater that’s actually fleet-friendly:
- verifiable updates (signed manifests), fail-closed, atomic swap + rollback
- incremental publishing on the build side (so a “new dataset” doesn’t always mean re-shipping everything)
- incremental/resumable downloads on devices with bandwidth caps + maintenance windows
- staged rollout patterns (canary → wider) for fleets
If you’re willing to share your map coverage + deployment style (Compose/Portainer/Mender/K8s), I have a short form here: https://corviont.com/#join-waitlist