GitOps + OTel

Run GIS like the rest of your production infrastructure.

Honua gives platform teams a way to publish, change, and observe geospatial services without depending on hidden server state or manual administration. Manage services with manifests, review changes in Git, and trace requests through the runtime and into the data layer.

Read the Docs View the Runtime Talk to Us

Manifest-based changes OpenTelemetry support Containers and serverless Standard cloud tooling

Manifest Example

service:
  name: parcels
  source: postgis://operations/parcels
  protocols: [geoservices, ogcapi, grpc]
  style: parcels-default
  permissions:
    readers: [planning, public-map]

Trace Example

route: /grpc.features.QueryFeatures
span_count: 7
db.statement: SELECT ... FROM parcels
cache.hit: true
status: ok

Git-Friendly Changes

Publish services and configuration with the same review discipline you use elsewhere.

Declarative Setup

Describe services, styles, and permissions as files.

Treat publication and configuration as reviewable artifacts instead of a sequence of clicks inside a server UI.

Safer Rollouts

Use the same promotion flow as the rest of your stack.

Move changes through pull requests, CI checks, and environment promotion rather than making production edits directly.

Auditability

See what changed, when it changed, and who approved it.

Teams get a clearer change trail for compliance, incident review, and repeatable recovery.

OpenTelemetry

Stop guessing why a spatial request is slow.

Honua exposes traces so teams can follow a request from ingress through the runtime and into the database. That makes performance tuning and incident response concrete instead of guesswork.

Request Visibility

Trace application calls, query execution, and downstream dependencies.

Use Datadog, Grafana, Honeycomb, or another standard observability tool instead of relying on server-local logs and guesswork.

Shared Context

Give platform teams and GIS teams the same visibility into runtime behavior.

Operations issues stop being a handoff problem when both sides can see the same trace and understand where time is actually being spent.

Deployment Paths

Use the footprint that matches the workload.

Target	Fit	What teams like about it
Docker and Kubernetes	Steady traffic, controlled rollouts, shared platform clusters	Fits existing CI/CD, ingress, scaling, and secret management patterns.
ECS, AKS, and managed containers	Cloud-native operations without custom GIS infrastructure	Uses the same cloud control plane as the rest of your services.
AWS Lambda and Azure Functions	Event-driven or bursty workloads	Scale-to-zero economics for request-driven spatial processing.

If your platform team cannot deploy, roll back, or trace a GIS service the same way they handle everything else, the GIS stack becomes an operational liability.

Next Step

Pair the operations model with the runtime or the modernization path.

See how the gRPC runtime fits with these operational patterns, or move to the modernization page if you are planning a cutover from existing GIS infrastructure.

View the Runtime Modernization Open Docs