Spatial expertise deserves more reach.
Analysts should spend more time answering questions. Administrators should gain skills they can use across modern infrastructure. Developers should be able to bring spatial data into applications people already use.
That is the direction behind Honua. A GIS server is one component. The platform connects spatial data, applications, analysis, automation, and the infrastructure that runs them.
Automate migration. Create with AI. Scale with demand. Operate with confidence.
Bring what you have.
Substantial functional overlap with ArcGIS Server, GeoServer, and other GIS tools is intentional. Familiar capabilities and compatible interfaces give teams a practical adoption path.
Services, layers, and application code are different migration problems. Automated imports and codemods help with supported paths; inventories, compatibility checks, output review, and workflow tests establish whether a specific move is ready. The objective is incremental migration, not a claim that every existing workflow converts automatically.
Build what comes next.
AI is part of how we build the platform and how people work through it. It is not an optional explanation layer over a traditional server.
In Studio, an agent can compose a spatial application through typed commands: selecting layers, changing styling, and refining views. Maps and applications become durable artifacts with version history—not just a conversation that disappears.
Studio is currently a self-hosted Preview. Across the platform, agents work through supported interfaces and explicit authority. Direct editing of source feature data stays outside the AI interface.
Scale the work—not idle infrastructure.
A fast map query and a long-running spatial job should have separate capacity decisions. Honua’s execution direction separates serving from durable coordination and processing.
Containers, serverless runtimes, scalable clusters, and batch backends are tools for matching compute to the workload. The benefit is not the presence of a Docker image; it is avoiding an all-purpose server sized for every possible peak. Actual savings need to be measured against the workload and deployment.
Efficiency includes data movement. The open geospatial gRPC protocol adds typed, streaming contracts alongside GIS standards and modern APIs.
Make change routine—and reversible.
Upgrades should become normal maintenance rather than exceptional projects. Git-backed configuration, versioned artifacts, telemetry, and protected operations connect an intended change to an observable result.
The Ops Inbox brings findings, evidence, and available remediation suggestions together. Human approval, explicit policy, and verified recovery remain part of the design. A successful container start is not sufficient evidence that a user’s workflow still works.
Make adoption understandable.
Community, Pro, and Enterprise are backed by a feature registry. Edition answers which capabilities are included. Usage or capacity will answer how commercial pricing scales. The units and rates are still being developed, without a Honua named-user fee.
Honua Server and Collect use ELv2. Other platform components use Apache 2.0. The mobile SDK and Collect app are experimental. Licenses, editions, release maturity, and support are separate questions.
The promise is a direction, not a statement that every component is equally mature. The supporting capability evidence and release documentation should make those boundaries inspectable.
Implementation references
These references describe the implementation and its current boundaries. Check release-pinned documentation before deployment.