Planisfy

Planisfy Documentation

Build, publish, secure, and operate MapLibre maps and open geospatial services with Planisfy.

Planisfy Documentation

Planisfy is the platform layer around MapLibre and open geospatial engines. MapLibre renders the map in the client, while Planisfy manages the styles, tilesets, service APIs, credentials, jobs, usage, storage, and operational state behind it.

You can use the hosted platform or run the same core application model on infrastructure you operate.

Choose your path

GoalStart here
Render a Planisfy style in MapLibreQuickstart
Upload data and publish your own mapUpload a tileset, then publish a style
Integrate geocoding, routing, elevation, or static mapsAPI conventions and authentication
Understand the platform architecturePlatform overview
See what is implemented and validatedCapabilities and validation status
Run Planisfy on your own infrastructureSelf-hosting overview

The main workflow

Most map projects move through the same resource lifecycle:

source data
  -> tileset processing or import
  -> published TileJSON and vector tiles
  -> MapLibre style
  -> published style URL
  -> browser, native client, or static renderer

Planisfy keeps editable resources separate from the URLs consumed by applications. You can continue changing a draft while existing clients use a published version, then move the stable URL to a new version when it is ready.

Start with resources and publications for the resource model, or follow the quickstart to render a map first.

What you manage in Planisfy

Map resources

  • MapLibre style JSON, versions, stable aliases, sprites, and glyph references.
  • Uploaded or imported tilesets, processing jobs, PMTiles artifacts, TileJSON, and tile delivery.
  • Public map assets that browsers and native clients can load directly.

Geographic service APIs

  • Pelias-compatible forward, reverse, and autocomplete geocoding.
  • Valhalla-backed directions, matrices, isochrones, matching, and optimization.
  • Elevation lookups and route elevation profiles.
  • Static PNG maps rendered from published styles.

These services depend on the configured engines and datasets. A route can exist even when its backing dataset is unavailable, so applications should handle the documented degraded and unavailable responses.

Platform operations

  • API keys, scopes, browser-origin restrictions, rate limits, usage, and audit records.
  • Upload, import, build, release, and activation workflows.
  • Health, preflight, metrics, worker state, backups, restores, and support bundles.
  • External build and serving agents for regional and planet-scale map-data workflows.

Public assets and authenticated APIs

Published styles, TileJSON, tiles, glyphs, and sprites can be made available as browser-loadable map assets. Service APIs such as geocoding, routing, elevation, and static maps require an API key or an authenticated Console session.

For credentials and failure behavior, read:

Managed and self-hosted deployments

Managed Planisfy operates the hosted provider configuration and runtime policy. Self-hosted Planisfy uses the same core API shapes and resource model, but you operate Postgres, Redis, object storage, geospatial engines, datasets, backups, upgrades, and observability.

Read deployment modes for the boundary between the two, or continue directly to Docker Compose self-hosting.

Platform status

Not every capability has the same operating requirements. Some work immediately, some depend on installed datasets or provider credentials, and some remain planned. The capabilities and validation status page records those distinctions, including the validated planet-scale OSM basemap and Valhalla routing graph workflows.

On this page