Honua
// platform architecture · evidence-aware reference shapes

How Honua works.

Honua Server's public trunk exposes documented GeoServices REST, OGC, OData, tile, gRPC, and MCP surfaces over shared policy, catalog, query, rendering, and job paths. Coverage varies by protocol and operation, and no immutable public server release artifact is currently published.

Source evaluation Source preview Private beta / Preview Planned
// platform · source evaluation

One request pipeline. Several documented interfaces.

A shared runtime handles authentication, policy, catalog lookup, query planning, encoding, and telemetry. Protocol adapters translate supported operations into that core; they do not make every protocol operation interchangeable.

952 / 952 passing assertions · 11 scoped CITE suites Honua-run snapshot · 2026-05-17 · not formal OGC certification
Illustrative request path Follow a supported feature query through the runtime.
  1. 01 Client interface ArcGIS, QGIS, web, SDK, or agent using a covered operation
  2. 02 Protocol adapter GeoServices, OGC, OData, tile, gRPC, or MCP request parsing
  3. 03 Identity & policy Authentication plus operation- and resource-scoped authorization
  4. 04 Shared execution Catalog lookup, query planning, jobs, rendering, and response encoding
  5. 05 Data & telemetry PostGIS or a covered provider, with health and OpenTelemetry signals

Illustrative sequence only. Latency and response behavior depend on the operation, data, and deployment.

01 · Clients

Keep familiar interfaces where coverage matches.

Existing clients can retain familiar service shapes when their required operations, parameters, versions, authentication, and extensions are covered.

ArcGIS clientsQGISWeb appsSDKsMCP agents
02 · Server runtime

Thin adapters over shared server services.

Documented surfaces converge on common policy, catalog, data, analytics, publishing, and job components. Capability flags make the available surface inspectable.

GeoServices RESTOGCOData / STACTilesgRPC / MCP
03 · State and providers

PostGIS first; additional paths stay explicit.

PostgreSQL/PostGIS is the read/write operational store. Covered relational connectors, file imports, and object-storage formats have provider- and operation-specific boundaries.

PostGISObject storageRedis · multi-nodeOTel backend
Edition lens

See where capabilities enter the catalog.

Showing documented capabilities across all editions. Maturity labels still apply.

Source evaluation

Core serving surfaces

Documented GeoServices REST, OGC, OData, STAC, tile, gRPC, and MCP operations with scoped coverage.

Community
Source evaluation

Runtime foundations

PostGIS-backed catalog and data paths, API keys, health probes, Prometheus, and OpenTelemetry.

Community
Source evaluation

Editing and analytics

FeatureServer editing, spatial analytics, geocoding, cloud raster paths, and multi-node caching.

Pro
Preview

Streams and alerts

Real-time streams and alert evaluation are pre-GA, disabled by default, and require explicit opt-in.

Pro
Source evaluation

Enterprise controls

Multi-provider OIDC, claim-to-role mapping, branch versioning, service imports, and extension hooks.

Enterprise
Mixed maturity

Verify the exact capability

The catalog separates implemented, Preview, private-beta, and planned behavior instead of flattening it.

All editions
// esri migration · partial coverage

Keep supported workflows familiar. Verify the rest.

FeatureServer, MapServer, ImageServer, GeocodeServer, NAServer, GPServer, and Geometry Service have documented operation-level coverage and gaps. Validate every required workflow before moving an endpoint.

Source evaluation GeoServices surface Source preview assessment paths Partial operation-level parity
Existing estate ArcGIS Server / Online Services, clients, data, auth, renderers, and operational dependencies
Honua pilot Supported services on Honua Selected layers in PostGIS, familiar covered interfaces, and explicit gaps
Run both systems while clients and response behavior are tested.
Measured migration path

Move only what the evidence supports.

01 · read-only first

Inventory the estate inside your network.

Run the open, read-only assessment tooling against the service inventory. Record services, layers, client versions, authentication, extensions, data sources, and workflows without modifying the source.

honua-esri-assess → local inventory and capability map
02 · compatibility review

Map requirements to operation-level evidence.

Compare every required operation and parameter with the public parity matrix. Unsupported renderers, symbols, attachments, extensions, and authentication flows stay visible for manual review.

Open the compatibility evidence →
03 · bounded import

Import a representative supported service.

Copy selected layers from supported queryable FeatureServer or MapServer roots into PostGIS and publish the pilot. Unsupported content is reported rather than silently treated as compatible.

Review migration evidence →
04 · side-by-side testing

Test client and response behavior.

Exercise the actual clients, operations, and data that must continue to work. Keep the existing service available while gaps are fixed or accepted. Estate-wide behavioral parity reporting remains planned.

Evidence per workflow
05 · controlled cutover

Move only validated endpoints.

Repoint a service after its required workflows pass. Preserve the source service as a rollback path, observe the moved workload, and repeat service by service instead of scheduling a big-bang replacement.

Read the full migration playbook →
Public prerelease

JavaScript

Supported import and call-site transformations are available through the published prerelease tooling.

Source preview

Python

A source-preview scan, translate, and run path emits evidence for recognized operations and manual review.

Guided path

.NET and MAUI

Guided reimplementation and adapters are documented; no automated .NET or MAUI source rewriter exists today.

Migration boundary Compatibility is workflow-specific.

A matching protocol name is not proof that every client behavior or extension will transfer.

Plan a measured migration →
// mcp and operations · mixed maturity

Agents use the same boundaries. They do not bypass them.

Server MCP discovery and query are source-evaluation paths. The separate geospatial-mcp specification remains a source preview with partial coverage. The single-environment operator loop is private beta.

Source evaluation health, telemetry, server MCP Private beta operator loop Planned fleet verification
Build and inspect

GIS-facing agents

Discover covered services, read metadata, query features, and invoke supported analysis through server APIs. Policy checks apply to the agent identity just as they do to any other client.

AgentMCP / gRPCAuth + policyServer APIs
Explore AI and GIS boundaries →
Operate and propose

Operations-facing agents

Read health and telemetry, inspect deterministic findings, and prepare policy-scoped proposals. Risky and irreversible work remains approval-gated.

SignalsFindingProposalApproval
Review the operator model →
Operations loop

Available signals, bounded automation, visible gaps.

Source evaluation

Observe health and telemetry.

Health/readiness endpoints, Prometheus metrics, and OpenTelemetry signals expose the deployment state.

Source evaluation

Inspect the evidence behind a condition.

Operators and agents can read the available signals and supporting evidence before proposing a change.

Private beta

Prepare a bounded plan.

The single-environment loop can produce structured proposals under configured release and policy controls.

Private beta

Route approval or a configured low-risk action.

Deterministic low-risk actions require explicit policy. Risky and irreversible work remains approval-gated; the system does not claim unattended fleet self-healing.

Planned

Verify every outcome and promote across environments.

Post-action verification, signed fleet promotion, and broader autonomous remediation remain planned.

Identity Every call has a principal.

Agents use scoped credentials and the same authorization boundaries as interactive or service clients.

Evidence Proposals point back to signals.

Operators can inspect the condition, proposed action, and configured policy before execution.

Control Approval remains a product boundary.

Automation does not turn unknown, risky, or irreversible work into an implicit background action.

// azure · reference evaluation shape

AKS with managed state. Preview, not certification.

Use the public Helm chart to evaluate a stateless Honua server tier on AKS with managed PostgreSQL/PostGIS, shared object storage, Redis for multi-node mode, and your observability backend.

Preview AKS HA evaluation Evaluation access private Terraform Planned Azure Marketplace
Traffic and identity
Operator-selected ingress + TLS Route traffic into the cluster; validate identity and network controls for your environment.
Workload identity + secret references Use the cloud controls your platform team operates; confirm the exact integration path.
AKS · evaluation
Honua Server pods Public Helm chart · stateless serving tier · health and telemetry endpoints
Optional worker paths Validate long-running jobs, storage, retry behavior, and optional GDAL conversion separately.
Managed state
Azure PostgreSQL + PostGIS Operational catalog and feature store; choose and test the managed tier for your workload.
Blob storage + Redis Shared artifacts and the additional state required for multi-node behavior.
Your OTel backend Collect the available traces and metrics using the platform your team already operates.
Public source

Helm chart

Available for Kubernetes evaluation. Immutable live upgrade and rollback evidence is not yet published.

Evaluation access

Terraform

Modules are private and must be pinned to an exact commit. No stable public SemVer bundle exists.

Evaluation path

Functions and Batch

Validate cold starts, migrations, storage, job durability, failure handling, and rollback behavior.

Planned

Marketplace

There is no Azure Marketplace listing or one-click production deployment available today.

Deployment evidence This is an evaluation and pre-production HA shape.

Replica counts, service tiers, regions, availability targets, and recovery objectives remain workload decisions.

Review deployment evidence →
// aws · reference evaluation shapes

EKS or ECS/Fargate. Evidence varies by path.

Use the public Helm chart to evaluate Honua on EKS, or inspect the ECS/Fargate path available in source. Keep the server tier stateless and place operational state in PostgreSQL/PostGIS, shared object storage, and Redis where multi-node behavior requires it.

Preview EKS HA evaluation Source path ECS/Fargate Planned AWS Marketplace
Traffic and identity
Operator-selected load balancing + TLS Choose the ingress and network boundary appropriate to EKS or ECS/Fargate.
Workload identity + secret references Validate IAM boundaries and secret delivery against the exact source path you adopt.
Compute · evidence varies
EKS with the public Helm chart Kubernetes evaluation path with a stateless serving tier and external state.
ECS/Fargate path in source Inspect and validate task layout, rollout behavior, health gates, and scaling for your workload.
Managed state
RDS PostgreSQL + PostGIS Operational catalog and feature store; tier, backups, and failover remain operator decisions.
S3-compatible storage + Redis Shared artifacts and the additional state required for multi-node behavior.
Your OTel backend Collect the available traces and metrics in your existing observability platform.
Preview

EKS

Evaluate through the public Helm chart. This is not a certified, sized production architecture.

Available in source

ECS/Fargate

Evidence differs from the Kubernetes path; validate deployment, health, scaling, and rollback behavior.

Evaluation path

Lambda and Batch

Validate cold starts, storage, migrations, queue semantics, job durability, and failure recovery.

Planned

Marketplace

There is no AWS Marketplace listing or one-click production deployment available today.

Deployment evidence Validate the topology, not just the cloud logo.

Infrastructure modules are private, with no stable public bundle; Lambda and Batch remain evaluation paths.

Review deployment evidence →
// next

Start with one workflow.
Follow the evidence outward.

Use the architecture to orient the evaluation, then verify compatibility, availability, and deployment boundaries before choosing a production path.