honuaHonua combines a geospatial server, SDKs, Console, and AI tools. Bring in data, build applications, run analysis, and spend less time operating the services behind them.
Meet the platform components ↗ · Server, Console & Studio, developer SDKs, and agent tools. Mobile SDK and Collect are experimental.
Four ways the platform fits together, from the first dataset to everyday operations.
Connect a database, upload a file, or import an existing service. Publish through Honua Server, then use the same data from GIS clients, web applications, and SDKs.
Work with the shared AI conversation and Studio’s realtime editor in Console. Discover layers, refine the map, and save the composition. Use SDKs to build it into an application.
Console and Studio are Preview. Direct editing of source feature data stays outside the AI interface.
Inside AI mapmaking ↗Submit a supported process through an API or SDK. Honua tracks the job while a worker or batch backend runs it. Retrieve the result without sizing the serving tier for the entire analysis.
AI helps gather operational context, investigate a finding, and propose a supported change. Preflight checks, an authorized approval, and post-change verification protect the rollout.
Git-backed history and a verified recovery path support rollback where the operation allows it.
Follow a protected change ↓Handle map and feature requests with independently sized serving capacity.
Place supported long-running work on separate workers or batch compute.
PostGIS, object storage, and durable coordination keep data and job state outside disposable serving instances.
Trace a request, walk through migration and operations, or inspect the container, cluster, AWS, and Azure deployment patterns.
Architecture diagrams & technical reference ↗Console and Studio provide the workspace; SDKs connect applications and data pipelines; agents work through explicit tools. Server provides shared data, services, policy, and execution.
Connect your existing tools and applications through shared spatial data and standard interfaces. Adopt Honua one workflow at a time.
Inspect capability coverage ↗Honua defines and implements an open geospatial gRPC/Protobuf protocol. Typed requests and incremental results give services and SDKs another integration path. Measure network and throughput benefits on your workload.
Explore the protocol ↗Authentication, policy, catalog lookup, query planning, encoding, and telemetry converge on shared runtime services. Adapters translate covered operations into that core.
Illustrative sequence only. Latency and response behavior depend on the operation, data, and deployment.
Connect desktop GIS, web applications, SDKs, and agents to the same spatial services.
Documented surfaces converge on common policy, catalog, data, analytics, publishing, and job components. Capability flags make the available surface inspectable.
Create a layer from an existing table without copying its data, or import files and services. PostgreSQL/PostGIS supports full read/write; the other database providers offer read/query access.
Explore database capabilities →
Start with containers, use managed serverless compute, or run on your own cluster. Map traffic and heavyweight jobs do not have to compete for the same capacity.
Run a small containerized stack for a local evaluation or a straightforward deployment.
Scale serving tasks with demand and send suitable heavy jobs to on-demand batch workers.
Manage serving replicas and worker capacity independently on Kubernetes.
Interactive requests stay on the serving tier. Longer jobs retain their state while separate workers do the processing.
PostGIS holds spatial data and the catalog. Object storage holds files and results. Redis coordinates shared jobs where required. Telemetry goes to your observability backend.
The roles stay the same. Choose the services that fit your environment.
| Role | AWS | Azure |
|---|---|---|
| Container serving | ECS / Fargate | Container Apps |
| Node-based clusters | EKS + Helm | AKS + Helm |
| Heavy processing | AWS Batch / Kubernetes Jobs | Azure Batch / Kubernetes Jobs |
| Spatial database | RDS PostgreSQL + PostGIS | Azure PostgreSQL + PostGIS |
| Files & results | S3-compatible storage | Blob storage |
| Shared coordination | Redis | Redis |
| Observability | Your OpenTelemetry backend | Your OpenTelemetry backend |
Reference deployment paths; process backends and runtime dependencies vary by release. Lambda and Azure Functions references are also available for suitable workloads.
For a production deployment, validate sizing, availability, upgrades, rollback, backup, and recovery against your workload.
Migration is more than moving data. Publish the layers you need, adapt the applications that use them, and convert supported scripts and processing workflows with Honua’s migration tools.
Create a live layer from an existing database table without copying its data, or import supported services and files. Check fields, geometry, access, and the interfaces your clients use.
Publish existing tables ↗ Service migration guide ↗Scan a web application and use automated code conversion to rewrite supported imports and API calls. Choose Honua compatibility APIs or MapLibre-native output, then review the generated changes and flagged manual work.
Application migration tools ↗Scan Python scripts, toolboxes, and processing definitions. Translate supported operations into Honua process calls, with a report separating runnable mappings, manual review, and unsupported work.
Python migration tools ↗Code conversion is scoped to the patterns each tool supports. Review the output, build the application, and test the workflow before cutover. For .NET and MAUI, migration guides and adapters support reimplementation; Not yet automated source rewriting.
Record services, layers, authentication, and data sources. Scan the application or script for supported patterns and dependencies, without changing the source.
Service inventory + code scan → migration scope
Compare required operations with the compatibility evidence and code-conversion reports. Separate automatic rewrites from manual changes, including widgets, authentication, and processing semantics.
Open the compatibility evidence →Connect an existing database table or import the selected service data. Run the JavaScript/TypeScript or Python conversion tool for the chosen workflow in a working branch, inspect its diff and report, and complete the flagged manual steps.
Review migration evidence →Test the converted app or script against the published layers. Verify queries, widgets, authentication, and processing outputs alongside the existing workflow before calling the migration complete.
Not yet Estate-wide behavioral comparison reportingDeploy the reviewed application or script and update its connections once the workflow passes. Keep the previous application version and services available for recovery, observe the result, and expand incrementally.
Read the full migration playbook →Server MCP discovery and query use the same policy and data boundaries as other interfaces.
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.
Read health and telemetry, inspect deterministic findings, and prepare policy-scoped proposals. Risky and irreversible work remains approval-gated.
Health/readiness endpoints, Prometheus metrics, and OpenTelemetry signals expose the deployment state.
Operators and agents can inspect the signals behind a proposed change.
The single-environment loop produces proposals under configured release and policy controls.
Low-risk actions need an explicit policy. Risky or irreversible work requires approval.
Post-action verification and compensating rollback are implemented at the operation gateway. Signed fleet promotion across environments, and broader remediation, are not yet implemented.
Agents use scoped credentials and the same authorization boundaries as interactive or service clients.
Operators can inspect the condition, proposed action, and configured policy before execution.
Automation does not turn unknown, risky, or irreversible work into an implicit background action.
Illustrative request paths and deployment patterns. Architecture reference · Release notes