Roadmap¶

GeoDeploy is at v1.6.1. Everything under In v1.0 and in the releases after it is built and running in production; the groups at the end are what comes next.

Shipped · Finishing · Planned

In v1.0¶

People and access¶

Shipped

From a single admin to an organisation, with ownership, permissions, and a record of who did what.

Role ladder — viewer → editor → admin → a single transferable owner
Invitations: emailed when SMTP is configured, otherwise a copy-able link
Single sign-on (OIDC), optional, alongside password login
Per-resource visibility — private ⊂ organization ⊂ public
Four access tiers on published portals, enforced server-side
Scoped API tokens — shown once, stored hashed, for scripts and desktop tools
Secrets encrypted at rest; sessions revoked on password change
Audit log with a paginated activity view
Optional SMTP for notifications — any relay, no vendor lock-in

Open formats¶

Shipped

Nothing published here should need GeoDeploy to read it.

STAC 1.0.0 API — collections, items, ready-to-use assets
OGC API - Features — landing, conformance, collections, items
TileJSON for vector and raster layers — one URL per source
COG, PMTiles and GeoParquet read directly by QGIS, DuckDB, Python and R
CORS on public data and catalog endpoints, so browser clients work
Share links, with a panel in My Data

Finishing v1.0¶

Shipped

The last of it: verifying on real hardware what the tests can only check in parts, then the release notes and the tag.

Apache 2.0 licence, contribution guide, documentation site
Backup → restore round trip proven end to end on a live instance
Scheduled wipe-and-restore proven (demo mode runs the same restore path hourly)
Release notes
A clean install verified from scratch on fresh machines — all four combinations of managed/external PostGIS and managed/external object storage
An upgrade exercised on a live instance — v1.1 installed from the in-app updater's release channel. (Strictly this was branch → v1.1 rather than v1.0 → v1.1; it drives the same machinery — fetch tags, resolve the target, reset, rebuild, verify the new code is running.)

v1.1 — maps that show what the data says¶

Shipped · 2026-08-07

A portal could show where things are. This is the release where it can show what they are — and where choosing a version to run stops being a matter of SSH.

Data-driven symbology — colour from a field: categorized for text values, graduated for numbers (quantile, equal-interval, natural breaks), with a legend that matches because the legend is the class list
Classified points keep their marker shape — a star stays a star when it is coloured by a field
Outlines that can be none, and point outlines with a thickness — which is how a ring is drawn
3D: polygons extruded by a field, points as bars, a tilt control, and a starfield behind the globe
Portals load as one piece instead of assembling themselves in front of the visitor
Choose which version to install — main, the latest release, a specific release, or any branch; and the updater verifies the new code is actually running
Backup history can be tidied; large uploads survive a restore
Installed from the release channel on a live instance
Fixes found by using it: a bar near the antimeridian striped the whole planet; a shapefile declaring "Unknown" geometry took the point path; rasters requested tiles across the whole world; download-by-area found nothing on the globe

v1.2 — from an upload to a map anyone can open¶

Shipped · 2026-08-07

Rasters that used to fail silently, and layers another tool can actually open. Every raster fault fixed here reported itself as healthy — the layer said ready, its TileJSON was valid, and only the tile server's log knew otherwise.

Big and awkward rasters work — a 3 GB upload no longer dies writing overviews (BigTIFF), and a 4-band multispectral image renders instead of failing every tile at the PNG encoder
Hillshade works from the editor, not only from the published legend
A world layer no longer breaks every tile — geographic data is clipped to the Web Mercator band at import, so a dataset reaching Antarctica stops making the projection refuse
One oversized tile no longer hangs a portal — a 200 m drone plot was still being requested at zoom 3, and the timeout left a catalog portal loading forever
WMTS for QGIS — paste one URL and Zoom to Layer goes to the data, which an XYZ link can never do because it has nowhere to carry an extent
Tiles that miss a raster come back empty, not missing — no more 404 storms in someone else's console
Share links say which tool each one is for
Portals: Start tilted as an authoring choice, real symbology in the catalog's on-map list, a phone layout where the results are not a sliver, SVG logos that take the theme colour, and a globe thumbnail that keeps the space behind the earth

v1.4 — into the tools you already use¶

Shipped · 2026-08-17

The CLI made an instance reachable without a browser. This one puts it inside the desktop GIS people already have open.

A QGIS plugin — browse the catalog, add a layer, style it, publish back. Built on the packaged client, which is why that client has no dependencies and runs on Python 3.9. Built; not yet run in anger inside QGIS, and experimental until it has been
Styling that travels — portal and layer style interchange with GeoLibre and QGIS, for every layer type. Both directions now for vectors and rasters, including a polygon's outline width. 3D extrusion is carried safely but is not yet DRAWN by QGIS — see "Every symbol QGIS can draw" below
Download a backup, and restore from disk — state-only (small, covers a bad restore or a botched update) separately from the full copy including objects. Slipped: designed, not built
Labels — the other half of data-driven symbology v1.1 did not ship, and unlike size this one does not exist anywhere yet. Slipped; carried forward

v1.5.2 — a restore that leaves spatial queries working¶

Shipped · 2 Sep 2026

A backup you cannot restore is a guess — and so is one that restores while quietly breaking every spatial query until somebody restarts the service.

The restore no longer replaces the PostGIS extension. --clean dropped it successfully (tables go first, so nothing depends on it by then) and the rebuilt geometry type came back with new OIDs, stranding every connection open across the restore. Spatial predicates failed; COUNT(*) did not, which is what made it look like a dashboard bug
The worker recycles its connections after a restore, beside the schema and Martin repairs it already did
A 502 logs the exception it was raised for — the message naming the cause used to reach only the response body, which neither the service log nor the dashboard shows

v1.5.3 — the restore fix, finished¶

Shipped · 2 Sep 2026

v1.5.2 kept the PostGIS extensions installed and then could not restore at all on a database that has postgis_topology or postgis_tiger_geocoder — which the standard image installs. A failed restore is worse than the bug it was fixing.

A restore no longer fails on the schemas its extensions own — topology and tiger can be neither dropped nor recreated once the extension stays, and that is the intended outcome, not an error
A missing psql degrades to a warning rather than taking the restore down with it
An end-to-end restore test — dump a real spatial table, restore it through the real code path, assert the rows come back and the geometry type keeps the same OID. It is what caught the v1.5.2 regression, which the pure-function tests could not see

v1.5.4 — a restore that does not lie about the database¶

Shipped · 2 Sep 2026

An in-place restore is DDL against a live system. Everything it drops is missing for a moment that something else can act on — and one of those moments left an instance insisting it had no database.

setup_config survives a restore as one row with its primary key. The API inserts a blank default row into the window where --clean has emptied the table, the snapshot's row lands on top, and the primary key can no longer be created — leaving two rows, no key, and an instance that reports "cannot reach its database" while the database answers normally
Repaired before _restore_own_db_settings(), which updates that row and would otherwise fix one copy while the API read the other

v1.6.1 — "no basemap" actually removes the basemap¶

Shipped · 11 Sep 2026

Choosing it in the editor appeared to do nothing, and the editor was innocent: its preview is a REAL published bundle, so what the preview shows is decided at publish.

The bundle honours __none__. It is deliberately not a catalog entry — there is no service behind it — so the lookup found nothing and the template's own basemap stayed baked in. The runtime switcher could still hide it afterwards, which is why it looked as though only the published portal honoured the setting
The basemap is taken OUT at publish rather than hidden on load, on a white ground, so a portal opens as it was authored with no flash of a map nobody asked for

Next up¶

Into the tools you already use¶

Planned

Your data can already leave GeoDeploy in open formats. This is the return trip — edit in the tool you prefer, publish back.

The QGIS plugin and style interchange shipped in v1.4 and were finished in v1.6 above — including external services in both directions. What is left here is the rest of the round trip, not yet scheduled.

A .geolibre.json importer — POST /api/interop/geolibre/preview (a dry run that says what would be imported) and /publish (creates a layer per source and builds the portal). Shipped in v1.0, and API-only: it reads a whole project — XYZ and COG layers, extruded buildings, a 3D-Z track, categorized, graduated and single-symbol vectors, the story sections and the 3D view — carrying raw MapLibre paint for what the friendly style cannot say, and a source_identity on every layer for a future write-back
Somewhere to drop the file — the importer has no button. Today it is a curl to /api/interop/geolibre/preview, which means nobody who has not read the API reference knows it exists
Push from GeoLibre — the other end: a "Publish to GeoDeploy" plugin inside GeoLibre, so a project goes across without exporting a file first
Write-back: expose a layer as editable GeoJSON and re-ingest the edit
Catalog search — STAC GET/POST /api/stac/search by bbox, collection, datetime and id (what QGIS's STAC browser and pystac-client send), and the catalog experience's own search box over names, keywords and abstracts. Shipped in v1.0 and v1.4
Free-text search across the whole instance — one box that finds a layer, a portal or a dataset by anything written about it, rather than a filter per surface

Finishing what v1.5 started¶

Planned · next

Two items scoped into the dashboard release that it shipped without. Named here rather than ticked there, because a dashboard nobody has measured on ten million features is not the same as one that has been.

Linked or detached, chosen per dashboard. A linked dashboard reads its layers live, so the numbers move when the data does — that is what is built today. A detached dashboard is built on saved queries and keeps reporting what it reported, which is what a published figure sometimes has to do. The distinction has to be stated in the editor in those terms, because "layer or saved query" is a storage detail and "does this update itself?" is the actual question being asked
Benchmarks on real data — the spatial filter path is the one that decides whether a dashboard over ten million features is pleasant or merely possible

What still cannot travel from QGIS¶

Planned

v1.6 closed most of this. What is left is the part where a web renderer genuinely cannot follow, plus one thing QGIS itself cannot draw.

Symbols a web map cannot draw at all — a shapeburst fill, an SVG marker from the user's disk that fails to rasterise, a geometry generator. Today the closest picture is sent, which is right for the portal and lossy for QGIS ⇄ QGIS. The answer is to carry the layer's QML alongside the friendly style, so a round trip through GeoDeploy returns exactly what went in while the portal keeps drawing its approximation. GeoDeploy already does this for GeoLibre imports, where raw MapLibre paint rides along in style.maplibre
Inverted polygons — a mask, the world minus the layer, which is how you dim everything outside a study area
3D drawn in QGIS from a portal group. GeoDeploy renders extrusion and the plugin carries it safely, and a layer opened from its DATA gets a real 3D renderer. A layer opened as the fast preview cannot: QGIS has no 3D renderer for vector TILES in either 3.44 or 4.2, so the group says so and points at the editable source rather than drawing it flat in silence

The constraint that shapes all of it: GeoDeploy renders with MapLibre and TiTiler, not with QGIS. A symbol travels exactly when the web renderer can express it, and the useful question for each one is not "can we support it" but "does it survive a round trip unchanged, and if not, does the author find out before they publish?"

Install somewhere that is not empty¶

Planned

Every install path so far assumes a bare VPS that GeoDeploy owns — ports 80 and 443 free, fixed container names available, nothing else on the box wanting any of it. That is the right default and stays the default. It also rules out a lab server, a shared research machine, or a VM that already serves something on 443.

Serve behind an existing reverse proxy — publish to a configurable port, or to no host port at all, with the proxy_pass an operator already running nginx or Caddy needs. The single biggest unlock, and the first step
A base path. A portal lives at /portals/<slug>/ today; on a shared host it may need to live under /geodeploy/…. Every absolute URL the app emits — vector tiles, pmtiles://, the parquet range proxy, published portal assets — has to be built from a configured prefix rather than assumed to sit at the root. This is the part that will leak bugs and it deserves its own audit
A namespace for containers, networks and volumes, so two instances can coexist and neither collides with unrelated software
A rootless path, or at minimum a preflight that states the privileges required and fails early and legibly without them
A preflight that reports every conflict at once — ports in use, names taken, network present — before it writes anything

Half-doing the base path produces an instance that mostly works and breaks on the paths nobody clicked while testing, which is the worst failure available to a self-hosted product: the operator cannot tell whether they misconfigured it or it is broken. Hence a release rather than a flag. #79

A page for a layer¶

Mostly shipped · v1.4

A layer is a thing in its own right, not only a row in a list — so it has an address, and a page at it. /layers/<kind>/<id> is public for a shared layer and the same page appears inside the app; a private one asks for a sign-in.

Click a layer, get its page. A map of just that layer, at its own extent, drawn by the same style builder the portal editor uses — so the page shows what a portal would
What it is: geometry type, feature count, CRS, extent, size on disk, when it was added
How it is served: whether it is tiled and how (PostGIS tiles, a PMTiles archive, a COG), and whether a GeoParquet layer has been tiled yet
Its symbology, edited and saved here — the same panel My Data uses, writing the layer's default style
Everything that already exists about a layer, in one place: its share links, its legend, its sharing state, and the actions that apply to it
The attribute table, paged, with a click-through from a feature on the map. The one part of this page still missing — the data is reachable today only through the API or by downloading the layer

Depth¶

Exploring

Capabilities that change what a portal can be.

Temporal layers with a time slider
3D terrain — raise the map by a DEM, per raster layer, in the globe view (v1.6)
3D tiles in the globe view — somebody else's 3D tileset, drawn beside your data
Live connectors — scheduled re-sync, so published maps stay current
Photo features — bulk-import geotagged images into a field-story layer
In-browser analysis console — SQL against hosted GeoParquet
A small geoprocessing toolkit, run server-light
Translation of the dashboard and the published portals

Suggesting something¶

Open an issue on GitHub. A concrete description of what you were trying to do is the most useful kind — a good share of the list above came from exactly that.

Roadmap¶

In v1.0¶

Install and operate¶

Data¶

Portals¶

People and access¶

Open formats¶

Finishing v1.0¶

v1.1 — maps that show what the data says¶

v1.2 — from an upload to a map anyone can open¶

v1.3 — the CLI, and getting data back out¶

v1.4 — into the tools you already use¶

v1.5 — dashboards¶

v1.5.1 — a dashboard you can actually author¶

v1.5.2 — a restore that leaves spatial queries working¶

v1.5.3 — the restore fix, finished¶

v1.5.4 — a restore that does not lie about the database¶

v1.6 — every symbol QGIS can draw¶

v1.6.1 — "no basemap" actually removes the basemap¶

Next up¶

Into the tools you already use¶

Finishing what v1.5 started¶

What still cannot travel from QGIS¶

Install somewhere that is not empty¶

A page for a layer¶

Cartography and portal tools¶

Depth¶

Suggesting something¶