Honua Platform | Runtime, Admin APIs, SDKs, and Deployment

Core Idea

Replace the runtime. Then replace the rest of the stack.

Move GIS services onto Honua without breaking existing clients. Then bring in mobile, analytics, data services, and agent access on the same platform instead of stitching together five different products.

Compatibility

Keep existing clients. Fix the operating model.

GeoServices REST and OGC compatibility mean ArcGIS Pro, QGIS, and existing web maps keep working on day one. Migration tooling and codemods handle the app layer.

Import live Esri REST services with metadata preserved.
JavaScript SDK includes scanners, codemods, and compat wrappers.
Legacy clients stay on GeoServices REST while new apps move to gRPC and MCP.

Modern Interfaces

gRPC for apps and mobile. MCP for agents.

New applications get typed binary transport through gRPC. AI agents get service discovery and filtered queries through MCP. Both run on the same runtime as the legacy compatibility layer.

gRPC

An open geospatial gRPC standard, built here first.

GIS has been stuck on REST/JSON and XML for two decades. Honua is building a typed binary protocol for geospatial and releasing it as an open specification targeting OGC working-group submission.

Performance

Smaller payloads. Faster parsing. Lower cost.

Protobuf encoding cuts geospatial payload sizes by roughly 60–70% compared to GeoJSON. Binary parsing is up to 5× faster than JSON deserialization. For mobile clients on metered connections and backend services running at scale, the difference shows up in bandwidth bills, battery life, and p99 latency.

~60–70% bandwidth reduction over equivalent GeoJSON responses.
Up to 5× faster client-side parsing with generated Protobuf code.
Strongly typed contracts eliminate an entire class of serialization bugs.
HTTP/2 multiplexing and server streaming for large result sets.

Open Standard

Open source now. OGC submission next.

The gRPC geospatial protocol is not a proprietary wire format. The .proto definitions, service contracts, and specification documents are open source. The goal is formal submission to the OGC as a working-group standard so the industry has a vendor-neutral binary transport for geospatial data — the same way Protobuf became the backbone of cloud infrastructure.

Proto definitions and spec published under an open license.
Targeting OGC working-group submission as a community standard.
No vendor lock-in: any server or client can implement the spec.

MCP

Give AI agents structured access to geospatial data.

Model Context Protocol (MCP) is an open standard that lets AI assistants, coding agents, and copilots discover and query external services through a structured interface instead of scraping APIs or relying on prompt-stuffed context.

What MCP Does

Discovery, schema, and queries — not just a raw API.

An MCP server exposes tools that an AI agent can call: list available services, inspect a layer's schema and fields, run a filtered spatial query, and get results back in a structured format. The agent decides what to call based on the user's question — no hardcoded integrations required.

Agents discover published map and feature services automatically.
Schema inspection lets agents understand field types before querying.
Spatial and attribute filters run server-side, not in the prompt window.
Works with Claude, GPT, Copilot, and any MCP-compatible client.

Why It Matters

No legacy GIS platform has native agent access. Honua does.

Today, connecting an AI agent to ArcGIS or GeoServer means writing custom glue code, managing authentication wrappers, and hoping the output format doesn't change. Honua ships an MCP server package that plugs directly into agent frameworks — turning every published service into a tool an AI can use.

Ships as an npm package: @honua/mcp-server.
Analyst assistants can answer "show me all parcels within 500m of this school" without custom code.
Coding agents can generate SDK calls against real service schemas.

Cloud-Native Deployment

GIS that deploys like the rest of your infrastructure.

Legacy GIS servers require bespoke Windows installs, proprietary clustering, and dedicated ops teams. Honua ships as a single Linux container image that deploys with the same tools your platform team already uses — Docker, Kubernetes, Terraform, Helm. Stateless runtime. Standard ingress. PostGIS for storage. No special infrastructure.

Local Dev

Docker Compose

One docker compose up starts Honua, PostGIS, and optional Redis. Full protocol surface available on localhost for development and evaluation.

Kubernetes

Helm charts

Production-ready Helm charts with configurable replicas, resource limits, ingress, TLS, and horizontal pod autoscaling. Works on any conformant cluster.

AWS

ECS, Fargate, Lambda

Terraform modules for ECS/Fargate with ALB ingress, RDS PostgreSQL, and ElastiCache. Lambda option for low-traffic or event-driven workloads.

Azure

AKS, Container Apps, Functions

Terraform modules for AKS, Azure Container Apps, and Azure Functions with Azure Database for PostgreSQL and Azure Cache for Redis.

Observability

OpenTelemetry built in

Traces, metrics, structured logging, health endpoints, adaptive sampling, and Prometheus-compatible instrumentation ship in every deployment target.

Monitoring

Prometheus + Grafana

Prometheus-compatible metrics endpoint, pre-built Grafana dashboards for request throughput, query latency, and cache hit rates. Plug into the monitoring stack you already run.

Diagram showing GIS clients and analytics tools reaching Honua through ingress, with PostGIS, Redis, object storage, and monitoring behind the runtime.

One cloud-native runtime behind standard ingress, backed by PostGIS, optional Redis, object storage, and observability.

What Ships

What you get in the platform today.

Runtime

Multi-protocol server

FeatureServer, MapServer, ImageServer, Geometry Service, OGC API Features/Tiles/Maps, OData v4, vector tiles, WMS, WMTS, gRPC, and MCP from one PostGIS-backed process.

Admin

Admin APIs and Blazor UI

Publish services, manage connections and layers, configure styles, import data, and govern the runtime through REST admin APIs and a Blazor WebAssembly control center.

SDKs

JavaScript, .NET, Python

Typed clients, gRPC support, admin automation, geocoding, migration tooling, and an MCP server package. All Apache 2.0.

Mobile

MAUI field toolkit

Offline GeoPackage sync, dynamic forms, background upload, gRPC transport, and a direction toward AR-assisted and sensor-aware field collection.

Roadmap

What the platform is building toward.

Area	What is coming	Why it matters
Data services	Geocoding, routing, spatial analytics, H3 aggregation, and real-time streaming	Honua becomes an application platform, not just a serving runtime.
Cloud-native formats	GeoParquet, FlatGeobuf, PMTiles, and Cloud Optimized GeoTIFF	Modern data movement patterns alongside database tables and shapefiles.
Enterprise security	SSO/OIDC, RBAC, audit logging, change management, multi-tenancy	Large organizations can run Honua with the governance they require.
GeoServer migration	WFS 2.0 compatibility, SLD style import/export, admin config migration	Direct migration path from the most common open-source GIS server.
Apps and portals	Web map portal, dashboards, open data hub	The platform can own more of the user-facing stack, not just the APIs.
Managed cloud	Honua Cloud for teams that want the platform without the infrastructure	Self-hosted and managed share the same core, same SDKs, same contracts.

One platform instead of five products

Server runtime, SDKs, mobile toolkit, admin APIs, and deployment targets come from one product with one licensing model instead of separate vendor relationships for each.

Shared contracts all the way down

The runtime, SDKs, admin APIs, mobile toolkit, and deployment options all share the same protocol contracts and the same PostGIS data layer. Everything connects because everything was built together.

A full-stack geospatial platform, not just a feature server.