Skip to content
tobilgPublic

About

Multi-workspace geospatial server in Go: OGC API - Features and Tiles, WMS 1.3, WFS 2.0, WCS 2.0.1/2.1 and WMTS 1.0 for PostGIS, DuckDB, GeoParquet, vector files and GeoTIFF/COG

Topics

Resources

Contributing

Security policy

Stars

31 stars

Watchers

0 watching

Forks

Latest commit

 

History

13 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

neoserver

Current version: 0.3.0.

neoserver is a modern, multi-workspace geospatial server written in Go. It publishes PostGIS, DuckDB, GeoParquet, vector-file, and raster data through OGC API - Features, WMS 1.3.0, WFS 2.0, WCS 2.1/2.0.1, OGC API - Tiles, a management REST API, and an embedded administration console.

It is designed as a lightweight, API-driven alternative to GeoServer, with isolated workspaces, configurable service metadata, role-based access control, and an encrypted DuckDB backing store.

Features

  • Workspace-isolated data sources, layers, styles, credentials, and OGC settings
  • PostGIS, DuckDB Spatial, GeoParquet, Shapefile, GeoPackage, GeoJSON, and FlatGeobuf
  • OGC API - Features with CRS, bbox, temporal queries, Queryables, CQL2 text/basic spatial filters, property selection, sorting, and linked paging
  • WMS 1.3.0 with GetMap, GetFeatureInfo, GetLegendGraphic, SLD, time/elevation dimensions, raster/document formats, MapML, and UTFGrid
  • WFS 2.0 with GML/GeoJSON/CSV/GeoPackage/SHAPE-ZIP output, FES filters, stored queries, transactions, and feature locking
  • WCS 2.1 with WCS 2.0.1 compatibility, GeoTIFF/COG and PostGIS raster sources, GML/GeoTIFF output, and 2D subsetting
  • OGC API - Tiles and WMTS 1.0 with Mapbox Vector Tiles, raster map tiles, TileJSON, standard tile matrix sets, and a shared persistent cache
  • Optional workspace STAC catalogs for dataset discovery, mapped asset records, raster Items, and imported metadata
  • Management API and generated Swagger UI
  • Embedded React administration console for catalog, security, imports, caches, styles, settings, and map preview
  • API keys, self-signed JWTs, static/basic authentication, OIDC, workspace RBAC, and per-layer read controls
  • Configurable response caching, resource limits, OpenTelemetry export, and protected pprof endpoints
  • Filesystem or S3-compatible persistent tile caching with quotas and resumable seed/reseed/truncate jobs

Architecture

Management API
    |
    +-- Workspace
        +-- Services (datasource connections)
        |   +-- Published layers and SQL views
        +-- STAC Collections, Items, and source bindings
        +-- Styles
        +-- API keys and claim mappings
        +-- OGC service settings

Published endpoints:
  /workspaces/{workspace}/ogc
  /workspaces/{workspace}/wms
  /workspaces/{workspace}/wfs
  /workspaces/{workspace}/ogc-tiles
  /workspaces/{workspace}/wcs
  /workspaces/{workspace}/wmts
  /workspaces/{workspace}/stac (when enabled)
  /admin

The server stores its configuration and security state in an encrypted DuckDB file. Feature data remains in the configured source systems.

Deployment model and limits

  • One active server per store. The catalog, tile-cache index and mosaic index are DuckDB files held with exclusive locks, so a second process against the same store refuses to start. There is no clustering or active-active high availability; scale by running separate instances with separate stores, and recover by restarting or replacing the single node. Admin CLI commands such as create-token also need the server stopped.
  • Backups are taken offline. Stop the server (or otherwise quiesce all writers) and copy the catalog, audit database and other enabled state together. There is no online backup command.
  • The store key cannot be rotated. A leaked NEOSRV_STORE_KEY means re-initializing the catalog.

See Deployment for details on locking, backups, and store-key recovery.

Install

Released images are published to Docker Hub for Linux amd64:

docker pull tobilg/neoserver:0.3.0     # use :latest for the latest stable release

Each GitHub release also carries the image archive, a CycloneDX SBOM, SHA256SUMS and a qualification.json recording the gates that build passed.

Quickstart with Docker Compose

The minimal-image baseline measured 634 MB uncompressed (230 MB as a compressed Docker archive), about 75% smaller than 0.1.0. The runtime bundles DuckDB extensions for offline startup and omits PROJ datum grids. For precise grid-dependent raster reprojection, add the required grids using the deployment instructions.

Choose your path:

  • UI-first tutorial: Docker + browser, from an empty catalog to a private layer and a working client. No management API commands.
  • API-first tutorial: the same workflow using scripted HTTP requests.
  • Contributor setup: make doctor checks dependencies; make dev starts the backend and hot-reloading console with an isolated local catalog.

Requirements: Docker Compose, curl, jq, and OpenSSL.

For this local tutorial, use the repository's development key. Generate and retain a strong key (openssl rand -hex 32) for any deployment:

export NEOSRV_STORE_KEY=abc123 # Local only; never use in production.
export NEOSRV_SERVER_URLBASE="http://localhost:9000"

Initialize the backing store. The command prints a one-time bootstrap JWT; save it as TOKEN.

docker compose build server
docker compose run --rm --no-deps server init --store-path /data/neoserver.db
export TOKEN="paste-bootstrap-token-here"

Start neoserver and the seeded PostGIS database:

docker compose --profile postgis up --build

Verify the server:

curl http://localhost:9000/health
curl http://localhost:9000/ready
curl -H "Authorization: Bearer $TOKEN" \
  http://localhost:9000/api/v1/workspaces

The store and PostGIS volumes are persistent. On later starts, reuse the same NEOSRV_STORE_KEY and run only the compose up command. Continue with the complete getting started tutorial to create a workspace, publish the included sample data, and access every service.

Deployment

For a native development build, install GDAL 3 development headers first:

make build
export NEOSRV_STORE_KEY="$(openssl rand -hex 32)"
./neoserver init --store-path ./data/neoserver.db
./neoserver serve

For containers and production deployments, persist the backing-store path, supply the original encryption key through a secret manager, configure Server.UrlBase for the externally visible URL, and terminate authenticated traffic with HTTPS. See Deployment for initialization, persistence, proxy, backup, and upgrade guidance.

Documentation

Start and operate

Publish and manage data

  • Data sources — connection formats, discovery, files, remote data, and SQL views
  • WCS 2.1 — raster publication, subsetting, formats, and compatibility
  • SpatioTemporal Asset Catalog — publish existing datasets or import metadata, then search assets within a workspace
  • Management API — task-oriented administration and API reference links

Consume OGC services

Contribute

API reference and UI

After startup:

Replace demo with a workspace name or UUID for workspace endpoints. If Server.BasePath is configured, prepend it to every path.

License

neoserver is distributed under the MIT License. It bundles third-party software under its own terms; see third-party licenses and notices.

About

Multi-workspace geospatial server in Go: OGC API - Features and Tiles, WMS 1.3, WFS 2.0, WCS 2.0.1/2.1 and WMTS 1.0 for PostGIS, DuckDB, GeoParquet, vector files and GeoTIFF/COG

Topics

Resources

Contributing

Security policy

Stars

31 stars

Watchers

0 watching

Forks

Releases

Contributors

Languages